Custox Fleet
Diseño de punta a punta de una plataforma B2B que reúne el rastreo satelital de una flota de gran escala en una sola vista operativa, para un bróker de seguros. En dos meses, el proyecto pasó del brief al desarrollo.
Resumen y contexto
Resumen
Como única diseñadora, llevé la plataforma de principio a fin, desde la investigación hasta la entrega a desarrollo: definí la arquitectura, la experiencia y los distintos estados del sistema, y preparé un código base para facilitar su paso a implementación.
Contexto
El cliente es un bróker de seguros especializado en flotas de transporte de carga pesada. Asegura una flota de gran escala y necesitaba controlar su estado operativo en tiempo real, pero la información de rastreo le llegaba dispersa entre distintos proveedores de GPS.
Para un bróker de seguros, el estado operativo de la flota está directamente ligado a su exposición al riesgo. Una unidad que deja de reportar es un vehículo sin seguimiento; una alerta de pánico detectada tarde puede derivar en un robo o un siniestro.
El MVP debía resolver eso: una sola plataforma para monitorear la salud de la flota, revisar el detalle de cada unidad y responder a las alertas de seguridad, sin alternar entre sistemas.
Un punto definió el enfoque: el usuario principal era el propio equipo operativo del cliente, que necesita ver de un vistazo qué unidades dejaron de reportar o tienen una alerta activa, y decidir rápido. Usa la plataforma para consultar y actuar, no para explorar. Por eso prioricé la densidad de información y la lectura rápida por encima de una lógica narrativa o comercial.
El alcance: una landing con acceso, el login y tres dashboards (estado general, detalle por unidad y alarmas de seguridad).
El desafío
El desafío era convertir esa información fragmentada en una vista operativa que permitiera detectar rápidamente qué unidades requerían atención, sin perder legibilidad pese al volumen de datos. A eso se sumaron tres condiciones de ejecución:
Ritmo de ejecución
No había una fecha límite pactada, pero el cliente necesitaba avanzar con rapidez hacia una solución lista para desarrollo e integración.
Trabajo en paralelo
El proyecto convivió con otros trabajos activos, por lo que la organización del tiempo y la priorización formaron parte de la ejecución.
Coordinación entre áreas
Trabajé con el CTO como interlocutor principal, con Marketing y con el equipo de desarrollo, y alinear criterios entre las tres áreas fue parte del trabajo.
Enfoque y proceso
Trabajé con IA (GPT y Claude) y especificaciones para acelerar dos frentes: la investigación de patrones del rubro y la validación temprana de propuestas mediante prototipos funcionales. Las decisiones se documentaban en especificaciones que servían como base para desarrollo. La IA aceleró la exploración; el criterio y las decisiones siguieron siendo de diseño.
La investigación se apoyó en tres fuentes: plataformas de referencia del sector (Samsara, Geotab, Fleetio, entre otras), criterios de accesibilidad aplicables y el aporte directo del equipo que iba a operar la herramienta, recogido en reuniones y en un brief. De ahí salieron decisiones concretas: la navegación lateral fija, recurrente en las plataformas analizadas, y la regla de que ningún estado se comunicara solo con color.
Trabajé sobre componentes de shadcn/ui y Tailwind para mantener la propuesta cerca de implementación. El handoff no terminó en Figma: a partir de las especificaciones preparé una base funcional que entregué a desarrollo como punto de partida.
De la especificación a la interfaz
Las especificaciones documentaban comportamiento, jerarquía y criterios de accesibilidad antes de llevarlos a la interfaz. La misma definición fue la referencia para el prototipo y para la entrega a desarrollo.
Especificación · Alarmas de la flota
- Severidad
- Pánico tiene mayor peso visual que Desconexión.
- Representación
- Usar badges por tipo de alerta.
- Accesibilidad
- Nunca usar el color como única señal para comunicar estado.
- Acompañarlo con una etiqueta o un indicador equivalente.
De la exploración al sistema final
La exploración no buscó multiplicar variantes, sino converger temprano sobre una estructura que respondiera al problema y validarla contra los patrones del sector. A partir de ahí, el trabajo se concentró en llevarla a un sistema completo.
En los dashboards, la estructura se mantuvo estable desde temprano. La mayor parte de la iteración estuvo en cubrir estados vacíos y filtrados, modos claro y oscuro, selector de cliente e interacciones de drill-down.
Sobre esa base, dos decisiones de dirección terminaron de ajustar la propuesta a la identidad del cliente.
El hero de la landing
La primera propuesta mostraba el producto para explicar de inmediato qué ofrecía la plataforma. En la versión final, trabajada junto a Marketing, se reemplazó por fotografía de flota. Mantuvimos la estructura, pero adaptamos la primera impresión a la identidad visual que buscaba el cliente. La contrapartida fue perder parte de esa explicación inmediata: el producto pasó a explicarse más abajo, dentro de la propia landing.
Dirección final
El login
La primera propuesta priorizaba una pantalla sobria y centrada en el acceso. En la versión final incorporamos una imagen institucional y un layout dividido para acercarlo a la identidad visual del cliente, sin alterar la jerarquía ni la simplicidad del formulario.
Dirección final
Landing final
Decisiones de diseño
Las decisiones combinan patrones del rubro, criterios de accesibilidad y restricciones operativas del producto.
Acceso directo: landing orientada al ingreso y login dedicado
Como el usuario ya es cliente y entra a trabajar, la landing no sigue la lógica de captar o convertir: es una pantalla de acceso con contexto, que muestra el sistema real y ubica el ingreso como acción principal. El login se resolvió en una pantalla dedicada y no en un modal, para evitar los problemas habituales del modal en mobile en un acceso a datos sensibles: el teclado sobre el formulario y el manejo del foco.
Estados tipo semáforo, con un cuarto estado diferenciado
Para el estado de reporte de cada vehículo tomé como referencia el patrón recurrente en las plataformas de fleet management analizadas: verde, amarillo y rojo. El brief definía un cuarto estado, "nunca reportó", en negro. Lo pasé a gris oscuro porque, en este contexto, el negro podía leerse como sistema caído y prestarse a confusión. Además, ningún estado se comunica solo con color: cada uno se acompaña con un ícono o una etiqueta, por accesibilidad.
KPI cards ordenadas por criticidad, con drill-down
El dashboard Estado de flota abre con un grupo acotado de indicadores prioritarios: número destacado, etiqueta breve y color. Los estados críticos tienen más peso visual que el estado operativo, y cada card accionable lleva directo al detalle ya filtrado por ese estado. Así, el estado general se lee rápido y se llega sin pasos intermedios a las unidades que requieren atención.
Una tabla densa que se mantiene legible
El detalle por unidad tiene doce columnas. Fijé el VIN como primera columna para mantener la referencia del vehículo durante el scroll horizontal en resoluciones más chicas. El estado se muestra mediante un indicador de color en lugar de pintar la fila completa. Colorear toda la fila habría hecho más visible la criticidad, pero en una tabla de doce columnas competía con la lectura de los datos. Preferí una señal localizada y dejé la mayor jerarquía a las KPI cards, que ya permiten acceder al detalle filtrado por estado.
Alarmas con severidad diferenciada
Esta vista concentra las alertas críticas de seguridad: pánico y desconexión del rastreo. No tienen la misma gravedad. Una alerta de pánico puede implicar una persona en riesgo inmediato, mientras que una desconexión corresponde a una anomalía del dispositivo. Esa diferencia se refleja en la jerarquía visual: rojo para pánico y naranja para desconexión, de modo que puedan priorizarse de un vistazo. La documentación del siniestro queda accesible desde la misma fila.
Cobertura de estados y casos límite
Buena parte del trabajo necesario para dejar la plataforma lista para desarrollo estuvo en cubrir situaciones fuera del estado ideal: filtros sin resultados, ausencia de señal GPS, modos claro y oscuro, selector de cliente, tooltips y paginación.
Aunque el escenario principal de uso era desktop, por la densidad de información y el trabajo con tablas, también se trabajó la adaptación responsive para conservar jerarquía, legibilidad y acceso a la información en resoluciones menores. Resolver estos estados permitió llevar la propuesta de una pantalla ideal a un sistema completo.
Resultado y estado actual
En dos meses, la propuesta pasó de un brief con información fragmentada a una plataforma definida de punta a punta, con arquitectura, estados, flujos y vistas operativas listas para desarrollo. El diseño fue aprobado tras distintas instancias de validación con el CTO y se entregó junto con una base funcional para facilitar su implementación.