Caso · Fintech regional

Onboarding para fintech de pagos

Flujo de alta en cuatro pasos con verificacion progresiva

La version original pedia todos los datos en una sola pantalla y el abandono aparecia apenas en el segundo campo. Reorganizamos el alta en cuatro etapas: identidad, datos fiscales, cuenta bancaria y confirmacion. Cada paso deja claro que falta y que ya quedo validado, y los errores se explican junto al campo que los origina, no en un resumen al final.

La maqueta navegable incluye variantes para usuario nuevo, usuario invitado por un comercio y reintento tras un rechazo de verificacion.

Pantalla de alta de usuario en una fintech con pasos de verificacion y campos de identidad

El problema

Un formulario unico de doce campos mezclaba datos personales, fiscales y bancarios. El usuario no sabia cuanto le faltaba ni por que le pedian cada cosa en ese orden.

El enfoque

Verificacion progresiva: cada paso valida antes de avanzar, muestra el estado del tramite y permite volver sin perder lo cargado. Los mensajes de error viven al lado del campo.

La implementacion

Cuatro pantallas con barra de progreso, estados de carga y reintento. Se documentaron tokens de color para validado, pendiente y rechazado, con contraste verificado.

Lo que cambio en el alta

El orden de los pasos sigue el nivel de friccion: primero lo que el usuario tiene a mano, despues lo que requiere buscar un papel o abrir el home banking. La confirmacion final resume lo validado y evita el clasico "revisa todo otra vez".

  • Paso 1 · Identidad Nombre, documento y fecha de nacimiento con validacion en linea.
  • Paso 2 · Datos fiscales CUIT y condicion ante el organismo, con ayuda contextual.
  • Paso 3 · Cuenta bancaria CBU o alias, con verificacion de titularidad antes de continuar.
  • Paso 4 · Confirmacion Resumen de lo validado y estado del tramite en curso.

Resultado del caso

El alta dejo de ser una pared de campos y paso a ser un recorrido con estado visible. Los errores recuperables se resuelven en el mismo paso, y el reintento tras rechazo conserva lo ya validado en lugar de reiniciar el tramite.

Ver otros casos en projects.html o revisar el enfoque en solutions.html.

Otros casos del catálogo

Cada pieza arranca de un problema concreto de producto y termina en una maqueta que se puede recorrer. Estas son las tres que mejor muestran cómo trabajamos el alta de usuario, la lectura de datos en operación y el orden de un sistema de componentes.

Pantalla de alta de usuario en una fintech con pasos de verificacion y campos de identidad

Onboarding

Onboarding para fintech de pagos

Flujo de alta en cuatro pasos con verificación progresiva

El alta original pedía todo en una sola pantalla y perdía usuarios en el segundo campo. La reorganizamos en cuatro pasos: identidad, datos fiscales, cuenta bancaria y confirmación. Cada paso indica qué falta y qué ya quedó validado, y los errores se explican junto al campo que los origina. La maqueta cubre usuario nuevo, invitado por un comercio y reintento tras rechazo.

Ver el caso completo
Tablero de control de entregas urbanas con mapa, lista de envios y estados de incidencia

Dashboard

Dashboard operativo para logística urbana

Tablero de entregas con jerarquía por urgencia y filtros por zona

Operaciones seguía los repartos en una planilla compartida y cruzaba zona con estado del envío a mano. La maqueta propone tres niveles de lectura: resumen del día, lista por zona y detalle del envío. Las incidencias se marcan con color y texto para que sigan siendo legibles en pantallas mal calibradas. Quedan documentados los estados vacío, cargando, con datos y con error de sincronización.

Ver el caso completo
Documentacion de un sistema de componentes con tokens de color, tipografia y variantes de botones

Sistema de diseño

Sistema de componentes para un marketplace de servicios

Tokens, variantes y estados documentados para un equipo de tres personas

El marketplace sumaba pantallas cada sprint y cada una resolvía botones, campos y tarjetas a su manera. Partimos de tokens de color, espaciado y tipografía, y definimos componentes con sus variantes y estados: reposo, hover, foco, deshabilitado y error. Cada componente lleva notas de accesibilidad sobre contraste, foco visible y área táctil mínima, pensadas para alguien que recién se suma al equipo.

Ver el caso completo

Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.