Arquitectura escalable de un Design System para el rediseño de la app móvil bancaria, y la revisión heurística de los flujos transaccionales que ayudó a priorizar el roadmap.
Diseñé un sistema que hoy usan perfiles junior para extender pantallas manteniendo consistencia, sin depender de quien lo creó.
Trabajé en dos frentes. Junto a un equipo de tres, lideré la creación de un Design System escalable y replicable para el rediseño de la app móvil del banco, con estructura atómica y tokens semánticos: el foco no fue solo entregar componentes visuales, sino dejar una base ordenada que el equipo pudiera mantener y hacer crecer. En paralelo, ejecuté una revisión exhaustiva de los flujos transaccionales con evaluación heurística, documentando hallazgos por severidad y patrones transversales, que sirvió para priorizar el roadmap de transformación digital contrastándolo con data de uso real.
El encargo era rediseñar la app móvil del banco. Antes de pintar pantallas, el equipo evaluó factibilidad técnica, alcance viable y cómo hacer que el cambio se sostuviera en el tiempo. Si el proyecto se quedaba en un rediseño visual puntual, el resultado habría sido imposible de mantener en un ecosistema bancario con legado tecnológico fuerte y múltiples productos conviviendo: el riesgo era generar incoherencia y retrabajo cada vez que algo cambiara.
Había una plataforma con fuertes restricciones técnicas y un ecosistema digital fragmentado. El reto no era hacer la interfaz más atractiva: era crear una estructura que permitiera evolucionar sin romper la consistencia, en un banco con legado y varios productos conviviendo.
Definí una arquitectura de sistema por niveles siguiendo Atomic Design: tokens primitivos (los valores base, todavía sin significado — un color, un espaciado, una tipografía), tokens semánticos (esos mismos valores ya con un rol claro: color de error, espaciado de un formulario, texto de un botón primario), y sobre esa base, átomos, moléculas, organismos y plantillas — cada nivel construido sobre el anterior, sin saltarse capas. Estructuré el trabajo en bibliotecas publicables con dependencias claras entre ellas, para que cada nivel pudiera evolucionar sin arrastrar a los demás.
Las cinco capas del Design System, de los fundamentos a las plantillas. Cada una depende solo de la de abajo, y esa es la regla que permite que crezca sin rehacerse.
Elige una biblioteca para ver qué contiene, de qué depende y quién la consume.
Decidimos no construir un archivo monolítico. En su lugar armé el sistema por capas, con tokens semánticos y reglas compartidas, para que un cambio en un solo token semántico se propagara automáticamente a todos los componentes que lo consumían — sin tener que entrar a corregir pantalla por pantalla. Esto significó decir que no a variantes puntuales que algunos en el equipo querían para resolver casos rápido — mantener una sola fuente de verdad importaba más que resolver cada caso de la forma más cómoda en el momento, y esa fue una conversación que tuve que sostener más de una vez.
Cómo viaja un cambio de token hasta la app. No es automático: cada paso es una publicación deliberada, y el último distingue lo que sigue conectado de lo que ya no recibe el cambio.
Avanza y retrocede por los pasos para ver qué se publica en cada tramo.
Construí el Design System siguiendo Atomic Design de punta a punta, documenté las reglas de cada capa y alineé nomenclatura y lógica entre diseño y desarrollo. Esa estructura es la que permite diseñar pantallas nuevas rápido sin perder consistencia: un componente no se redibuja desde cero, hereda las reglas de la capa que tiene debajo. Y es la misma estructura la que permite hacer cambios a gran escala sin tener que tocar todo uno por uno — se ajusta el token o el átomo correspondiente, y el cambio llega solo, de forma controlada, a cada pantalla que lo usa.
Aseguré la implementación con guías de tokens, revisiones de consistencia y apoyo directo a los desarrolladores durante el primer ciclo de despliegue. Lo importante fue que el mismo beneficio que tiene diseño lo tiene desarrollo: el Design System les habla en el mismo lenguaje de capas y tokens, así que lo que implementan en código replica esa misma estructura, no una interpretación libre de cada desarrollador — un cambio en la base se ve reflejado igual de un lado y del otro. Con los perfiles más junior del equipo, eso significó sentarme con ellos a mostrar el por qué de cada capa, no solo el cómo — para que cuando extendieran el sistema sin mí, lo hicieran entendiendo la lógica y no solo copiando un patrón.
Definí la estructura del sistema antes que el estilo visual, para que el diseño fuera escalable y no dependiera de un solo archivo ni de una sola persona.
Elegí una estructura de librerías con dependencias claras, en vez de un único archivo monolítico, para facilitar la evolución y la trazabilidad.
Hice que los componentes consumieran tokens, no valores directos, para poder re-tematizar o ajustar el sistema desde la base sin tocar cada componente.
Alineé nomenclatura, capas y lógica con el equipo de desarrollo, para que lo implementado en código fuera la misma estructura que diseño definió, no una versión distinta.
Evalué cada decisión según cómo permitiría crecer al sistema sin refactorizaciones masivas.
Demuestra mi capacidad para diseñar un Design System como infraestructura escalable, gobernada y práctica — no solo como una librería de componentes — y para que ese mismo sistema hable el idioma de desarrollo, no solo el de diseño.
Aprendí que un design system no es una librería de componentes bonitos: es una decisión de estructura y de gobernanza. Su éxito no se mide cuando lo entregas, sino cuando alguien que no eres tú —de diseño o de desarrollo— puede construir con él sin romper la consistencia.