Conaliados
Dos productos opuestos en una plataforma: una app donde se pide el crédito y un backoffice donde se aprueba.
- Rol
- Responsable de diseño, equipo de 2
- Duración
- ~5 meses
- Plataforma
- App móvil · Backoffice web
- Sector
- Fintech · Crédito
- Estado
- Congelado por reasignación de presupuesto
Resultado
Completamos el handoff y el desarrollo arrancó. Antes de avanzar más, la empresa reasignó el presupuesto del proyecto a otras urgencias y el desarrollo quedó congelado. Fue una decisión de priorización de negocio, no de producto ni de diseño.
Lo que sí quedó: un proceso de validación documental rediseñado, que pasaba de uno o dos días a minutos, y un sistema de diseño que sirvió de base para el trabajo posterior del equipo.
El dato de tiempos corresponde al flujo diseñado y a las pruebas internas, no a una medición en producción: el proyecto no llegó a operar.
Métricas objetivo
Las métricas de negocio que el rediseño buscaba mover, y debajo de cada una el valor que tendría moverla.
Abandono de la solicitud
En crédito, quien no recibe respuesta hoy pide el préstamo en otro lado mañana. Cada espera larga es ingreso que se va a la competencia.
Tiempo de validación documental
Una jornada revisando papeles es una jornada sin asesorar ni colocar créditos. El tiempo del administrador es capacidad comercial.
Solicitudes atendidas por jornada
El administrador revisa solicitudes en serie todo el día. Subir cuántas alcanza a cerrar es más capacidad operativa sin contratar a nadie más.
El cuello de botella estaba antes de la decisión de crédito.
Conaliados otorga crédito a personas y empresas a través de cinco líneas distintas. Nos concentramos en las dos principales: libranza y créditos para SOAT.
El problema no era decidir si aprobar. Era la validación documental del solicitante: manual, y entre uno y dos días. Para el administrador eso significaba una jornada revisando papeles en lugar de asesorar. Para el solicitante, un limbo sin saber en qué paso estaba ni cuánto le faltaba. En crédito esa espera es cara: quien no recibe respuesta hoy pide el préstamo en otro lado mañana.
Debajo había una causa heredada: parte de la documentación exigida no incidía realmente en la decisión de crédito.
Responsable de diseño del proyecto.
Trabajé con otro diseñador, que me consultaba las decisiones de criterio y de implementación. La participación de los 2 desarrolladores fue puntual, en la última etapa del proyecto.
- · El sistema de diseño del producto, del que fui responsable directo: foundations, componentes y su documentación.
- · El concepto visual, incluida la decisión de tratar la app y el backoffice como dos lenguajes distintos.
- · La investigación y los flujos, desde las entrevistas hasta el handoff.
- · Las dos interfaces completas, de la arquitectura de información a los prototipos de alta fidelidad.
- · Los estados de solicitudes y créditos, incluidos rechazo, anulación con motivo y trazabilidad de cada cambio.
Lo que no fue mío: las reglas de negocio del crédito vinieron del área que maneja el producto, con quienes hicimos una consultoría dedicada. La implementación fue de desarrollo, y la marca ya existía.
Entrevistas primero, y la letra pequeña de la operación.
Entrevistamos a 5 personas que habían solicitado créditos de libranza y de SOAT, y lo complementamos con una consultoría con un responsable de la gestión de esos créditos. Esa consultoría fue la que nos dio la letra pequeña de cómo funciona la operación por dentro, que ninguna entrevista con solicitantes podía darnos.
Con eso construimos los flujos de las dos caras del producto y la arquitectura de información de cada una. Cada decisión del recorrido quedó resuelta en el diagrama antes de abrir una pantalla. De ahí pasamos a foundations, componentes y prototipos de alta fidelidad hasta el handoff.
Dos productos, dos lenguajes visuales.
Diseñé la app del solicitante y el backoffice del administrador como dos productos con lenguajes distintos: la app más expresiva, el backoffice más sobrio y orientado a datos. Lo que descarté fue una sola interfaz responsive compartida, que era más barata de construir y de mantener.
El solicitante y el administrador no comparten contexto ni objetivo. El solicitante pide crédito desde el celular, casi siempre una sola vez, y necesita confianza y claridad sobre en qué paso va. El administrador trabaja sentado, revisa solicitudes en serie toda la jornada y necesita comparar y decidir rápido. Una interfaz responsive habría obligado a que uno de los dos usara una versión degradada del producto del otro.
Y los dos no pesan igual para el negocio. El solicitante es quien contrata y quien paga: de sus créditos sale el ingreso. Eso inclinó la balanza sobre dónde poner el atractivo visual y dónde bastaba con que la herramienta fuera eficiente, y es la razón por la que defendí mantener dos lenguajes en vez de uno solo más barato de construir.
La consecuencia fue concreta: el backoffice se construyó con densidad alta y la tabla como unidad principal; la app, con una decisión por pantalla y el progreso siempre visible.
Centralizar el proceso, no solo acelerarlo.
Todo el proceso era manual y no dejaba rastro: el solicitante entregaba en momentos distintos y por vías distintas, y podían intervenir varias personas sin que nadie supiera en qué punto estaba cada caso. Decidí llevar la solicitud y el desembolso completos a un solo lugar, con trazabilidad de cada cambio, y de paso recortar los campos y documentos a los que sí incidían en la decisión de crédito.
Lo que descarté fue dejar la cadena intacta y limitarnos a hacerla más rápida, que era la ruta de menor resistencia. El tiempo del administrador no se iba en ir despacio: se iba en trabajo repetido y en averiguar en qué punto estaba cada solicitud. Acelerar una tarea innecesaria sigue siendo tiempo perdido. Este fue el cambio que llevó la validación documental de uno o dos días a cuestión de minutos.
La información sensible se muestra, no se esconde.
Priorizamos que el estado del crédito y la información de pagos estuvieran accesibles sin varios clics de por medio, tanto para el solicitante como para el asesor. Lo que descarté fue el patrón habitual en productos financieros de enterrar los datos sensibles detrás de capas de confirmación, por precaución.
El asesor necesita responder en el momento en que el cliente pregunta; si tiene que navegar tres niveles para saber si un pago entró, la asesoría deja de ser oportuna. La protección de esos datos se resolvió en las capas de autenticación y permisos, no escondiendo la información de quien ya tiene derecho a verla.
Dos recorridos sobre un mismo objeto.
Los flujos fueron la forma de ver el problema completo antes de tener una sola pantalla que defender. Mapear las dos caras a la vez obliga a resolver en el diagrama lo que después cuesta caro: dónde se bifurca el recorrido, qué pasa cuando algo falla, en qué punto una decisión del solicitante cambia el trabajo del administrador. Solo con ese panorama encima de la mesa el diseño de pantallas se vuelve una consecuencia en lugar de una apuesta.
Pedir un crédito desde el teléfono.
La app resuelve tres cosas: entender qué productos tengo, saber cuánto y cuándo debo pagar, y pagar. El home abre con el saldo pendiente y el próximo pago porque es la pregunta con la que el usuario abre la app.
Una solicitud entendible en una sola pantalla.
El backoffice está organizado por producto, y dentro de cada producto por solicitudes e historial. La tabla es la herramienta principal del analista: filtros por fecha y estado, orden por cualquier columna y el estado siempre visible como etiqueta.
El estado es el producto.
Una solicitud puede estar aprobada, rechazada, resuelta o anulada; un crédito puede estar al día o en mora. Cada estado cambia lo que el analista puede hacer en la pantalla, y la anulación exige motivo y fecha para que la decisión quede trazable.
Color y tipografía, con el contraste verificado.
Los foundations son la parte del sistema que nadie ve y que decide todo lo demás: cada componente hereda lo que aquí quede definido, y corregirlo después obliga a revisar el producto entero. Por eso el color no se cerró eligiendo valores bonitos sino verificando combinaciones: qué texto puede ir sobre qué fondo, con qué mínimo de contraste, y qué combinaciones quedaban descartadas de entrada. La tipografía se definió con el mismo criterio, especificada por dispositivo para que la jerarquía se sostenga en pantallas pequeñas.
Componentes documentados por estado y por tamaño.
El sistema quedó como una librería de componentes en Figma, con sus estados resueltos y armada para usarse sin tener que interpretarla. Solo construimos lo que el producto iba a usar de verdad: cada componente extra es trabajo de diseño, de documentación y de implementación que alguien tiene que sostener, así que el catálogo se mantuvo del tamaño del problema y no del tamaño de un sistema ideal.
El proyecto pertenece a un producto de un cliente, así que comparto un subconjunto de pantallas, y los datos que se ven son ficticios, generados para el prototipo. El prototipo completo, los flujos y las decisiones que quedaron fuera puedo presentarlos en una conversación.
Lo que aplico desde entonces.
Una rampa se prueba contra todas las superficies donde va a vivir.
Visualmente el resultado nos dejó orgullosos, pero al llevar los componentes a fondos oscuros aparecieron fricciones de contraste que no habíamos previsto: definimos la rampa mirando cómo se veía sobre fondo claro, que era el del producto, y no el rango completo de superficies donde iba a aparecer. Hoy la contrasto contra todos los fondos previstos antes de darla por cerrada, y eso incluye los que todavía no existen en el diseño.
En un backoffice de jornada completa, el modo oscuro es ergonomía.
Usamos mucho blanco, y en el backoffice, donde el administrador pasa la jornada entera, eso es fatiga acumulada. Hoy lo trato como un requisito del contexto de uso y no como una preferencia estética: pesa en la definición de los tokens desde el primer día, porque incorporarlo más tarde obliga a rehacerlos.
En productos financieros, comunicar es parte del diseño.
Trabajando con datos sensibles y con pagos, la manera de comunicar el estado de la información resultó tan crítica como la interfaz. Que todos los actores estuvieran al día sobre los pagos correspondientes no era un requisito de contenido: era la función del producto.