Onboarding digital para Driver App — Tucar 2025
Cómo rediseñé el proceso de activación de conductores nuevos para que sea 100% autogestionado, reduciendo tiempos sin aumentar la carga operativa de un equipo de 8 personas.
Tres cosas que entender antes de seguir.
La empresa
Plataforma chilena de arriendo de vehículos eléctricos para conductores de apps (Uber, Cabify, DiDi). Operación 100% en Chile, en crecimiento acelerado.
El conductor
Personas que viven de manejar 8 a 12 horas al día. Necesitan empezar a facturar lo más rápido posible. Cada día sin auto es un día sin sueldo.
El proceso
Etapa 1 de 3 del nuevo flujo de activación. Cubre desde el registro inicial hasta la verificación documental previa a recibir el vehículo.
Driver app · pantalla principal del onboarding
El proceso anterior no escalaba.
Antes de este rediseño, cada conductor que se registraba pasaba por un flujo manual: WhatsApp con un agente, formularios sueltos, documentos por correo, validación caso por caso.
El equipo de operaciones manejaba esto con planillas de Google Sheets y mucha paciencia. Funcionaba con 30 registros al mes. No funcionaba con 300.
El brief inicial pedía "mejorar el flujo." La pregunta real era otra: ¿cómo hacer que un conductor pueda registrarse, validar sus documentos y agendar la entrega del auto sin hablar con nadie — y sin que el sistema falle cuando lleguen 50 registros un mismo día?
Activación autogestionada, sin sacrificar control.
Diseñar el flujo más corto posible que permita a un conductor: registrarse, validar identidad, subir documentos y quedar listo para agendar entrega del auto — todo desde la app, sin agente de por medio.
Y al mismo tiempo, dejar al equipo de operaciones con visibilidad completa del estado de cada conductor en tiempo real, para intervenir solo cuando algo se rompe.
De la entrevista al prototipo navegable.
Research cualitativo + datos
Entrevisté a 12 conductores recién activados y a las 3 personas del equipo de operaciones que más onboardings hacían. Mapeé el flujo existente paso a paso, cronometré los tiempos reales y crucé eso con los tickets de soporte de los últimos 6 meses para identificar dónde se caían los registros.
Service blueprint + flujos
Reconstruí el journey en un blueprint que cruzaba lo que ve el conductor, lo que pasa en backend y dónde interviene operaciones. Eso volvió obvias las 4 zonas donde el sistema dependía de una persona — y por lo tanto, donde había que automatizar primero.
Wireframes y prototipado
Wireframes en baja, validación con 5 conductores en sesiones moderadas. Iteración. Prototipo en alta fidelidad usando los componentes del design system de Tucar. Validación con 8 conductores más antes de pasar a desarrollo.
Handoff colaborativo
Documenté cada estado, cada caso de error, cada copy. Trabajé directamente con Bastián, Ignacio y Macarena del equipo de desarrollo durante el sprint de implementación, ajustando lo que el código demostraba que estaba mal pensado.
Service blueprint + screens en alta fidelidad
Lo que la investigación cambió del brief.
-
✶
Los conductores no abandonan por dificultad — abandonan por incertidumbre. Si no saben en qué paso están o cuánto les falta, se van.
-
✶
El 70% de los registros se completaban en menos de 10 minutos cuando el flujo era claro. El cuello de botella era la validación documental, no el formulario.
-
✶
Operaciones no necesitaba menos trabajo — necesitaba que el trabajo que hacía fuera más visible para el conductor, para reducir tickets de "¿qué pasa con mi cuenta?"
-
✶
Los estados intermedios (en revisión, requiere acción, aprobado) eran tan importantes como los flujos en sí. Diseñar la espera resultó ser el mayor trabajo de UX.
El nuevo flujo, en pantallas.
Cuatro etapas claras: registro, identidad, documentos, listo para agendar. Cada una con un estado visible, una acción única, y feedback inmediato. Si algo falla, el conductor sabe exactamente qué tiene que arreglar y dónde.
Lo que cambió cuando se lanzó.
Métricas medidas en los primeros 60 días post-lanzamiento, comparadas con el flujo anterior:
de activación de un conductor.
por mes con el mismo equipo de ops.
relacionados con el proceso.
* Reemplaza con métricas reales del proyecto
Diseñar onboardings para gente que vive de la app me enseñó que la claridad no es un nice-to-have — es la diferencia entre que alguien empiece a trabajar mañana o no.