Rediseño Driver App — Tucar
Cómo reconstruí la app de conductores de Tucar desde investigación con usuarios reales hasta una interfaz que prioriza claridad de ingresos y visualización de datos operacionales — y que después se convirtió en la base del primer design system de la empresa.
La app que ya existía tenía deuda acumulada.
Driver App
La herramienta principal de los conductores de Tucar. Con ella ven sus ingresos, el estado de su cuenta, alertas, y gestionan el día a día de la operación del vehículo eléctrico.
Deuda visual + funcional
Iteraciones acumuladas sin sistema. Inconsistencias entre pantallas, jerarquías confusas, y drivers reportando diariamente que no entendían sus liquidaciones ni sus balances.
Base para escalar
Rediseño completo como cimiento para construir el Design System de Tucar — pensando en cada feature futura, no solo en la app actual.
Driver app · home & liquidaciones versión antigua
Los drivers no confiaban en lo que veían.
El principal hallazgo fue que los conductores no entendían cómo se calculaban sus ingresos. El cálculo era correcto; la interfaz no lo estaba mostrando bien.
Resultado: tickets diarios al soporte del tipo "me están cobrando mal" cuando en realidad era un problema de claridad visual, no de backend. El problema de producto más caro no era un bug, era una mala jerarquía.
Los números que confirmaron la hipótesis.
Antes de diseñar una sola pantalla, encuesté a los conductores activos para dimensionar el problema. Los datos fueron claros: la app no estaba cumpliendo ni en satisfacción ni en comprensión de la información financiera.
Cuatro drivers, un mismo patrón.
Entrevistas cualitativas con conductores activos. El patrón fue consistente: todos desconfiaban de la información financiera que mostraba la app y todos compensaban con cálculos manuales.
A veces la información no es confiable. Debo comparar mis ganancias de Tucar con las de Uber o hacer cálculos propios.
Rodrigo G. · ConductorNo logro entender las diferencias de penalizaciones y multas. Me gustaría que hubiera más claridad en la información.
Carlos L. · ConductorMuchas veces no logro saber cuáles son los cargos en mis liquidaciones. Me gustaría ver los motivos.
Camila S. · ConductoraLiquidaciones y balance es la misma información. Podrían evaluar el agregar las ganancias y así tener claridad de las recaudaciones.
Andrés M. · ConductorConoce a Juan.
Basado en las entrevistas y datos cuantitativos, construí el arquetipo principal que representaba al 70%+ de los conductores de Tucar.
Juan
52 años · Conductor · Tucar
"Es importante para mí tener una aplicación que me ayude a visualizar claramente el costo de mi plan de arriendo, así como los pagos que debo realizar a Tucar y los descuentos asociados."
Wireframes
Seis hallazgos que definieron el rediseño.
La información de multas y cobros debe ser más detallada. Los drivers necesitan las razones, no solo los montos.
El diseño y jerarquía debe ser lo más minimalista y simple posible. Cada elemento extra es fricción × 10 horas al día.
El inicio debería mostrar un resumen general de la semana: cuánto gané, cuánto debo, qué queda.
Necesitan saber qué tótems de carga están funcionando — un mapa en tiempo real con disponibilidad.
Las liquidaciones deben mostrar toda la información y ser explicativas. No un PDF descargable — datos en pantalla.
Opción de descargar datos en Excel o enviar por correo — para drivers que llevan registro propio.
Research, auditoría y sistema.
Research con drivers reales
Encuestas cuantitativas + sesiones de usabilidad con conductores activos, grabando pantalla mientras navegaban sus liquidaciones. El patrón fue claro: se perdían en la misma pantalla, todos. Crucé eso con tickets de CX de los últimos 6 meses.
Auditoría del UI existente
Mapeé cada componente repetido en la app. Encontré 14 variantes del mismo botón, 3 tipografías diferentes, y 8 formas de mostrar dinero. Base perfecta para proponer un sistema unificado.
Design System desde cero
Construí el primer Design System de Tucar: tokens de color (primitivos + semánticos), tipografía escalada, componentes base. Dark + light mode desde el día uno. Reducción de ~25% en retrabajo de UI.
Wireframes, testeo e iteración
Prototipos en baja → testing con conductores → iteración → alta fidelidad usando los componentes del nuevo design system → segundo round de testing antes de pasar a desarrollo.
Los prototipos antes de construir.
Antes de pasar a desarrollo, testeé los wireframes con conductores reales para validar que las decisiones de diseño se sostenían fuera del Figma.
User Journey Map
La app rediseñada, en pantallas.
+105 pantallas nuevas construidas sobre el design system. Jerarquía clara de información financiera, navegación simplificada, y estados de cuenta que los drivers pueden leer sin comparar con Uber.
72 personas encuestadas, los números hablan.
de los flujos críticos.
implementar el design system.
las nuevas funcionalidades.
El feedback negativo es el más útil.
No todo fue positivo — y eso es parte del diseño. Estos fueron los hallazgos que informaron las iteraciones siguientes del producto.
Quiere desglose detallado de descuentos aplicados.
Sugirió ver ganancias en tiempo real, no al cierre.
Problemas con apertura y cierre de puertas del vehículo.
Problemas puntuales de navegación entre secciones.
- ✶
Cuando la UI muestra dinero, cada decisión visual es también una decisión de confianza. Un número mal jerarquizado se lee como estafa.
- ✶
El mayor valor de un rediseño no es lo nuevo, es la oportunidad de construir el sistema que debería haber existido desde el principio.
- ✶
Los drivers no necesitan dashboards impresionantes. Necesitan certeza sobre un solo número: cuánto cobraron hoy.
480 horas de trabajo me enseñaron que mover un número 4 pixeles puede ser la diferencia entre un driver que confía en la plataforma y uno que la abandona. El diseño basado en research no es un lujo — es el mínimo necesario.
Descargar caso de estudio