Rediseño de Liquidaciones Tucar
Cómo transformé una liquidación que los conductores tenían que descifrar en una explicación clara: primero el saldo, después su composición, y al final el detalle necesario para confiar en cada cargo.
Arriendo, conducción y una liquidación semanal.
Liquidaciones
La sección donde cada conductor revisa cuánto generó, qué se descontó y cuánto recibirá al cierre de la semana.
Dinero + operación
Ganancias, arriendo, TAG, garantía, bonos, beneficios y ajustes convivían en una misma lectura financiera.
Research + arquitectura
Lideré research, arquitectura de información, prototipo UI y alineación con CX, Producto y Desarrollo.
De una liquidación que se descifra a una explicación que se entiende.
Muchos conductores no llegaban al detalle, convivían con demasiados conceptos y no podían reconstruir con claridad cuánto generaron, qué se descontó y cuánto recibirían.
La consecuencia era operacional: las dudas salían del producto y terminaban en CX. La interfaz no estaba respondiendo la pregunta más importante: “¿por qué recibo este monto?”
No había una única fuente perfecta, había señales.
Crucé tickets y dudas frecuentes, feedback de CX y speakers, conversaciones con conductores, auditoría UI y restricciones reales de Producto + Desarrollo. La meta fue detectar problemas de comprensión para construir una hipótesis de rediseño.

Juan
52 años · Conductor · Tucar
"Necesito ver claro cuánto gano y cuánto me cobran."
Journey map · de la duda al entendimiento
Cuatro insights definieron la dirección.
La información estaba, pero no en el momento mental correcto.
La estructura respondía al sistema, no al modelo mental del conductor.
Cobros y abonos relacionados aparecían separados, aumentando la sensación de falta de trazabilidad.
El detalle debía existir sin competir con el resumen. No simplificar ocultando, sino ordenando.
Service blueprint · qué se activa cuando la interfaz no resuelve la pregunta
De estructura del sistema a modelo mental.
El cambio principal no fue visual: reordené la lectura financiera para responder primero las preguntas del conductor y dejar la lógica interna en un segundo nivel.
La hipótesis fue ordenar la liquidación como una boleta: primero el resultado, luego la composición y después el detalle. Saldo = ingresos − egresos.
Saldo primero; detalle cuando se necesita.
La nueva vista prioriza el resultado financiero y abre camino al detalle sin sobrecargar la primera lectura: saldo a depositar, ingresos, egresos, y trazabilidad por línea para viajes, TAG, arriendo, cargos y beneficios.
Validar comprensión antes que estética.
Test comparativo con 15 conductores. Evaluamos tres tareas: entender el saldo, explicar su composición y encontrar el origen de un cobro. El foco fue comprensión, no estética.
La arquitectura se sostuvo con cambios mínimos.
- ✶
Saldo → ingresos/egresos se mantuvo como estructura principal.
- ✶
Detalle bajo demanda se mantuvo porque no competía con la lectura inicial.
- ✶
La petición más clara fue poder descargar la liquidación en PDF, pendiente por limitaciones técnicas del backend.
- ✶
La fricción residual ya no apuntaba principalmente a la arquitectura, sino a confianza, hábito y capacidades técnicas pendientes de medir.
Cuando el producto maneja dinero, claridad visual es confianza operativa. Este caso demuestra cómo trabajo entre craft visual, reglas de negocio, datos y colaboración con desarrollo para hacer que sistemas complejos se sientan simples sin perder precisión.