Caso de producto / Náutica · Ecosistema SaaS
SupaSailing & SupaMaritime
Un mundo marítimo. Un espacio de trabajo para cada rol.
De la sala de máquinas de un yate a la oficina de un puerto deportivo y a una agencia portuaria: una familia de productos digitales que facilita las operaciones complejas, con dos marcas distintas y una forma coherente de organizar el trabajo diario.
- Nuestra contribución
- Estrategia UX, diseño de producto y desarrollo web
- Enfoque del proyecto
- Arquitectura de marca · Navegación por rol · Interfaces operativas · Sitios adaptables
01 / El reto
Diseñar las conexiones detrás de cada travesía
El trabajo marítimo rara vez sucede en un único escritorio. Capitanes, técnicos, equipos de marinas, operadores de chárter y agentes portuarios trabajan sobre la misma embarcación desde perspectivas diferentes. El proyecto convierte esa complejidad en una familia comprensible: SupaSailing atiende la náutica recreativa con Fleet, Charter, Marina, Broker, Shipyard y Guild; SupaMaritime aborda las operaciones comerciales con Agent, Ferry, Merchant y Guild, junto a una oferta independiente de venta de billetes de ferry. La web explica esta estructura antes de pedir al visitante que elija un producto. Dentro del ecosistema, el objetivo pasa de explicar funciones a ayudar a cada rol a reconocer las prioridades y la siguiente acción.
El reto principal no es la cantidad de funciones, sino la diversidad de contextos. Un responsable de marina piensa en amarres y llegadas; un técnico, en equipos y mantenimiento; un agente, en escalas y documentos. Un panel genérico ocultaría esas diferencias. A la vez, los productos necesitan patrones familiares para estados, fichas, permisos y confirmaciones, y la navegación pública debe distinguir con claridad la oferta recreativa de la comercial.
Las decisiones detrás de la experiencia
Empezar por el rol y después mostrar el módulo
Las páginas por rol traducen el catálogo en situaciones de trabajo: jefe de máquinas, responsable de marina, operador de chárter o propietario de astillero. Cada página conecta una responsabilidad conocida con el módulo adecuado. Los nombres de producto siguen visibles, pero la primera pregunta es «¿Qué necesitas gestionar?».
Dos marcas claras, una familia coherente
SupaSailing y SupaMaritime se dirigen a mercados distintos, por lo que sus webs diferencian la náutica recreativa del transporte marítimo comercial. Las convenciones de navegación, los colores de los módulos y las estructuras de página comparables aportan continuidad. Los enlaces entre marcas indican el destino de forma explícita.
Mostrar el estado operativo antes que la administración
Fleet destaca mantenimiento, incidencias, inventario y documentos próximos a vencer; Marina organiza el trabajo alrededor del mapa de amarres, llegadas, solicitudes y contratos; Agent se centra en las escalas y sus tareas. Tablas, etiquetas de estado y acciones contextuales permiten localizar el objeto de trabajo sin perder la jerarquía del conjunto.
Diseñar para trabajar lejos del escritorio
El flujo también incluye el pantalán y la sala de máquinas. El canal de Telegram de Fleet permite comunicar incidencias; el flujo de lectura de contadores de Marina utiliza fotos, OCR, elección del amarre y confirmación. El principio es completar la tarea en su canal de trabajo: capturar, comprobar la interpretación y confirmar el registro antes de guardarlo.
Conectar registros con límites claros entre productos
La arquitectura compartida define un registro canónico de embarcaciones y conexiones explícitas con Fleet, Charter, Broker, Marina y Shipyard. Cada aplicación conserva sus responsabilidades operativas. La coherencia UX se traduce en entidades reconocibles y traspasos previsibles, con límites de integración claros.
02 / Personas e investigación
Diseñar en torno a las necesidades
Proto-personas ilustrativas, basadas en los roles y flujos del producto. Describen hipótesis de diseño, no participantes entrevistados.
La coordinadora de marina
Operaciones · Marina
- Necesidad
- Asignar un amarre adecuado, preparar llegadas y conectar cliente, contrato y facturación.
- Fricción
- Las solicitudes llegan por distintos canales y un mismo amarre cambia de estado según la fecha.
- Respuesta de diseño
- Mapa de amarres por fecha, bandeja de solicitudes y ficha de cliente con acciones contextuales.
El jefe de máquinas
Operaciones técnicas · Fleet
- Necesidad
- Identificar vencimientos, encontrar la ficha del equipo y cerrar el mantenimiento con los datos correctos.
- Fricción
- La información se reparte entre equipos, incidencias, manuales y repuestos, a menudo consultados lejos del escritorio.
- Respuesta de diseño
- Ficha centrada en el equipo, estado de mantenimiento visible y comunicación por Telegram con confirmación.
El agente portuario
Operaciones comerciales · Agent
- Necesidad
- Coordinar la escala e identificar qué tarea, servicio o documento requiere atención.
- Fricción
- Varias escalas avanzan a la vez, con traspasos entre operaciones, documentación y administración.
- Respuesta de diseño
- Un espacio por escala con estados explícitos, documentos relacionados y una siguiente acción clara.
Preguntas de investigación y validación
Este marco de investigación es una reconstrucción editorial basada en los repositorios y las páginas por rol del producto. Las protopersonas y el recorrido representativo expresan hipótesis de diseño. Las preguntas de entrevista y los escenarios de usabilidad son un plan de validación propuesto, no resultados de entrevistas documentadas ni de pruebas realizadas.
Una reconstrucción editorial del razonamiento de diseño. Las preguntas de entrevista y los escenarios de usabilidad son una guía de validación; no se presentan como trabajo de campo realizado ni resultados medidos.
Guía de entrevistas
- Hipótesis: entrar por rol facilita elegir un módulo. Pregunta: «¿Qué necesitabas organizar la última vez que buscaste software marítimo?».
- Hipótesis: el estado solo es útil con contexto. Pregunta: «¿Qué información necesitas antes de asignar un amarre o una tarea de mantenimiento?».
- Hipótesis: los traspasos generan entradas duplicadas. Pregunta: «Muéstranos cómo pasa la información de un mensaje a una hoja de cálculo y al siguiente compañero».
- Hipótesis: la captura móvil necesita una revisión explícita. Pregunta: «Al registrar trabajo en el pantalán o a bordo, ¿qué puedes comprobar al momento y qué debe esperar?».
Escenarios de pruebas de usabilidad
- Tarea propuesta: elegir marca y módulo a partir de un rol; registrar recorrido, dudas y justificación.
- Tarea propuesta: encontrar un amarre para una embarcación y estancia de ejemplo; comprobar la comprensión de fechas, dimensiones, disponibilidad y conflictos.
- Tarea propuesta: revisar una lectura OCR en Telegram, corregir un amarre ambiguo y confirmar; observar la recuperación de errores y la confianza antes de guardar.
- Tarea propuesta: localizar un mantenimiento vencido y su equipo; valorar si urgencia, responsable y siguiente acción se entienden sin ayuda.
- Plan de revisión: repetir los recorridos esenciales en pantalla pequeña y con teclado, incluyendo estados vacíos, permisos, cargas interrumpidas y guardados fallidos. Registrar finalización y errores sin inventar una referencia ni un resultado.
03 / Customer journey
Customer journey
Un recorrido representativo reconstruido a partir del producto, que conecta cada necesidad con una decisión de interfaz.
| Etapa | Acción de la persona | Fricción | Respuesta de diseño |
|---|---|---|---|
| 01 · Encontrar el punto de entrada | El profesional llega a la web a partir de su rol o necesidad operativa. | Un catálogo amplio puede dificultar la distinción entre módulos similares. | Las páginas por rol explican el escenario y llevan a la marca y al módulo adecuados. |
| 02 · Comprender la situación | La coordinadora comprueba fecha, llegadas previstas y amarres disponibles. | Una vista sin contexto temporal puede sugerir una disponibilidad que no coincide con la estancia. | Mantener visibles la fecha, el estado de los amarres y las solicitudes recibidas. |
| 03 · Actuar sobre la ficha correcta | Se revisa la solicitud, se vincula al cliente y a la embarcación y se asigna un amarre adecuado. | La entrada repetida y las selecciones ambiguas pueden generar duplicados o conflictos. | Utilizar fichas reconocibles, selecciones explícitas y avisos de conflicto. |
| 04 · Registrar el trabajo en el pantalán | El operario fotografía el contador y comprueba la lectura interpretada en Telegram. | La foto por sí sola no garantiza una lectura, unidad o amarre correctos. | Mostrar el valor interpretado, permitir elegir el amarre y confirmar antes de guardar. |
| 05 · Entregar el trabajo con contexto | La oficina revisa la estancia, los consumos relacionados y las tareas administrativas pendientes. | El traspaso pierde valor si el siguiente compañero no ve qué se ha registrado y qué sigue pendiente. | Conectar estancia, lecturas y facturación, con estado y siguiente acción visibles. |
0101 · Encontrar el punto de entrada
- Acción de la persona
- El profesional llega a la web a partir de su rol o necesidad operativa.
- Fricción
- Un catálogo amplio puede dificultar la distinción entre módulos similares.
- Respuesta de diseño
- Las páginas por rol explican el escenario y llevan a la marca y al módulo adecuados.
0202 · Comprender la situación
- Acción de la persona
- La coordinadora comprueba fecha, llegadas previstas y amarres disponibles.
- Fricción
- Una vista sin contexto temporal puede sugerir una disponibilidad que no coincide con la estancia.
- Respuesta de diseño
- Mantener visibles la fecha, el estado de los amarres y las solicitudes recibidas.
0303 · Actuar sobre la ficha correcta
- Acción de la persona
- Se revisa la solicitud, se vincula al cliente y a la embarcación y se asigna un amarre adecuado.
- Fricción
- La entrada repetida y las selecciones ambiguas pueden generar duplicados o conflictos.
- Respuesta de diseño
- Utilizar fichas reconocibles, selecciones explícitas y avisos de conflicto.
0404 · Registrar el trabajo en el pantalán
- Acción de la persona
- El operario fotografía el contador y comprueba la lectura interpretada en Telegram.
- Fricción
- La foto por sí sola no garantiza una lectura, unidad o amarre correctos.
- Respuesta de diseño
- Mostrar el valor interpretado, permitir elegir el amarre y confirmar antes de guardar.
0505 · Entregar el trabajo con contexto
- Acción de la persona
- La oficina revisa la estancia, los consumos relacionados y las tareas administrativas pendientes.
- Fricción
- El traspaso pierde valor si el siguiente compañero no ve qué se ha registrado y qué sigue pendiente.
- Respuesta de diseño
- Conectar estancia, lecturas y facturación, con estado y siguiente acción visibles.
04 / Wireframing
De la estructura a la interfaz
Wireframes de baja fidelidad reconstruidos para este caso. Explican la jerarquía y el flujo, sin reproducir archivos originales del proyecto.
05 / UI y diseño visual
Sitios públicos y bocetos de diseño
Los pies de imagen distinguen capturas de sitios públicos y bocetos de plataformas generados con IA. Abre una imagen para ver sus detalles.
Lo que permite el diseño
El resultado es una familia de productos con una estructura comprensible: mercados diferenciados, entradas por rol e interfaces organizadas alrededor de los objetos del trabajo diario. El caso conecta arquitectura de marca, webs públicas y diseño operativo, desde la ficha de una embarcación hasta el mapa de amarres y una lectura confirmada sobre el terreno. Su aportación principal es una forma coherente de convertir la complejidad en acciones comprensibles; no se atribuyen impactos económicos ni métricas de uso sin medición documentada.
