Case Study · 2026
01 / 10
RolProduct & Content Designer EmpresaMercado Libre · Driver Experience Año2025 Preparado paraACL Tecnología

Reliable
Business
Hours.

Cómo rediseñar un dato plano hasta convertirlo en un sistema que ayuda a miles de conductores a decidir bajo incertidumbre.

Andrés Felipe Díaz · Product Designer
15–20 min
Hook · El contexto real
02 / 10
17:40 · miércoles
5 paradas
Un driver en ruta. Cinco destinos muy distintos entre sí.
01 Local comercial cierra 19:00
02 Oficina laboral salida 18:00
03 Edificio con portería recibe 7–22h
04 Comercio pequeño horario no cargado
05 Residencial sin portería sin datos
El problema real

Cada parada
es un mundo
distinto.

Comercial, laboral, residencial, con portería, sin datos. Cada tipo de ubicación tiene su propia lógica de "¿puedo entregar aquí ahora?".

Y encima de eso, había dos operaciones paralelas: MLP (drivers afiliados en última milla) y Flex (drivers propios, entrega same-day). Mismo problema conceptual, contextos operativos distintos.

¿Cómo diseñas un sistema que le hable a 5 tipos de ubicación × 2 operaciones × N ventanas horarias, sin abrumar al driver?
El diagnóstico inicial
03 / 10
Lo que todos creían al inicio

Dos equipos. Mismo instinto equivocado.

Empezamos en MLP (última milla con drivers afiliados). Cuando el piloto funcionó, escalamos a Flex (operación propia, entrega same-day). En ambos casos el diagnóstico inicial del equipo fue el mismo.

Diagnóstico obvio

Falta data.
Falta horario exacto.
Cárguenlo y listo.

"Si mostramos el horario de cierre, el driver planifica mejor y no llega cuando está cerrado." La solución parecía evidente.

→ Mostrar horario exacto
→ Cubrir todos los casos
→ Delegar la decisión al driver
Lo que descubrimos al mapear el universo

No era falta de data.
Era falta de contexto.

El 51% de paradas comerciales no tenía horario cargado. Del 49% que sí tenía, solo algunos eran confiables. El buyer solo podía cargar horarios de corrido o 24h. Los que tenían portería no sabían si la portería recibía 24h o solo en ventanas limitadas.

→ Data parcial e inconsistente
→ Cada tipo de parada = lógica distinta
→ Dos operaciones con tiempos distintos
El insight que cambió todo
04 / 10
Reframe
Mostrar horarios se vuelve Comunicar contexto

El horario dejó de ser un dato plano. Pasó a ser una señal contextual que combina tipo de ubicación, momento del día, calidad del dato y tipo de operación — y se traduce a un mensaje que el driver puede accionar sin pensar.

Este reframe hizo dos cosas. Uno: abrió el espacio de diseño de "una celda de texto" a "un sistema de estados". Dos: nos permitió escalar la misma lógica de MLP a Flex con adaptaciones mínimas, en lugar de diseñar dos productos paralelos. El framework era el mismo; las variables cambiaban.
Arquitectura del sistema
05 / 10
La solución

Tres dimensiones.
Un framework.
Dos operaciones.

El mensaje que ve el driver se deriva del cruce de tres dimensiones. El mismo framework funciona en MLP y en Flex con adaptaciones en el racional temporal.
Dimensión 1 · Tipo de ubicación
A
Comercial con horario
Local con horario cargado por el seller. Ej: "Abre de 9 a 18 hs".
B
Laboral / Residencial
Domicilio con o sin horario de disponibilidad del receptor.
C
Con portería
Edificio con portería que recibe en horario propio (limitado o 24h).
D
Sin datos
El sistema no tiene información confiable. Hay que comunicarlo honestamente.
Dimensión 2 · Momento del día vs. horario del destino
— 60 min antes de apertura → Planificá · últimos 60 min antes → Ya podés ir · abierto → Podés entregar · 60 min antes de cierre → Apurate · post-cierre → Está cerrado (informativo, no bloqueante)
Dimensión 3 · Operación
MLP · Última milla
Drivers afiliados. Rutas largas con muchas paradas.
Racional: racionalizar horas de despacho y priorizar paradas con ventanas cortas. El umbral crítico: 3h entre despacho y cierre.
Flex · Same-day
Drivers propios. Entrega same-day o siguiente día.
Racional: menos paradas, más urgencia. Horarios laborales y de portería son tan críticos como los comerciales.
Diseño de contenido aplicado
06 / 10
Cómo se ve el output

El mismo framework,
adaptado a cada tipo de parada.

Tres ejemplos de mensajes que el driver ve en la app, derivados del sistema. La copy no se escribe por pantalla: se deriva de la combinación tipo de ubicación + estado temporal + calidad del dato.

Caso A · Comercial, lejos del cierre
Abierto · Cierra a las 18 hs Tenés tiempo para entregar. Horario confirmado por el seller.
Tipo: comercial Dato: alta calidad
Tono informativo. El driver puede seguir con su planificación sin interrumpirse.
Caso B · Comercial, cierre cercano
Cierra pronto · 18 hs Apurate si vas para allá. El comercio cierra en menos de 1h.
Tipo: comercial Estado: <60min a cierre
Accionable, no bloqueante. El driver decide: la app no restringe la marcación.
Caso C · Edificio con portería 24h
Con portería 24 hs Podés dejar el paquete en portería a cualquier hora. No necesitás coordinar con el receptor.
Tipo: residencial Sub-contexto: portería
Un tipo completamente distinto de mensaje. Mismo framework, otra dimensión de la matriz.
Decisiones defendibles
07 / 10
Trade-offs

Las decisiones difíciles
que tocó defender.

Ningún sistema se diseña sin tensiones. Estas son las tres que tuve que resolver con el equipo de producto y engineering.

01
Tensión Producto quería empezar mostrando "más información". Yo argumenté que mostrar un rango horario sin contexto temporal (ej: "De 9 a 18 hs" a las 17:55) era peor que no mostrar nada.
Priorizamos el contexto sobre el dato crudo. El driver ve el estado interpretado ("Cierra pronto") antes que el número.
02
Tensión Ingeniería planteó restringir marcaciones en paradas cerradas o de alto riesgo. Eso le quitaba autonomía al driver y rompía el modelo de confianza.
Acordamos con producto e IT: "se mostrará de manera informativa, no vamos a restringir marcaciones". El sistema guía, no bloquea.
03
Tensión El 51% de paradas comerciales no tenía horario cargado. Ocultarlas era injusto; mostrar "sin datos" era confuso; inventar un rango era peligroso.
Introduje el estado "Con horario comercial" — una señal honesta que indica "sabemos que es comercial, pero no tenemos su ventana exacta".
04
Tensión Escalar de MLP a Flex podía significar rediseñar todo desde cero. Tiempos, operación y tipos de parada eran distintos.
Diseñé el sistema como framework reutilizable desde el inicio. Al escalar a Flex solo hubo que adaptar el racional temporal y agregar los estados de portería.
Impacto medido
08 / 10
Resultados post-implementación

Los números importan.
El patrón importa más.

Delivery Success
95–98%
↑ +3–5 pts
En rutas con visibilidad exacta de horario.
First Visit Delivery Success
92–94%
↑ estabilizado sobre 92%
Consistente tras la implementación del sistema.
Business Closed
0.7–2.4%
↓ hasta −60% en segmentos
Casos de llegada a comercio cerrado reducidos.
Unvisited Address
0.3–0.5%
Tasa mínima mantenida
Direcciones no visitadas en rango controlado.
El patrón que valida la hipótesis
Las rutas con horario exacto visible alcanzaron 98.3% de éxito de entrega.

Mejor información operativa → mejores decisiones en terreno → mayor éxito de entrega. No fue una mejora cosmética. Fue validar que el diseño de información, cuando se hace bien, mueve la métrica que a producto le importa.

Qué aprendí
09 / 10
Aprendizajes transferibles

Diseñar para decisión
no es diseñar
para lectura.

01 · Sistema
La interfaz es la punta del iceberg.
Lo que el usuario ve es el resultado de reglas, variables y estados. El trabajo de diseño pasa por debajo: definir esa lógica antes de diseñar pantallas.
02 · Contenido
La copy es parte del producto, no del final.
No se escribe después del mockup. Se deriva de los estados del sistema y se prueba con los mismos criterios que se prueba un componente.
03 · Incertidumbre
Comunicar duda es más útil que inventar certeza.
Un sistema que admite cuando no sabe algo genera más confianza que uno que oculta la incertidumbre detrás de datos falsamente seguros.
04 · Impacto
Diseñar bien mueve métricas de negocio.
No hay que elegir entre experiencia y eficiencia operativa. Cuando el diseño reduce fricción cognitiva, el negocio lo nota en sus números.
Por qué este caso conecta con lo que hacen en ACL
El conductor en ruta y el equipo B2B comprando tienen el mismo problema estructural: tomar decisiones con información incompleta, bajo presión de tiempo, dentro de un sistema que los acompaña. Diseñar para uno es diseñar para el otro.
Cierre
10 / 10
Gracias por el tiempo
Gracias por su tiempo
Andrés Felipe Díaz R. PRODUCT DESIGNER · BOGOTÁ · 2026
· fin ·