Banndo
Rediseñé desde Arenga la app mobile de Banndo, una plataforma que conecta marcas con conductores para campañas de publicidad en vehículos. El trabajo combinó auditoría UX/UI, modernización visual y definición de flujos para onboarding, documentación, vehículos y campañas.
Contexto
Banndo ya tenía una app, pero necesitaba una revisión profunda.
La propuesta de negocio era clara: permitir que conductores generen ingresos extra usando sus vehículos como soporte publicitario, mientras las marcas acceden a campañas móviles en la calle.
El problema era que esa claridad no estaba completamente traducida en el producto.
La experiencia existente estaba visualmente desactualizada, con inconsistencias de UI, baja jerarquía, problemas de legibilidad, componentes poco escalables y una percepción general que no transmitía la confianza necesaria para operar con datos personales, documentación y campañas activas.
El foco principal del rediseño era el conductor: una persona que se registra, carga sus datos, vincula su vehículo, sube documentación, espera aprobación y luego puede aplicar o participar en campañas de publicidad móvil.
El problema
La app tenía pantallas, pero todavía no tenía una lógica de producto lo suficientemente clara.
No estaba definido de forma consistente qué pasaba cuando un conductor cargaba documentación, cuándo algo quedaba en revisión, cuándo se aprobaba, qué bloqueaba la participación en campañas o cómo se diferenciaba el estado del usuario del estado del vehículo.
Además, varios flujos estaban incompletos o abiertos: registro, onboarding, datos personales, carga de vehículo, documentación, validación de identidad, campañas disponibles, postulación, campaña activa, soporte y visualización de métricas o ganancias.
El problema no era solo visual. Era de claridad operativa.
Una app de este tipo necesita que el usuario entienda todo el tiempo tres cosas: qué ya está aprobado, qué falta completar y qué puede hacer ahora. Si eso no está claro, el conductor no sabe si está listo para aplicar a una campaña o si todavía hay algo bloqueando su participación.
Approach
Dos principios guiaron el rediseño.
Auditar antes de rediseñar. Antes de modernizar la interfaz, necesitábamos entender qué flujos existían, cuáles estaban incompletos y dónde la experiencia se rompía. Si empezábamos por la UI, corríamos el riesgo de hacer más atractivo un producto que seguía teniendo los mismos baches.
Diseñar estados, no solo pantallas. El producto dependía de estados: conductor aprobado, vehículo pendiente, documentación en revisión, campaña disponible, campaña activa, datos incompletos. La app necesitaba una gramática clara para mostrar esos estados sin obligar al usuario a interpretar qué significaba cada situación.
La dirección visual buscó llevar la app hacia un tono más tech, moderno y confiable, sin romper la lógica operativa que el equipo ya venía construyendo.
Decisiones clave
Ordenar el onboarding alrededor del estado del conductor y del vehículo
El onboarding no podía ser un formulario largo donde todo tuviera el mismo peso.
El conductor necesitaba crear su perfil, cargar información personal, vincular un vehículo y completar documentación. Pero no todos esos pasos tenían la misma lógica ni desbloqueaban lo mismo.
La decisión fue ordenar la experiencia separando claramente el estado del conductor y el estado del vehículo. El usuario podía entender si el problema estaba en su perfil, en los datos del auto, en la documentación o en la validación general para participar en campañas.
Esto permitió que el onboarding dejara de sentirse como una lista indefinida de tareas y pasara a funcionar como un proceso guiado hacia un objetivo concreto: quedar habilitado para aplicar a campañas.
Lo que descartamos: resolver todo en un único flujo lineal sin jerarquía. En productos con documentación y validación, un formulario largo no simplifica la experiencia; solo esconde la complejidad.
Diseñar estados claros para documentación y aprobación
El producto anterior no tenía una lógica clara de estados.
Eso era un problema crítico porque la documentación define si un conductor puede avanzar o no. Si un documento está pendiente, en revisión, aprobado o rechazado, la interfaz tiene que decirlo de forma explícita y accionable.
La decisión fue construir una gramática de estados para documentación, vehículo y aprobación. Cada estado debía explicar qué estaba pasando, qué significaba para el usuario y qué acción podía tomar.
No alcanzaba con poner un badge de color. Un estado útil necesita contexto. “En revisión” no significa lo mismo que “requiere corrección”. “Aprobado” no significa lo mismo que “listo para aplicar”. La app tenía que hacer visibles esas diferencias.
Lo que descartamos: usar estados genéricos tipo “pendiente” para todo. Son fáciles de implementar, pero trasladan la incertidumbre al usuario. Si todo está pendiente, nada está realmente explicado.
Modernizar la UI sin romper la lógica operativa existente
Banndo necesitaba una app más moderna, más consistente y más confiable. Pero el rediseño no podía transformarse en una reinterpretación completa del producto desde cero.
La decisión fue mejorar la UI sin desconectarla de la operación real que el equipo necesitaba validar. Trabajamos sobre jerarquía, legibilidad, consistencia de componentes, navegación, estados y percepción de marca, pero respetando los flujos principales que el negocio necesitaba sostener.
El objetivo no era que la app pareciera otra cosa. Era que se sintiera como una versión más clara, robusta y escalable de lo que Banndo ya estaba intentando construir.
Lo que descartamos: priorizar visual antes de entender los flujos. También descartamos crear una experiencia distinta para cada campaña en esta etapa. Antes de personalizar cada caso, la app necesitaba una base común que funcionara para cualquier campaña.
Solución
El resultado fue un rediseño completo de la app mobile orientada principalmente a conductores.
La experiencia quedó organizada alrededor de los momentos principales del usuario: registro, onboarding, carga de datos personales, carga de vehículo, documentación, validación, campañas disponibles, postulación, campaña activa, soporte y visualización de métricas o ganancias.
La app permite que el conductor entienda su estado general y avance paso a paso hacia la posibilidad de participar en campañas. La documentación deja de ser una sección aislada y pasa a formar parte de un sistema de habilitación más claro.
También se trabajó una UI más moderna, tech y confiable, con componentes más consistentes, mejor jerarquía visual y una relación más sólida con la marca.
El rediseño no buscó agregar complejidad. Buscó hacer visible la operación real del producto: qué necesita el conductor, qué necesita validar Banndo y qué condiciones deben cumplirse para que una campaña pueda activarse.
Impacto
El rediseño dejó una app más clara, consistente y preparada para desarrollo, con flujos mejor definidos para onboarding, documentación, vehículos y campañas.
También ayudó al equipo a ordenar decisiones de producto que antes estaban abiertas, especialmente alrededor de estados, aprobación y participación del conductor.
La nueva estructura permitió separar mejor lo que pertenece al perfil del usuario, lo que pertenece al vehículo y lo que pertenece a la documentación requerida para operar.
Visualmente, la app pasó de una experiencia poco consistente y difícil de escalar a una interfaz más moderna, confiable y alineada con la propuesta tecnológica de Banndo.
Más que un cambio estético, el proyecto ayudó a convertir pantallas sueltas en una experiencia mobile más operable y validable.
Reflexión
Banndo me recordó que un rediseño no siempre empieza por hacer que algo se vea mejor.
Muchas veces, antes de tocar componentes o colores, hay que entender qué lógica de producto está incompleta. En este caso, el mayor problema no era solo la interfaz anterior, sino la falta de estados claros para explicar qué podía hacer un conductor y qué lo estaba bloqueando.
También fue un buen ejercicio de equilibrio: modernizar sin romper. El producto necesitaba mejorar visualmente, pero también respetar una lógica operativa que el equipo ya estaba construyendo y necesitaba validar.
Lo que haría diferente: hubiese formalizado desde el inicio un mapa completo de estados del conductor, vehículo y documentación. En productos operativos, ese mapa termina siendo casi tan importante como el flujo principal, porque define cómo el sistema responde cuando las cosas no avanzan de forma ideal.
