De pantallas dispersas a una app de logística coherente.

¿Cómo navegas y negocias en Kuyuy?

Kuyuy conecta transportadores con generadores de carga para envíos nacionales e internacionales. La migración a una app nativa prometía escalabilidad, ahorro de tiempo y soporte — todo en un solo lugar.

Pero la realidad era más desordenada. El producto tenía muchos wireframes de alta fidelidad, pero sin arquitectura global, sin prototipo interactivo y con terminología inconsistente entre tres perfiles de usuario (Transportador, Generador de Carga y SuperAdmin — cada uno con variantes Admin y Empleado). Lo que tenía sentido internamente no tenía sentido para los usuarios reales.

Lead de diseño en un equipo cross-funcional.

Lideré el diseño de punta a punta: arquitectura de información, flujos de usuario, prototipos de alta fidelidad, mapeo de edge cases y la librería de componentes que engineering siguió durante el build. Trabajé de cerca con el PM en el scoping y con el cliente para validar decisiones en cada fase.

Mi foco fue convertir un producto web fragmentado en una app nativa que funcionara para tres perfiles de usuario — sin tener que construir tres interfaces distintas.

Cómo se veía cada decisión en la práctica.

Una arquitectura, tres perfiles

En lugar de construir tres apps paralelas, diseñé una arquitectura de información única donde las entidades compartidas (envíos, contratos, mensajes) se veían igual para todos — pero mostraban acciones específicas del rol donde importaba. El SuperAdmin mantenía control total, Transportadores y Generadores veían solo lo que necesitaban para accionar.

Una etiqueta = un concepto

El producto viejo usaba terminología diferente según quién estaba logueado. Trabajé con el PM para consolidar todo en un solo vocabulario. Ejemplo: "Con Ofertas" significa lo mismo para cada perfil — Oferta + Aceptar/Rechazar + Contraoferta. Mismo término, mismas acciones, mismas validaciones.

El happy path no era suficiente

Mapeé edge cases críticos: documentos rechazados (ver requisitos faltantes, reintentar o escalar), datos incompletos (validar y crear ticket), incidentes en ruta (pausar, reasignar o escalar a Operaciones) y cierres fallidos. Un buen UX cubre tanto lo esperado como lo inesperado.

Insights clave que me llevo.

• La arquitectura primero evita pantallas sueltas y discusiones circulares. Sin un mapa, cada conversación empieza desde cero.
• Un término = una acción. Alinear el lenguaje entre perfiles acelera todo — y previene bugs causados por expectativas desalineadas.
• Prototipar por flujo es mejor que esperar a "la app completa". Las pequeñas validaciones se acumulan más rápido que los grandes releases.
• Guiar activamente al cliente. El mapa visual elimina ambigüedad y acorta los ciclos de revisión.
• Lo que no pudimos validar: testing de tareas tempranas con transportadores y generadores reales. En retrospectiva, un test de cinco segundos sobre la primera acción por perfil habría ahorrado semanas.