Closer
Contexto
Los gerentes de agencias necesitan gestionar sus áreas de reparto, pero no cuentan con un apoyo visual y necesitan mucho tiempo para hacer estimaciones en base a varios documentos que no siempre están actualizados.
Objetivo
Centralizar y facilitar la gestión del reparto, con información de la carga de trabajo y capacidad de organizar refuerzos de manera ágil, sin tener que recurrir a varias herramientas.
Mi rol
Lideré el diseño UX/UI de principio a fin para este proyecto.
Trabajé en estrecha colaboración con el equipo de producto, desarrollo y responsables de operaciones para comprender los principales puntos de fricción y necesidades de los usuarios finales.
Rediseñé la arquitectura de la información y los flujos clave, agrupando el contenido de forma lógica para mejorar la usabilidad y contemplando excepciones, estados de error y casos límite.
Definí y documenté patrones reutilizables para sentar las bases de un sistema de diseño adaptable a otras herramientas internas.
Resultados y métricas
Usado en +80 agencias de reparto
Tiempo de trabajo reducido de 40-90 minutos a 10-15 minutos
Aumenta la confianza en datos, reduciendo uso de múltiples fuentes de información
Lanzado con éxito en España y expandido a Portugal
Proceso de trabajo
Investigación
Antes de empezar a diseñar, era importante entender bien el contexto y las necesidades reales de quienes iban a usar la herramienta, y sobre todo tener bien definido el problema que tenemos que resolver.
Para esto realicé entrevistas a usuarios clave: gerentes de agencia. La entrevista la centré en entender sus tareas del día a día para comprender su forma de trabajo, y luego centramos el resto de preguntas en el proceso de planificación de reparto. Algunos usuarios tenían acceso a una herramienta anterior que estaba quedando en desuso, así que para las entrevistas decidí incluir pantallazos de ejemplo para que me expliquen las fallas de esa herramienta y también los puntos fuertes.
Las entrevistas me sirvieron para entender no solo qué les frustraba, sino también qué soluciones improvisaban para compensar esas carencias. Por ejemplo, muchos sacaban la información de una mezcla de varias herramienta, confiaban poco en la información, y se apoyaban en grupos de whatsapp para comunicar la información, lo que hacía el proceso muy poco escalable.
Este proceso de investigación me permitió aterrizar varios puntos clave:
Los gerentes no contaban con una visualización clara y centralizada de las zonas.
No contaban con una manera sencilla de identificar en un mapa zonas personalizadas, lo que les limitaba mucho a usar los CP como zonas.
La planificación se hacía “a ojo”, y con mucha carga sobre la experiencia personal. Un usuario con menos experiencia no podría sacar la misma cantidad de información, o no sabría de dónde sacarla.
No había una forma sencilla de estimar la carga de trabajo ni de redistribuir los recursos en tiempo real.
Con esto pude definir un problema clave en el que enfocarme:
“Gerentes de agencias de reparto necesitan una forma visual y eficiente de planificar zonas de entrega, ya que actualmente carecen de herramientas para ver el territorio, estimar carga de trabajo y asignar refuerzos con antelación. Esta falta de visibilidad dificulta la toma de decisiones y afecta directamente la eficiencia operativa.”
El siguiente paso fue empezar a traducir los aprendizajes en ideas de diseño.
Wireframes
A partir de los requisitos funcionales, elaboré wireframes de baja fidelidad que me ayudaron a alinear expectativas con los distintos stakeholders y validar las primeras ideas de interfaz y flujo.
Durante esta fase, exploré distintas formas de representar información geográfica, visualizar volúmenes estimados y permitir acciones sobre zonas concretas, buscando siempre un equilibrio entre claridad y facilidad de uso.
La acción principal era crear zonas directamente sobre un mapa, por lo que realicé un pequeño ejercicio de benchmarking. Me fijé especialmente en cómo lo resolvían productos consolidados como Google Maps, en la visualización de datos, e Idealista, en la creación de zonas editables en el mapa.
Al compartir los wireframes con perfiles tanto de desarrollo como de negocio, fue más fácil alinear expectativas sobre el funcionamiento del producto y entender el impacto técnico de cada alternativa en términos de complejidad y tiempos.
Aunque los wireframes cumplieron su función principal, noté cierta dificultad al presentarlos a personas sin perfil técnico: algunos interpretaron que se trataba de la versión final del producto, a pesar de haber aclarado previamente que era una propuesta inicial de estructura y flujo. Esto me hizo reforzar aún más el contexto y las explicaciones en futuras sesiones de validación.
Prototipado
Diseñé pantallas de alta fidelidad y desarrollé un prototipo interactivo para testear los flujos principales: visualización de zonas, creación, edición, y asignación de refuerzo. Trabajé especialmente en la claridad visual y jerarquía de datos.
Para facilitar la comprensión presenté los prototipos junto con videos cortos usando Loom. De esta forma pude conseguir feedback claro y efectivo.
Con los flujos validados en wireframes, pasé a construir un prototipo interactivo que nos permitiera probar la herramienta en un entorno más realista y facilitar la conversación entre perfiles técnicos, negocio y usuarios.
El objetivo principal era validar el proceso para realizar tareas clave, como crear zonas, revisar la carga estimada o reasignar zonas entre agencias. También me interesaba ver si la interfaz facilitaba la toma de decisiones sin necesidad de información de aplicaciones externas.
Durante esta fase ajusté microinteracciones, jerarquías visuales y la forma de mostrar los datos sobre el mapa, basándome en feedback de sesiones internas. El prototipo fue clave para detectar mejoras pequeñas pero relevantes, como la necesidad de resaltar zonas sin asignar o mostrar información de carga al hacer hover, y también mejoras más avanzadas como la capacidad de crear zonas en base a localizaciones específicas o determinar días de funcionamiento.
Retos y aprendizajes
Uno de los principales retos fue hacer comprensible la funcionalidad completa sin sobrecargar la interfaz con datos.
En una primera iteración encontramos un problema grave de rendimiento: cada agencia de reparto puede tener un orden de 10.000 o 14.000 paquetes previstos para un único día. Mostrar esto en el mapa desde un inicio hacía que la aplicación fuera muy lenta, llegando a bloquear algunos ordenadores.
La solución a este problema vino por dos frentes: primero decidimos no cargar toda la información en el mapa desde una primera instancia, sino que se hace necesario elegir una “fecha de llegada a agencia” y luego clickar en un botón para cargar los paquetes en mapa. Por otro lado, conseguimos reducir los tiempos de carga de datos simplemente cambiando los marcadores de puntos en mapa. En lugar de mostrar un icono “pin” en cada coordenada, lo que decidimos fue mostrar solamente un punto. Esto hizo que la cantidad de capas renderizadas en el navegador se viese muy reducida, optimizando los tiempos de carga de datos.
