Insight One · Plataforma de pagos · Ene – Jul 2024
Que cada rol vea lo que necesita ver.
Rediseñé la plataforma de gestión de terminales de pago de Insight One: segmenté la información por tipo de usuario, definí reglas para las cargas y creé su primer design system.
Cada piedra es una métrica del caso.
Tickets de soporte frente a los tres meses previos al proyecto
Componentes del primer design system, ya implementados
Módulos rediseñados de punta a punta
User paths analizados en 10 secciones
Contexto
Insight One es el producto de Agnostiko para gestionar terminales de pago de distintas marcas durante todo su ciclo de vida, desde una consola en la nube. Agnostiko me contrató para rediseñarlo; trabajé con equipos de México, EE.UU. y Venezuela, y su primer cliente fue un banco mexicano. Cuando llegué no tenía sistema de diseño: cada módulo decidía su propio criterio visual.
El problema de fondo era más profundo que la interfaz. Todos los módulos estaban abiertos para todos los usuarios, no había feedback ni instrucciones sobre los procesos, y tampoco reglas claras para subir archivos clave, como las bases de datos. Éramos dos diseñadoras; yo lideré las negociaciones con negocio, producto, desarrollo y el cliente piloto.
Mi rolel puente entre las áreas
Éramos dos diseñadoras en el proyecto. Yo lideré todas las negociaciones, desde el pitch hasta la defensa de las decisiones de diseño, y trabajé con producto, desarrollo, QA, ventas y el cliente piloto:
Diseño y research
- Research con cuatro métodos: entrevistas, tests moderados, feedback de QA y focus group
- Task flows y user flows por tipo de usuario
- Prototipos de baja a alta fidelidad
Alineación entre áreas
- Llevé la necesidad del cliente piloto a la mesa con negocio
- Sesiones de ideación con desarrollo, producto, QA y ventas
- Priorización del MVP con matriz y método MoSCoW
Design system
- Defendí crear un design system inicial para estandarizar y escalar
- Alrededor de 20 componentes, todos implementados
- Style guide, tipografía y breakpoints
El cuello de botellatodos veían todo, nadie sabía qué hacer
El problema no era una pantalla fea. La plataforma no distinguía quién debía ver qué y no guiaba a quien la usaba.
Todos los módulos estaban abiertos para todos los usuarios.
Decisores, técnicos de IT y desarrolladores veían lo mismo, aunque hacían actividades distintas dentro de la misma plataforma.
Sin feedback, sin instrucciones y sin reglas para subir archivos clave.
En las cargas masivas, como las bases de datos, el usuario no sabía si la información se había enviado bien.
“There are processes where I’m not sure if the information was sent or loaded correctly.”
Julieta · Bank Manager
“In the displayed tables, I don’t feel like we’re seeing the columns with the information we need.”
Andrés · IT Systems Manager
Lo que hice
- Mapeé task flows y user flows por tipo de usuario: 32 paths en 10 secciones para ver dónde se perdía cada uno.
- Definí con el equipo reglas y guías para las cargas masivas: mensajes de error detallados, distinción entre carga individual y masiva, y borrado en dos pasos.
El desacuerdoalcance de negocio contra necesidad del cliente
El alcance que definía negocio no correspondía con lo que el cliente piloto necesitaba para operar.
No quería incluir cuántas terminales estaban offline ni desde cuándo.
El alcance definido dejaba fuera un dato que el cliente consideraba básico.
Con ese dato el banco decide si manda a alguien al negocio a revisar qué pasa.
Sin él, la plataforma mostraba información pero no ayudaba a actuar.
Lo que hice
- Llevé la necesidad del cliente piloto a la mesa con negocio y defendí el diseño que la reflejaba.
- Reuní a producto, desarrollo, QA y ventas en sesiones de ideación y de factibilidad técnica para validar el alcance antes de construir.
Lo que se decidió
El dato de terminales offline quedó en el dashboard.
- Así el banco puede ver qué terminales fallan y desde cuándo, y decidir si manda a alguien a revisar.
Decisioneslo que defendí
Un design system inicial antes que pantallas sueltas
Defendí crear componentes y un DS inicial para estandarizar y poder escalar a futuro. Se crearon alrededor de 20 componentes y se implementaron.
Alineación visual y de arquitectura de información
En una plataforma con enormes cargas de datos y tablas, ordené jerarquía, filtros y estados para que la información se pudiera leer y accionar.
Cargas con guía y reglas claras
Un flujo guiado — subir, verificar, cargar, informe — con estados visibles y mensajes de error detallados.
Style guide y componentes
Desliza para ver el style guide completo ↔
Titulares y subtítulos en Poppins, en distintos calibres. Párrafos y etiquetas en Roboto.
Los puntos de quiebre se definieron para desktop, tablet y mobile, específicamente para el proceso de log-in.
Desliza para ver los ~20 componentes del design system ↓
Impactolo que cambió
Soporte
Design system
Del análisis al rediseño
Fuente: tickets reportados por soporte y por QA en los tres meses previos al proyecto, comparados con el periodo posterior.
Evidenciaantes y después de los módulos clave
- Interfaz genérica sin identidad de marca y con flujo confuso
- Hero con propuesta de valor clara y branding integrado
- Datos sin jerarquía y mapa sin contexto útil
- KPIs priorizados y visualización de distribución por terminal
- Tabla densa, sin filtros y sin visibilidad de estado
- KPIs de terminales, filtros activos y estados claros
- Lista densa sin categorías, difícil de escanear
- Grid de apps con cards y categorización clara
- Proceso sin feedback ni validaciones claras
- Flujo guiado: subir → verificar → cargar → informe
- Lista sin segmentación por rol ni permisos visibles
- Cards por usuario con rol, permisos y estado diferenciados
Lo que aprendí
Alinear expectativas también es diseñar
Las empresas que empiezan a integrar UX suelen esperar el resultado óptimo en una sola ejecución. Parte de mi trabajo fue sostener la alineación entre lo que pedía negocio, lo que necesitaba el cliente y lo que el equipo técnico podía construir.
“Un sistema claro empieza por decidir quién necesita ver qué.”
Melany Olivares