Un proceso que frenaba
el crecimiento del negocio

La evaluación para leasing abarcaba múltiples etapas —primer contacto, evaluación, aprobación, formalización y posventa— pero el flujo entre ellas era fragmentado y manual. Un caso podía tardar varios días desde el primer contacto hasta la aprobación final, impactando directamente la experiencia del cliente y la tasa de conversión.

A nivel interno, el backoffice enfrentaba reprocesos constantes por información incompleta. La carga se concentraba al final del mes y el modelo dependía de tareas manuales que hacían inviable escalar sin multiplicar recursos humanos y costos operativos.

Cómo diseñé
el proceso de discovery

Material visual 01 — Artefactos de análisis

Lo que encontramos
detrás del proceso

El análisis reveló que los problemas no eran fallas aisladas, sino síntomas de un diseño de proceso que nunca fue pensado para escalar.

Portafolio de iniciativas
para transformar el modelo

Del análisis emergió un portafolio de cuatro iniciativas priorizadas por impacto y viabilidad, orientadas a reducir fricción, automatizar lo repetible y liberar capacidad humana para lo que importa.

Hoja de ruta

Hacer que el agilismo
tenga sentido en la práctica

El cliente no necesitaba otra capacitación de Scrum donde los participantes toman nota y olvidan al día siguiente. Necesitaba que distintos equipos internos vivieran el método: que entendieran por qué el backlog existe, qué hace realmente un Product Owner y cómo negociar prioridades cuando todos tienen urgencias.

El reto de diseño era claro: traducir conceptos abstractos en experiencias concretas y transferibles, en un único día, con grupos mixtos en cuanto a rol y experiencia previa.

Cuatro dinámicas que
hacen vivir los conceptos

Investigué qué dinámicas se usan en este tipo de formación ágil y adapté cuatro de ellas al caso del cliente. El aporte no estuvo en inventar los juegos —son formatos conocidos en la comunidad de facilitación— sino en elegirlos, personalizarlos y ordenarlos: cada participante experimenta el problema antes de que alguien le explique el concepto, y la secuencia sube en complejidad de la comunicación individual a la simulación de negocio completa.

Un mes acompañando
las ceremonias reales

El taller era el punto de partida, no el entregable. Durante un mes acompañamos a los equipos de forma virtual, entrando como observadores a las ceremonias que ellos mismos iban montando. Ver el método en su contexto real —y no en una simulación— fue lo que permitió detectar dónde se trababan y despejar las dudas concretas de cada equipo.

Diseño de la experiencia
de aprendizaje

• Investigación de formatos — qué dinámicas se usan en formación ágil y cuáles servían para este cliente
• Diseño de las dinámicas — personalización de las cuatro mecánicas y el debriefing de cada una
• Secuencia de la jornada — el orden en complejidad progresiva y la mezcla de participantes entre áreas
• Materiales y logística — los materiales físicos y las guías para el equipo facilitador
• Acompañamiento — un mes observando las ceremonias reales para ajustar el apoyo

El punto de partida

El cliente llegaba con una plataforma que ya llevaba varios años en operación. En la primera presentación quedó claro que el problema no era funcional: el producto hacía lo que tenía que hacer. Lo que no acompañaba era la experiencia. Casi cualquier información se resolvía con una tabla, la interfaz arrastraba un estilo que no había evolucionado con el producto, y llegar a una acción concreta tomaba más pasos de los necesarios.

Qué hicimos,
y con qué límites

El discovery se centró al 100% en Salacuna, con foco en el perfil empresa/Cliente — la administradora que gestiona el beneficio dentro de la empresa — confirmado como la prioridad del rediseño. Dos instancias: una sesión interna de negocio y cinco entrevistas con usuarias reales.

Lo que encontramos
y lo que costaba

Cada hallazgo quedó etiquetado con su origen —entrevista, hipótesis interna o revisión del front— y con su estado respecto del alcance. Separar lo que dijeron las usuarias de lo que suponía el negocio fue lo que evitó rediseñar problemas imaginarios.

La fricción que hoy resuelve una llamada es la misma que mañana hace que el cliente deje de usar la plataforma.

Ninguno de estos hallazgos es solo de usabilidad. Encadenados forman una escalada conocida: la tarea que la plataforma no resuelve se convierte en una llamada, el trabajo migra al correo o a la propia beneficiaria, y el cliente que se acostumbra a resolver por fuera deja de percibir el valor del beneficio. Al revés también aplica — una plataforma que funciona y se muestra bien ayuda a ganar clientes, no solo a retenerlos.

Traducirlos así fue lo que consiguió que el rediseño dejara de discutirse como un tema estético y pasara a ser una decisión con dueño y presupuesto.

Qué vamos
a optimizar

Dentro del alcance de front, los hallazgos se consolidaron en ocho frentes. Traducir una lista de dolores en frentes accionables es lo que permitió priorizar sin reabrir la discusión en cada pantalla.

• Reducir clics — llegar a cada acción con menos toques
• Reducir pasos — acortar flujos largos y repetitivos
• Acciones más claras — qué se puede editar y qué no
• Ubicación de la información — poner a mano lo que hoy cuesta encontrar
• Jerarquía de la vista — destacar lo vigente sobre lo secundario
• Optimizar el scroll — tablas y vistas largas recorribles
• Filtros más rápidos — búsqueda integrada en las tablas
• Lenguaje consistente — copy de estados, rótulos y botones

Sistema primero,
experiencia después

Con el diagnóstico sobre la mesa, la decisión fue no empezar por las pantallas. Si el problema era consistencia, jerarquía y recorrido, ir pantalla por pantalla solo habría maquillado los síntomas. Construí primero el sistema de diseño y, recién sobre esa base, reajusté el UX/UI.

Primero el sistema,
después las pantallas

La marca ya tenía tokens, paleta y una firma visual —el chamfer, el corte a 45°—. Lo que no tenía era un sistema: reglas explícitas de cuándo usar cada cosa. Documenté una regla de oro que gobierna todo el front —el texto siempre en Deep Blue, los colores vivos como superficie y nunca como texto, el verde reservado para la acción— y sobre ella levanté la librería completa: botones, holding shapes, formularios, cards, tablas, estados e íconos, cada uno con sus variantes y su spec.

Construirlo antes de rediseñar fue lo que permitió que las decisiones no se volvieran a discutir pantalla por pantalla — y, más tarde, que la versión móvil no necesitara componentes nuevos.

Componentes del sistema

01 / 04

←

→

Antes y después

Las mismas funciones, tres módulos clave. A la izquierda la plataforma que encontramos; a la derecha, la misma pantalla reconstruida sobre el sistema de diseño.

Una versión
que no existía

La plataforma solo vivía en escritorio. Diseñar la versión móvil no fue encoger la de escritorio: las tablas se vuelven tarjetas, los filtros se repliegan en un panel desplegable y la navegación horizontal pasa a menú. Como el sistema de diseño ya contemplaba el comportamiento responsive, la adaptación no necesitó componentes nuevos — solo aplicar los que ya estaban definidos.

Un proceso manual
con costo invisible

La trattoria gestionaba el 100% de sus reservas por teléfono, con un personal que debía atender llamadas mientras servía a los clientes presenciales. Las reservas fuera del horario de atención se perdían. Los errores en la toma de datos eran frecuentes. Y el proceso dependía por completo de la disponibilidad de una persona.

El desafío no era solo automatizar — era diseñar una experiencia de voz confiable, natural y coherente con la identidad del restaurante, sin que el cliente sintiera que estaba hablando con un sistema frío.

De qué está hecha
la conversación

Mapeé el diálogo completo: el camino ideal, las variaciones reales del lenguaje, el manejo de error y las salidas de excepción. No construí el motor de voz — trabajé sobre la capa de experiencia: qué pregunta el agente, en qué orden, cómo devuelve lo que entendió y qué hace cuando no entiende.

Darle al agente
de qué hablar

Un asistente de voz no sabe nada del negocio hasta que alguien se lo escribe. Construí la librería de contexto: el menú, los horarios, las políticas de cancelación, los eventos vigentes y —lo que más trabajo dio— el mapa del salón. La armé como el briefing que le darías a un mozo nuevo en su primer día: no lo que el sistema necesita, sino lo que hace falta para responder bien.

El croquis fue la pieza clave. El cliente no pide «la mesa 7»: pide «algo tranquilo» o «afuera». Para que el agente pudiera ofrecer eso, cada mesa tuvo que entrar con su zona, su capacidad y las expresiones con que la gente suele pedirla.

Quién es Francesco
cuando contesta

Ponerle nombre al asistente fue la primera decisión: Francesco no es un detalle simpático, es lo que permite que se presente sin fingir ser humano. Después vino traducir el registro de la trattoria en reglas concretas de conversación — porque no basta con decir «cálido y cercano»: hay que escribir qué frases entran y, sobre todo, qué frases quedan fuera.

Un caso difícil,
de principio a fin

El guion no se escribe para el camino fácil. Este es el caso que más trabajo dio: un cumpleaños de once personas que necesita dos mesas unidas en la terraza — algo que no entra en el flujo estándar de reserva. Al margen, la decisión de diseño detrás de cada respuesta.

Reconstrucción del guion a partir del caso trabajado. Las decisiones de diseño anotadas al margen son las que gobernaban la conversación real.

Próximos pasos

Un producto nuevo,
no una versión digital

Avanza no digitalizaba un proceso existente: era un producto nuevo. Una empresa quería sumar a su paquete de beneficios el acceso a un préstamo personal para sus colaboradores, con mejores condiciones que las del mercado. El canal se apoya en algo que la entidad ya tenía: el historial de pago de quienes tomaron un préstamo antes, que habilita una oferta pre-aprobada para uno nuevo.

Del pre-aprobado
al dinero depositado

El flujo principal lleva al cliente por un recorrido lineal pero lleno de decisiones de diseño: bienvenida, ingreso, perfil con oferta pre-aprobada, simulación, evaluación y desembolso. Estas son cinco vistas clave del prototipo navegable.

Flujo navegable de 16 vistas, construido y prototipado en Figma.

Aterrizar la idea
antes de diseñar

Antes de diseñar pantallas, mapeé qué tenía que pasar por dentro. El aterrizaje consistió en descomponer el enunciado "que el cliente lo haga solo" en un recorrido con lógica real: elegibilidad, cálculo de cuota, estados de la solicitud y casos borde.

La otra cara
del producto

El canal es autogestionado para el cliente, pero el producto tiene dos caras: detrás sigue habiendo un equipo comercial que lo coloca y le da seguimiento. Más allá del encargo, propuse y aterricé un perfil de ejecutivo — identidad del equipo, métricas de colocación y conversión, ranking e historial de atenciones — para que la gestión comercial y la trazabilidad postventa no quedaran fuera del sistema.

Diseñarlo con los mismos componentes demostró que la solución escala como ecosistema y no como pantalla suelta: dos experiencias distintas, un solo sistema de diseño.

Lo que sigue
para este producto

Un cuaderno como
sistema de cobranzas

La gestión de la cartera se llevaba a mano. Las fechas de vencimiento, las promesas de pago y los recordatorios de cada cliente vivían en el cuaderno personal de cada ejecutivo. Funcionaba mientras la cartera fuera chica y la memoria alcanzara — y dejó de funcionar antes de que alguien lo notara.

Investigar lo justo
para decidir bien

Este no era un problema que necesitara meses de investigación. El proceso estaba a la vista y el equipo sabía perfectamente qué le dolía. Hice un levantamiento acotado — entrevistas con el equipo de cobranzas para reconstruir cómo gestionaban el día a día — con un objetivo concreto y único: definir qué módulos debía tener el sistema y en qué orden construirlos.

Dimensionar la investigación al tamaño real de la incógnita también es una decisión de diseño. De ese levantamiento salieron cuatro pilares, y cada pilar se convirtió en un módulo de la plataforma.

Cuatro pilares,
cuatro módulos

Cada pilar del levantamiento se tradujo en un módulo con una pregunta que responder. Ninguna pantalla existe porque quedaba bien: existe porque contesta algo que antes se contestaba con el cuaderno, o no se contestaba.

Tres roles,
una sola plataforma

El ejecutivo, el supervisor y el administrador entran al mismo producto y necesitan cosas distintas. En vez de construir tres plataformas, diseñé una que se reorganiza según quién la abre: cambia la navegación disponible, cambian los datos que se ven y cambia el alcance de las acciones.

La cobranza
ocurre en la calle

El ejecutivo de cobranzas no está sentado frente a un escritorio: visita clientes, llama desde el auto, registra una promesa apenas cuelga. La versión móvil no es el escritorio encogido — es una jerarquía distinta, donde primero aparece qué hay que hacer hoy y los filtros de cartera se vuelven chips de un toque.

Lo que dejó
el proyecto

Reemplazar un cuaderno no es digitalizar un cuaderno. La tentación era construir una lista de clientes con fechas — una versión electrónica de lo mismo. Lo que el equipo necesitaba era que el sistema tomara decisiones que antes tomaba la memoria: qué es urgente, qué está por caerse, a quién le toca.

El otro aprendizaje fue sobre la proporción del research. Con un proceso observable y un equipo que sabía nombrar sus dolores, un levantamiento breve y dirigido dio lo que hacía falta para decidir la arquitectura. Investigar de más habría retrasado el producto sin cambiar ninguna de las cuatro decisiones importantes.