Industria
fintech
Cliente
kiban
Workflow Builder para Originación de Crédito
Diseñar sin plan de producto: traduciendo lógica técnica a experiencia de usuario
Me asignaron rediseñar workfloo—la herramienta estrella de la compañía que llevaba años operando. workfloo permitía crear flujos de trabajo para procesos de aprobación de préstamos: desde que alguien solicita hasta que se aprueba o rechaza. Esa lógica ya existía en código. Los developers de la empresa hablaban directamente con developers de los clientes—servicio técnico a servicio técnico. Funcionaba, pero solo si tenías un equipo de programación. kiban quería moverse de ahí: que otras personas del cliente (analistas, product managers, operadores, analistas) pudieran crear sus propios flujos sin escribir código.
El problema no era solo diseñar sin contexto—era que el contexto que me daban estaba mal desde el origen.
El equipo técnico lideraba el proyecto. "Me daban el trabajo en cachitos. Una pantalla, un flujo, un componente—sin explicar para qué servía ni cómo se conectaba con el resto. Hablaban en lingo técnico que no entendía y esperaban que diseñara por partes, como unidades aisladas. Me daban el detalle primero, sin el panorama. Se rehusaban a dar un paso atrás para explicar el sistema completo." Pensaban que diseño era replicar visualmente: "Nomas replica esto." Mientras me mostraban herramientas similares. Para ellos, benchmarking era "copy-paste". Estaban tan encimismados en que el producto YA FUNCIONABA que se negaron a ver en qué NO funcionaba y PARA QUIÉN Nofuncionaba. Diseñaba coherencia visual sobre un sistema que no tenía coherencia conceptual. Todo lo que podía hacer era maquillar una lógica que ya estaba decidida.
Diseñé el canvas completo desde cero.
Espacio, tamaño de componentes, colores. Cómo se movía en el canvas. Cómo se agregaba un componente. Cómo se construía el camino del flujo—el flujo mismo. Diseñé las cartas de los conectores. Variaciones de estado. Zoom in, zoom out. El equipo usaba el mismo término para componentes completamente diferentes—creé diferenciación visual para que usuarios pudieran distinguir qué era qué. La herramienta completa se integró a la plataforma Kiban Cloud como el módulo de Originación.
"Diseñar coherencia donde no existe requiere construir el mapa que nadie más hizo."
01
Benchmarking cuando falta contexto
No había arquitectura de información pensada para usuarios. El mapa lo iba construyendo yo con lo que podía entender de documentación que en un punto ni mis superiores técnicos entendían. Cuando caché que eran flujos de trabajo, estudié Zapier, Make, n8n. Identifiqué patrones: canvas infinito, zoom para contexto/detalle, diferenciación visual entre conectores, feedback inmediato. Adapté lo que ya funcionaba—no copié. El benchmarking me dio la estructura que el equipo no pudo darme.
02
Priorización sin roadmap
La herramienta se hacía en partes. Se priorizaba conforme a la agenda de programación—no a un plan de producto. El proyecto no tenía roadmap claro. Features importantes llegaban de último minuto—como el modo sandbox, que apareció casi al final sin explicación de para qué servía o por qué era necesario. El equipo priorizó velocidad. Diseñé para la limitante, no para un cambio real.
03
Traducir lógica técnica sin que lo valoren
El equipo usaba el mismo término para componentes completamente diferentes. Creé diferenciación visual para que usuarios pudieran distinguir qué era qué. Con información mínima, yo diseñaba pantallas funcionales que aclaraban visualmente la lógica. Pero cuando el equipo veía todo funcionando, asumían que agregar o modificar features era igual de rápido. "Esque tú rápido le mueves y ya quedó"—como si pensar formas, jerarquías, flujos no tuviera peso. Como si fuera random. Decían que el error de programarlo mal costaba mucho en tiempo y dinero. Pero diseñarlo mal, aparentemente, no costaba nada. Hacer que se vea fácil es, precisamente, lo difícil.
