Volver a proyectos

MELI UX challenge

Rediseñando la experiencia de ruta en Envíos Flex para que un transportista con una mano libre y 2 segundos de mirada pueda hacer su trabajo sin buscar información.

0%
Caída de NPS en el último mes
0
Entregas por jornada
0s
Tiempo de mirada a pantalla
↓ Descubrir el caso
Ilustración de un transportista en moto consultando la app Envíos Flex
01 · Brief

El punto de partida

Un NPS que cae y cuatro transportistas que dicen lo mismo: la información está, pero cuesta encontrarla.

  • Envíos Flex es la solución de Mercado Libre para entregas same day y next day operadas por la logística del propio vendedor. Brief
  • La app es la herramienta central de trabajo: consulta de paradas, validación de dirección, identificación del receptor y confirmación de entrega.
  • Contexto de uso: arriba de una moto, entre paradas, con atención fragmentada y ventanas de lectura de 2-3 segundos. Inferencia
Ilustración de un transportista en la puerta de un edificio consultando su celular
–4%
Caída de NPS en el último mes Brief
  • La investigación interna apunta a que los transportistas necesitan más claridad y más contexto sobre la ruta y cada entrega. Brief
  • El problema no es la falta de features. El problema es cómo la app organiza, jerarquiza y revela información crítica durante la jornada. Inferencia

Qué nos están diciendo los usuarios Brief

"

Necesito organizar mis entregas por distancia y proximidad para perder menos tiempo en las mismas.

C
Carlos, 32 años
La app podría ordenar por proximidad, pero no lo hace
"

Cuando el encargado del edificio me pregunta el nombre de quién va a recibir la entrega, nunca me acuerdo dónde encuentro la información.

C
Claudia, 45 años
El nombre del receptor existe, pero está colapsado
"

Cuando llego a la dirección, muchas veces es difícil encontrar el número de la casa, así que termino llamando directamente al comprador.

P
Pablo, 24 años
La dirección llega sin jerarquía visual
"

Sería genial si en cada parada supiera cuántos productos o paquetes todavía tengo que entregar, así puedo prepararlos con anticipación.

T
Teresa, 58 años
No se muestra la cantidad de paquetes por parada
Insight clave Inferencia

Los cuatro feedbacks convergen en una misma lectura: la app ya cuenta con gran parte de la información necesaria, pero no la entrega con la jerarquía adecuada ni en el momento operativo correcto.

02 · Definición del problema

Cuatro dolores, un solo problema

Mi hipótesis: los cuatro dolores comparten una raíz de arquitectura de información.

Qué revela la experiencia actual Inferencia

Pantalla "Tus paradas del día"
  • Las paradas se listan, pero no se comunica si están ordenadas por proximidad
  • No se muestra el nombre del receptor ni la cantidad de paquetes por parada
  • Falta una referencia clara de progreso dentro de la jornada
Pantalla "Detalle de parada"
  • La dirección aparece como bloque de texto corrido, sin jerarquía
  • La cantidad de paquetes está colapsada detrás de una interacción adicional
  • Los datos del comprador están escondidos, aunque son necesarios en el momento

Contexto operativo Inferencia

Constraints de diseño: cómo opera el transportista Flex
🏍️
Vehículo Moto con soporte de celular
📱
Dispositivo Android gama media, 6.1"
✋
Manos Una mano libre
👁️
Atención 2-3 seg de mirada a pantalla
📦
Entregas 15 a 25 por jornada
🗺️
Zonas Alterna entre conocidas y nuevas
Frustración clave: "Pierdo tiempo buscando datos que deberían estar visibles. Quiero completar más entregas en menos tiempo."
Problema formulado Inferencia

La app Envíos Flex no organiza ni jerarquiza la información de ruta y entrega de forma que el transportista pueda operar con eficiencia y confianza en contexto de calle.

How Might We

¿Cómo podemos darle al transportista la información que necesita en cada momento de su ruta, sin que tenga que buscarla?

  • ¿Cómo construimos confianza en el orden sugerido de entregas?
  • ¿Cómo logramos que el nombre del receptor sea visible en el momento exacto de uso?
  • ¿Cómo hacemos que la dirección precisa se entienda de un vistazo?
  • ¿Cómo damos visibilidad de carga y progreso sin sumar ruido visual?

Principios de diseño Inferencia

1
Información en el momento justo
La interfaz acompaña cada etapa con el detalle adecuado
2
Cero búsqueda
Si un dato requiere tocar o scrollear, la experiencia falla
3
Diseñado para la calle
Miradas breves, una mano libre, movimiento y distracciones
4
Progreso siempre visible
La jornada debe sentirse controlable y predecible
5
Confianza en la ruta
Si el sistema sugiere un orden, debe explicar por qué
03 · Investigar

Evidencia, benchmark y hallazgos

Qué pude confirmar, qué tuve que asumir y qué patrones del mercado validan la dirección.

Supuestos críticos, con nivel de certeza Supuesto

# Supuesto Tipo Certeza Fuente Si falla, qué cambia
S1 Los transportistas prefieren un orden sugerido por proximidad vs. elegir su propio orden Comportamiento Media Brief (1 quote de Carlos) Si prefieren control total, el default cambia: "tu orden" es el principal, sugerencia es secundaria
S2 El nombre del receptor es dato que la app ya tiene disponible por envío Dato técnico Alta Inferencia: MELI procesa compras, tiene estos datos Si no está, la feature no se puede implementar
S3 La dirección viene como dato estructurado (calle, número, piso, depto) Dato técnico Baja Inferencia del wireframe, no confirmable La jerarquía de 4 niveles se degrada a texto plano con parsing. Diseño con fallback incluido
S4 El algoritmo de proximidad existe en el backend Técnico Desconocida No hay dato en el brief Sin algoritmo, la app ordena por geolocalización del dispositivo (sort simple, no ruteo)
S5 Los transportistas manejan entre 10-30 entregas por jornada Contexto Alta Brief + benchmark industry Si es mucho más, la UI de lista necesita paginación/filtros

Benchmark funcional Benchmark

🗺️
Google Maps
Navegación turn-by-turn con siguiente maniobra prominente
→ "Siguiente parada" como hero de la UI
🚗
Waze
Info contextual en ruta sin interrumpir la navegación
→ Datos de parada visibles sin cambiar de pantalla
📦
Amazon Flex
Lista de entregas con ruta optimizada y progreso visible
→ Benchmark directo: lista + ruta + progreso
🛵
Rappi / PedidosYa
Card de "próximo pedido" con dirección, nombre y contador
→ Patrón de card con info key visible
🔄
Circuit / Spoke
Optimización de ruta para repartidores, drag to reorder
→ Cómo comunicar "ruta optimizada"
⚡
Onfleet
Dashboard de entregas con estados, ETA y notas por parada
→ Referencia enterprise para field operations

Heurísticas UX aplicadas Benchmark

#1 Visibilidad del estado del sistema
#2 Coincidencia sistema-mundo real
#6 Reconocimiento sobre recuerdo
#8 Diseño estético y minimalista
M Ley de Miller (5-7 elementos)
F Ley de Fitts (CTAs accesibles)

Mapa de Pains y Gains Inferencia

✕ Pains actuales
Alta No saber el orden óptimo → pierde tiempo
Alta No encontrar nombre del receptor → fricción con portero
Alta No ver piso/depto → debe llamar al comprador
Media-Alta No saber paquetes por parada → no puede preparar
Media No tener sentido de progreso → ansiedad
Alta Info de dirección en texto largo sin estructura
✓ Gains esperados
Directo Ruta optimizada → menos km, menos tiempo
Alto Nombre visible → entrega fluida en edificios
Alto Dirección estructurada → llega sin llamar
Medio Contador de paquetes → prepara antes de llegar
Alto Progreso visible → sensación de control

Insights del research Inferencia

Insight 1

Los 4 pain points no son problemas independientes. Son síntomas de un problema de arquitectura de información.

Insight 2

Interfaz entendible de un vistazo (2–3 segundos)

Insight 3

"Datos comprador" está colapsado detrás de un chevron en el detalle de parada. Ese dato debería ser lo primero visible, no lo último accesible.

Insight 4

No hay progreso visible en el wireframe actual. El transportista no sabe "llevo 8 de 20" y eso genera incertidumbre sobre su jornada.

Oportunidades priorizadas Inferencia

Prioridad Oportunidad Razón
P0 Dirección estructurada con jerarquía visual Resuelve pain #3, reduce llamadas, impacto inmediato
P0 Nombre de receptor prominente en detalle de parada Resuelve pain #2, cambio de UI puro
P0 Ruta ordenada por proximidad con indicación visual Resuelve pain #1, diferencial fuerte
P1 Contador de paquetes por parada + progreso global Resuelve pain #4, agrega contexto operativo
P2 Integración directa con navegación externa Reduce fricción de alternancia entre apps
P2 Barra de progreso de jornada Reduce ansiedad, mejora percepción
De la investigación a la solución

Los cuatro dolores comparten una raíz: la información ya existe en la app, pero no se entrega con la jerarquía ni en el momento correcto. No faltan features. Falla la arquitectura de información.

La dirección es reorganizar, no agregar. Eso se traduce en 5 decisiones concretas de diseño.

04 · Solución propuesta

Copiloto de ruta

Un copiloto que propone, informa y se adapta. Porque el transportista sabe más sobre su territorio que cualquier algoritmo.

⚠️
Encuadre: Propuesta fundamentada en research secundario y benchmarks. Cada decisión requeriría validación real con transportistas antes de producción.
✓ Dirección elegida

Dirección elegida: "Copiloto de ruta" Inferencia

Rediseño centrado en la ruta como eje narrativo. La app se comporta como un copiloto: muestra la siguiente parada con toda la info necesaria, organiza por proximidad, y permite avanzar linealmente. El patrón "siguiente parada" es familiar en apps de navegación y tiene baja curva de aprendizaje.

5 decisiones concretas de diseño Supuesto

📋
Lista de paradas
Orden por proximidad. Badge de paquetes y nombre del receptor visibles sin abrir nada. Acciones rápidas: "Llevar primero" y "Hacer después".
📍
Detalle de parada
Dirección en 4 niveles jerárquicos (calle, número hero, piso/depto, entre calles). Mapa inline. Receptor prominente.
📊
Progreso
Barra "X de Y entregas" siempre visible. Badge por parada: pendiente, en camino, entregada. Sensación de control.
📦
Paquetes
Conteo por parada en la card. Preparar antes de llegar. Lista expandible con IDs en el detalle.
🧭
Navegación
Patrón "siguiente parada" con bottom sheet. CTA adaptativo: "Abrir en Maps" → "Llegué" al acercarse. "Llegué" siempre disponible como acción manual.

Cómo se resuelve cada pain point

No saber el orden óptimo
→
Lista auto-ordenada por proximidad + banner "Ruta sugerida" con ahorro cuantificado
→
Vista de ruta
No encontrar nombre del receptor
→
Nombre visible en la card de la lista + prominente en detalle con ícono de persona
→
Lista + Detalle
Ubicación exacta difícil
→
Dirección en 4 niveles: calle + número XL + piso/depto tag + entre calles + mapa inline
→
Detalle
No saber cuántos paquetes
→
Badge "📦 2" en cada card + sección "Paquetes en esta parada" en detalle
→
Lista + Detalle
Sin visibilidad de progreso
→
Barra "X de Y entregas" siempre visible + badge de estado por parada (pendiente, en camino, entregada)
→
Vista de ruta

Los HMW, respondidos

¿Cómo darle la info en cada momento?
→
Modelo de copiloto: cada pantalla muestra solo lo que el transportista necesita en esa etapa (inicio → ruta → parada → entrega → cierre)
→
Todo el flujo
¿Cómo construir confianza en el orden?
→
Banner "Ruta sugerida" con tiempo ahorrado + posibilidad de reordenar con acciones rápidas
→
Vista de ruta
¿Cómo hacer visible el nombre del receptor?
→
Nombre visible en la card de la lista (sin abrir) + prominente en detalle con ícono de persona
→
Lista + Detalle
¿Cómo hacer la dirección legible de un vistazo?
→
Dirección en 4 niveles jerárquicos: calle + número XL + piso/depto tag + entre calles como referencia
→
Detalle

Diseño resiliente: cómo funciona con y sin backend

Cada decisión tiene un fallback para funcionar cuando las condiciones técnicas no son las ideales.

🗺️ Ruta sugerida
Si hay algoritmo La app muestra "Ruta sugerida · Ahorrás ~38 min" con optimización real de ruteo.
Sin algoritmo Las paradas se muestran en el orden asignado, con opción "Ordenar por cercanía" que usa geolocalización del dispositivo para un sort simple (distancia en línea recta, no ruteo).
📍 CTA "Llegué" y GPS
GPS preciso El botón "Llegué" aparece automáticamente al detectar distancia <200m. Experiencia adaptativa sin intervención del usuario.
GPS impreciso "Llegué" siempre disponible como acción manual (botón secundario). Banner sutil: "Tu ubicación puede no ser precisa". El GPS adaptativo es un plus, no un gate.
05 · Diseño de la solución

Del concepto a las pantallas

Cómo se traduce cada decisión en estructura, jerarquía y pantallas concretas.

El flujo completo

El sistema se articula como un HUB + paradas. La pantalla P1 (Vista de ruta) es el centro de operaciones: el transportista siempre vuelve ahí después de cada acción. Esto simplifica la navegación y da sensación de control.

User Flow — Ruta Flex: Copiloto de entregas
Diagrama del user flow completo (desde inicio de jornada hasta ruta completada)

Wireframes: Exploración en baja definición

Antes de definir el look visual, exploré la estructura y jerarquía de cada pantalla en baja definición. El objetivo era validar que la arquitectura de información funcionara antes de invertir en detalle visual.

Wireframe P0 — Inicio de jornada
P0. Inicio de jornada
Wireframe P1 — Vista de ruta
P1. Vista de ruta
Wireframe P2 — Navegando a la zona
P2. Navegando a la zona
Wireframe P3 — Confirmar entrega
P3. Confirmar entrega
Wireframe P4 — Entrega confirmada
P4. Entrega confirmada

Pantallas en alta definición Supuesto

Las tres pantallas más críticas del flujo, diseñadas sobre el sistema visual de Mercado Libre. Resuelven directamente los pain points identificados en la investigación.

High-Fi P0 — Vista de ruta (inicio)
P0. Vista de ruta (inicio)
High-Fi P1 — Vista de ruta
P1. Vista de ruta
High-Fi P2 — Detalle de parada
P2. Detalle de parada

Diseño para la fricción (cuando el happy path falla)

Un diseño que solo funciona en condiciones ideales no sirve para transportistas en la calle. Estos son los escenarios reales que la propuesta contempla.

🏠 Dirección sin numeración visible
Hoy (inferido) El transportista no encuentra la casa, pierde tiempo buscando y termina llamando al comprador.
Con copiloto P2 muestra la nota del comprador prominente ("Casa azul frente a la plaza"). Si no hay nota, sugiere "¿Necesitás contactar al comprador?" con CTA directo.
📡 Sin señal / modo offline
Hoy (inferido) La app no carga. El transportista queda sin información sobre sus paradas y no puede registrar entregas.
Con copiloto La ruta se cachea al inicio de la jornada. En offline, opera con datos locales y sincroniza al volver. Banner: "Sin conexión — trabajando con tu última ruta".
🚪 Comprador ausente, no contesta
Hoy (inferido) El transportista espera sin referencia de tiempo, o se va sin registrar. Pierde tiempo y no hay feedback.
Con copiloto Timer de espera visible: "Esperando hace 3 min". Después de 5 min, sugiere: "¿No hay nadie? Podés reportar el problema o dejar en lugar seguro".
🏢 Edificio sin portero, comprador en piso alto
Hoy (inferido) El transportista no sabe cómo acceder. Busca instrucciones que están colapsadas en "Datos comprador".
Con copiloto Si hay instrucciones de acceso ("Timbre 3B, esperar"), se muestran prominentes en P2. Si no hay, CTA "Llamar" sigue siendo el fallback principal.
Explorar el flujo en Figma
Recorre las pantallas del flujo propuesto y el detalle del diseño.
Abrir en Figma
06 · Alcance

Alcance: lo que incluí, lo que dejé fuera y por qué

Cada decisión de recorte tiene una razón explícita. Esto es lo que prioricé para el MVP y lo que reservé para iteraciones futuras.

Optimización algorítmica real de rutas
Requiere backend de ruteo que no puedo confirmar que existe. Mi propuesta funciona con o sin él, diseño con fallback incluido.
Disponibilidad y estructura de datos de dirección
Es una dependencia de datos, no de diseño. Diseño para el caso ideal (4 niveles) y para el degradado (texto plano con parsing).
Integración con sistema de Maps (routing en vivo)
Complejidad técnica alta, lo dejo para v3. El MVP resuelve con deep link a Google Maps/Waze: solución probada y sin dependencias internas.
Chat con comprador
Requiere integración con mensajería. En el MVP el contacto se resuelve con "Llamar", que es directo y no genera fricción extra.
Excepciones logísticas (devoluciones, paquetes dañados, reagendamiento)
Flujos que requieren research operativo profundo. El MVP cubre entrega exitosa + "no pude entregar" como punto de partida.
Métricas reales (solo propongo un framework)
No tengo acceso a datos de producción. Planteo hipótesis con baseline estimado, no promesas. El framework está diseñado para ser validable.
Criterio de recorte

Elegí resolver lo que tiene impacto directo en la experiencia del transportista y es implementable sin dependencias externas confirmadas. Lo que dejé fuera tiene un "por qué" explícito y un lugar en el roadmap.

07 · Impacto esperado

Cómo mediría el impacto de este rediseño

Sin acceso a datos de producción, propongo un framework de métricas donde cada indicador tiene una lógica causal: qué debería cambiar, cuánto y por qué.

Estas métricas son hipótesis basadas en benchmark y análisis contextual. Los baselines son estimados y requieren validación en producción.

+2-4 pts
Recuperar NPS perdido Hipótesis
KPI norte. Si la causa es arquitectura de información, el rediseño debería revertir parcialmente la caída. Las métricas proxy son la evidencia real.

Framework de medición Hipótesis

Operativa
20s baseline: 45s (estimado)
Tiempo entre abrir detalle y confirmar entrega
Hipótesis: Reducir de 45s a 20s
Por qué debería moverse: Si la info está visible sin buscar (nombre, dirección, paquetes), el tiempo de resolución baja. Hoy incluye buscar datos colapsados.
CX
–30%+ baseline: alta (inferida)
Tasa de uso del botón "Llamar" por parada
Hipótesis: Reducir 30%+ las llamadas al comprador
Por qué debería moverse: Si la dirección se entiende de un vistazo (4 niveles + mapa inline), el transportista no necesita llamar para confirmar ubicación.
UX
→ 0 baseline: alta (dato colapsado)
Tasa de tap en "Datos comprador" (UI actual)
Hipótesis: Desaparece como interacción necesaria
Por qué debería moverse: Si el dato del receptor ya es visible en la card y en el detalle, nadie lo busca detrás de un chevron. Esta métrica proxy aísla el problema de AI.
Negocio
+5-10% baseline: 20/día (brief)
Entregas completadas por día por transportista
Hipótesis: Aumento de 5-10% sobre baseline
Por qué debería moverse: Menos tiempo buscando info + menos llamadas + ruta optimizada = más entregas completadas por jornada. Es efecto cascada de las otras métricas.
KPI norte
+2-4 pts baseline: –4 pts (brief)
NPS de la app
Hipótesis: Recuperar 2-4 puntos en 8 semanas
Por qué debería moverse: El NPS cayó por insatisfacción con la app. Si las 3 métricas proxy mejoran, eso prueba que el problema era de AI y el NPS debería recuperarse parcialmente.
Lógica de validación

Las 3 primeras métricas son las que prueban que el problema era de arquitectura de información. El NPS es el norte, pero las proxy son la evidencia. Si las proxy se mueven y el NPS no, el problema es otro.

Plan de validación

Fase Método Participantes Qué valida
1 Test de usabilidad remoto (prototipo Figma) 5 transportistas Flex activos ¿Puede completar una entrega sin ayuda?
2 Test de "primer vistazo" (5 seg) 8 transportistas ¿Qué info ven primero? ¿Es la correcta?
3 Entrevista contextual (ride-along) 3 transportistas Validar contexto de uso real (celular, mano, mirada)
4 A/B en producción (post-lanzamiento) Grupo control vs. tratamiento NPS, tiempo por entrega, tasa de llamadas

Riesgos y mitigación

Resistencia al cambio
Transportistas acostumbrados a la UI actual pueden rechazar el rediseño.
✓ Mitigación: onboarding ligero (tooltip en primer uso) + no eliminar funcionalidades existentes
Orden de ruta no óptimo percibido
Si el algoritmo propone un orden que no coincide con la intuición del transportista, pierde confianza.
✓ Mitigación: permitir reordenar manualmente + mostrar "ordenado por cercanía"
Datos de dirección incompletos
Si la dirección no tiene piso/depto, la jerarquía visual queda vacía.
✓ Mitigación: graceful degradation, omitir niveles faltantes sin mostrar "N/A"
Qué cambió
De lista plana sin contexto a copiloto de ruta con información jerarquizada por momento de uso.
Por qué
4 pain points → 1 problema de arquitectura de información. La data existe, la experiencia no la entrega bien.
Framework de validación
3 métricas proxy (tiempo, llamadas, taps) que aislan el problema de AI + NPS como norte. Si las proxy se mueven y el NPS no, el problema es otro.