UI Kit & Design System
Sistema de diseño construido desde cero para alinear diseño y desarrollo en la primera fintech digital de México.
Ver siguiente proyecto
El reto
En 2021, albo tenía varios equipos de producto construyendo en paralelo sin un lenguaje visual compartido. El resultado era predecible: componentes duplicados, comunicación ambigua entre diseño y desarrollo, y una deuda de consistencia que crecía con cada sprint.
Identificamos tres problemas concretos:
- Conocimiento descentralizado — cada diseñador tomaba decisiones visuales de forma independiente, sin referencia común.
- Componentes desactualizados — los existentes no reflejaban el producto real y nadie era responsable de mantenerlos.
- Comunicación ambigua con desarrollo — sin especificaciones claras, el handoff dependía de conversaciones individuales y generaba retrabajo.
"Los sistemas de diseño son la manera en que hablas de todas las decisiones que tomas como organización de diseño y código. Es la manera en que colaboras para traspasar esas decisiones."
— Nathan Curtis, Eight Shapes
El objetivo era crear un sistema de componentes que fuera la fuente de verdad para todos los equipos: diseño, desarrollo frontend y producto. No solo una librería de Adobe XD, sino un sistema vivo que cualquier diseñadora pudiera usar, actualizar y explicarle a desarrollo sin ambigüedad.
Usuarios
Un design system tiene usuarios internos con necesidades muy distintas. Entender qué necesitaba cada perfil fue clave para decidir qué construir primero y cómo documentarlo.
| Perfil | Necesidad principal |
|---|---|
| Product Designers | Necesitan componentes listos para usar y actualizar sin romper el sistema. Quieren moverse rápido sin tener que reinventar patrones. |
| Desarrolladores frontend | Necesitan especificaciones claras, nombres consistentes y propiedades documentadas. La ambigüedad en el handoff les cuesta tiempo y genera regresiones. |
| Product Managers | Necesitan visibilidad sobre qué existe para no pedir trabajo duplicado ni comprometer timelines por componentes que "ya deberían estar hechos". |
Mi proceso
Construir un sistema de diseño desde cero requiere un orden muy específico: no se puede diseñar lo que no se ha inventariado, y no se puede documentar lo que no se ha validado con quienes lo van a usar.
Documentamos el estado real de los componentes existentes: qué había, qué estaba desactualizado, cómo se comunicaban diseño y desarrollo. El inventario reveló múltiples variantes del mismo componente construidas de forma independiente.
Construcción del sistema en Adobe XD con tokens, variantes y propiedades. Cada componente documentado con sus estados, restricciones y notas de implementación — directamente en la herramienta donde diseñamos.
El sistema se diseñó para ser autoexplicativo: una guía de inicio rápido integrada en Adobe XD que cualquier diseñadora pudiera seguir sin necesidad de preguntar. La documentación vive donde se diseña, no en un doc separado que envejece.
Sesiones de presentación con los equipos de diseño y desarrollo para garantizar la adopción. El objetivo no era que usaran el sistema — era que cualquier diseñadora pudiera actualizarlo de forma autónoma.
Decisiones clave
Tres decisiones que definieron la arquitectura y la longevidad del sistema.
Nombrar los tokens por función (color-primary-action) en lugar de por apariencia (color-blue-500). Esta decisión garantiza que los tokens sobrevivan a cambios de marca sin necesidad de actualizar referencias en código ni en Adobe XD.
Estructura de Base (átomos: botones, inputs, iconos) y Compuestos (moléculas: cards, modales, formularios). Esta separación permite reutilización sin rigidez: los compuestos se construyen sobre base, pero cada uno puede evolucionar de forma independiente.
Las specs viven donde se diseña, no en un documento separado que queda desactualizado. Cada componente tiene su propia página de documentación en Adobe XD con ejemplos de uso, restricciones y estados. Si el componente cambia, la documentación está al lado.
Resultados y aprendizajes
El sistema fue adoptado por los 5 diseñadores del equipo y los 10 desarrolladores de frontend. La reducción del 25% en tiempo de ejecución se validó mediante ejercicios de evaluación con el equipo de Product Design — no fue una estimación, fue una medición.
Un design system es un producto, no un entregable. Necesita mantenimiento, gobernanza y una persona responsable de su evolución. Sin eso, se queda desactualizado en semanas.
La adopción no es automática. El sistema puede ser perfecto técnicamente y aun así no usarse. Las sesiones de presentación y el acompañamiento a los equipos fueron tan importantes como la construcción del sistema.
Empezar por los tokens acelera todo lo demás. Definir bien los valores base antes de construir componentes evita retrabajo masivo cuando llega el primer cambio de marca.