Nea

El problema

Entrar a transporte expuso mala usabilidad para usuarios no técnicos, flujos que no se ajustaban a rutas, viáticos y trabajo en campo, inconsistencias visuales, información fragmentada y ningún soporte nativo para equipos o varias empresas. Los clientes compensaban con hojas de cálculo.

Restricciones y principios de diseño

• Multiempresa como necesidad crítica.
• 3 roles (administrador, tarjetahabiente y observador) que necesitan vistas distintas de las mismas entidades.
• Un equipo de ingeniería pequeño, así que los cambios debían ser incrementales y reutilizables.
• Soporte móvil, porque muchos usuarios trabajan en carretera.
• No había margen para cambiar modelos, endpoints ni reglas de negocio; la lógica nueva tenía que vivir en el front end.

Con ese margen, tres principios guiaron el diseño: simplificar para usuarios no técnicos, diferenciar las experiencias por rol y construir la lógica nueva sobre la infraestructura existente.

Multiempresa

Un selector de empresa persistente cambia el contexto de toda la plataforma y conserva el módulo, los filtros y las vistas actuales.

Presupuestos

Modelados como una jerarquía: Empresa → Área → Operador o Equipo → Tarjeta. El flujo de creación cubre configuración básica, reglas y permisos, integrantes, duración y recurrencia, y una revisión final en móvil y escritorio. La vista de detalle muestra disponible contra gastado, desglose por categoría, integrantes, movimientos vinculados y ajustes controlados.

Movimientos

Organizados en Compras, Comisiones y Depósitos. El detalle de una compra tiene estados normal, expandido y rechazado, con la causa del rechazo explícita. Contabilidad cuenta con campos personalizados, metadatos contables y gestión de XML (SAT) dentro del mismo flujo.

Usuarios

Añadir un usuario ocurre en un drawer lateral sobre la lista. En escritorio mantiene el contexto a la vista; en móvil el mismo patrón se adapta al ancho de la pantalla, lo que ayuda a resolver lo responsivo sin diseñar un flujo aparte.

Impacto

Los clientes de transporte pudieron modelar su operación, y operadores y administradores entendieron mejor las reglas de gasto. La revisión de movimientos y XML pasó a formar parte del cierre de periodo. El sistema de diseño redujo los parches visuales, soporte reportó menos preguntas y ventas contó con una narrativa más clara. No medí con rigor la reducción de tickets ni el tiempo de capacitación, y lo señalo como una limitación.

Lo que me llevo

Nea cambió mucho en tres años: pasó de ser una plataforma para equipos de finanzas a sostener también la operación de empresas de transporte. Ese salto fue trabajo de equipo; trabajé junto a la lead designer, el equipo de sistemas de diseño y el de marca, y cada decisión se apoyaba en lo que los demás ya habían construido.

Me quedo con que las restricciones, incluso las duras, no frenan la evolución de un producto cuando se diseña con ellas: sin tocar el backend, la multiempresa y los presupuestos se resolvieron desde el front end, con cambios pequeños y reutilizables.