Kanguro Counter APP — Scanner

Diseñar una herramienta de logística para personas que nunca habían tocado un ordenador.

Rol Product Designer
Año 2023
Tipo Startup · Equipo internacional 🇪🇸 🇩🇪 🇮🇳 🇸🇾
Plataforma iOS · Android
Herramientas
Figma Material Design 3 React Native Paper Firebase Crashlytics
Carriers integrados
Amazon UPS GLS Ontime Paack
Ver prototipo en Figma
Kanguro Counter App en uso en un Kanguro Point
+2.700 Kanguro Points activos en España, Portugal y Alemania
2.900 usuarios activos mensuales
99,9% crash-free en Android

Desafío

Logística para personas que nunca habían tocado un ordenador

Kanguro conecta grandes transportistas — Amazon, UPS, GLS, Ontime, Paack — con una red de comercios locales donde los clientes recogen sus paquetes. Alguien tiene que gestionar esos paquetes en cada punto, y ese alguien es el dueño de una mercería o una peluquería que ese día también tiene que atender clientes, cuadrar la caja y gestionar su negocio. El producto se desarrolló íntegramente en inglés: el equipo de ingeniería estaba distribuido entre Siria, India y Alemania, y era la única lengua común. Por eso las pantallas son en inglés. Había una app en producción. Funcionaba. Pero los kounters — los dependientes de los puntos — escaneaban paquetes sin saber con certeza qué estaban haciendo.

El reto no era solo de UI. Era de comprensión: hacer que alguien sin contexto logístico ejecute bien, sin error, con un cliente esperando al lado.

Investigación

Antes de tocar Figma, fui a los puntos

Visité comercios con y sin experiencia logística previa. La diferencia era notable: los primeros entendían el vocabulario; los segundos necesitaban que todo fuera autoexplicativo. Observé cómo trabajaban y conduje dos rondas de entrevistas — una para entender el contexto, y una segunda ya con una primera versión diseñada, para recoger feedback directo sobre la app.

Observación en campo

Visité los puntos sin intervenir. Observé cómo los kounters procesaban paquetes reales, dónde se bloqueaban, qué ignoraban y qué consultaban con sus compañeros. Sin guión, sin preguntas — primero entender, luego preguntar.

Entrevistas semiestructuradas × 2 rondas

Ronda 1: descubrimiento contextual — qué entendían del proceso logístico y qué no. Ronda 2: validación con una primera versión diseñada. Dos momentos distintos del proyecto, dos objetivos distintos.

Jobs to be Done

El marco que ordenó los insights. El job central del kounter: "Cuando llega un repartidor o un cliente, quiero registrar la operación rápido y sin error, para poder volver a atender mi tienda sin quedarme con la duda de si lo hice bien."

El insight clave: el problema no era falta de habilidad. Era falta de contexto. Un kounter que lleva veinte años atendiendo su tienda puede aprender cualquier proceso — si ese proceso está explicado en su idioma, no en el idioma de la logística.

Exploración

El proceso empezó en papel

Antes de abrir Figma, necesitaba resolver si tenía sentido unificar los distintos tipos de transacción en un solo punto de entrada. El sketch de flujo fue el artefacto más importante del proyecto — el rombo de decisión en el centro y la anotación "combinar flujo correcto" son el momento exacto en que nació la lógica de la app. De ahí pasé directamente a alta fidelidad, documentando cada flujo completo antes de diseñar pantalla a pantalla.

Sketch en papel del flujo de escaneo — rombo de decisión y anotaciones
El sketch donde nació la lógica de "escanea primero, decide después" — el rombo de decisión en el centro es la solución.

Los flujos de usuario se muestran con detalle reducido por acuerdo de confidencialidad. El contenido completo está disponible en conversación directa.

Flujo Figma "Parcels from DD to Counter" — estados Created, Dropping y Dropped-off
El flujo principal del repartidor: desde que llega con paquetes hasta que quedan registrados en el counter con validación completada.
Detalle del flujo Counter a Recipient con ramificaciones por carrier
El flujo Counter → Recipient es el más complejo: la ramificación inferior muestra cómo la misma pantalla de validación gestiona estados distintos según carrier.

Antes · Después

Antes

La versión anterior partía de una premisa incorrecta: que el kounter ya sabía qué estaba haciendo cuando abría la app. La home pedía escanear sin contexto. El scanner no diferenciaba entre recibir y entregar. El sistema visual — amarillo intenso, cyan, ilustraciones 3D decorativas — priorizaba la energía visual sobre la claridad operativa.

Después

El rediseño parte del problema real: orientar al kounter antes de que cometa un error, no después. Cada pantalla tiene una sola pregunta. El sistema visual desaparece para que el contenido no tenga competencia.

Comparativa antes/después de la Counter App — fila superior versión antigua en amarillo y cyan, fila inferior versión rediseñada con Material Design 3
Arriba: versión anterior — la home solo decía "Escanea el QR", sin contexto de acción ni carrier. Abajo: versión rediseñada con MD3, orientación previa al escaneo y estructura de un solo paso.

Decisiones de diseño

Escanea primero, decide después

La versión anterior obligaba al kounter a decidir el tipo de transacción antes de escanear. El problema: muchas veces no lo sabían. Invertí la lógica. Escaneas primero. Después, la app muestra una confirmación con las opciones posibles en ese contexto: ¿estás recibiendo este paquete del repartidor o entregándoselo al cliente? Una pregunta clara, con ilustraciones de cada persona, no iconos abstractos.

El kounter ya no necesita saber de logística para usar la app. Solo necesita saber quién tiene delante.

Flujo completo de escaneo — lógica invertida
Home · Scanner · Confirmation Overlay — el flujo completo en alta fidelidad
Escáner con confirmation overlay y pantalla Parcel Validated
Escáner — confirmation overlay con la acción contextual y confirmación de paquete validado
Overlay de confirmación tras el escaneo
Scanning Confirmation Overlay — opciones contextuales con ilustraciones, no iconos abstractos

Una pantalla, toda la complejidad absorbida

Cada transportista requiere pasos distintos al entregar un paquete: firma, PIN, cobro en metálico, documentación aduanera. Gestionar cuatro carriers con requisitos distintos podría haberse traducido en cuatro flujos diferentes. Diseñé una pantalla de validación única con widgets condicionales que aparecen o desaparecen según lo que ese paquete concreto necesita. El kounter siempre ve la misma estructura: una lista numerada de pasos.

Para el kounter, siempre es la misma experiencia. La complejidad del sistema queda absorbida por el diseño.

Flujo de validación adaptativa para los cuatro carriers
Misma estructura, widgets condicionales según carrier — firma · PIN · cobro · documentación
Pantalla de validación con firma digital
Validación con firma — el widget aparece solo cuando el carrier lo requiere
Pantalla de validación con PIN de entrega
Validación con PIN — mismo layout, distinto widget condicional

El sistema que alineó diseño y desarrollo desde el día uno

Los desarrolladores usaban React Native Paper, una implementación de Material Design para React Native. La versión anterior ignoraba ese sistema y generaba una UI inconsistente que los devs tenían que lidiar constantemente. Construí el design system sobre Material 3: alineó diseño y desarrollo, redujo la deuda técnica desde el día uno y me dio componentes accesibles y consistentes sin construirlo todo desde cero.

No fue la elección obvia. Fue la correcta: elevar a decisión de diseño el sistema que los devs ya usaban.

Portada del Kanguro Design System v1.3 — basado en Material 3
Kanguro Design System v1.3 — construido sobre Material 3, compartido entre diseño y desarrollo
Componentes de botones del Kanguro Design System — Buttons, FAB, Icon button, Segmented button
Biblioteca de componentes — Buttons, FABs, Icon buttons y Segmented buttons documentados con todas sus variantes
Canvas del Kanguro Design System — tipografía y guía de color en vista completa
Vista de canvas — tipografía Nunito Sans y Color Guidance con paleta tonal y Light Theme documentados
Mano escaneando una etiqueta de paquete con la Counter App
El scanner en uso — frame de detección activo sobre la etiqueta del paquete
Pantalla de validación de la Counter App sobre superficie geométrica de colores
Pantalla de validación — tres pasos completados, listo para confirmar la entrega
Counter App en producción — activa en +2.700 puntos
Counter App en producción — España, Portugal y Alemania

Resultado

Infraestructura real, no side project

La primera versión llegó a producción en 3 meses. A día de hoy, la Counter App está activa en más de 2.700 Kanguro Points en España, Portugal y Alemania, con cerca de 2.900 usuarios activos mensuales y una estabilidad técnica del 99,9% crash-free en Android y 99,3% en iOS.

No son métricas de un side project. Es infraestructura de producción real, usada a diario por personas que no eligieron ser operadores logísticos — y que ahora ejecutan ese rol con fluidez.

Reflexión

Este proyecto me enseñó que diseñar para usuarios con baja familiaridad tecnológica no significa simplificar hasta vaciar: significa entender qué información es imprescindible y cuál es ruido, y tomar decisiones claras sobre esa diferencia. También aprendí a moverme sin red — fui el único perfil de producto durante todo el proceso, sin PM ni otro diseñador, y tuve que defender el espacio para investigar en un entorno donde todo iba a correr. Esa semana de visitas y entrevistas fue un lujo que tuve que justificar. Y que cambió el producto.

Activo en producción.

+2.700 puntos. Expansión internacional en curso.

Hablemos del proceso

Otros proyectos