¿Qué contiene un design system?
Cuatro capas, de lo abstracto a lo concreto:
- Fundamentos: paleta de color con sus roles, escala tipográfica, sistema de espaciado, radios y sombras.
- Componentes: botones, campos, tarjetas, tablas, avisos — cada uno con sus variantes y sus estados (normal, hover, foco, deshabilitado, error).
- Patrones: combinaciones resueltas, como un formulario de contacto o una tabla de datos con filtros.
- Reglas de uso: cuándo usar cada cosa y, sobre todo, cuándo no.
La cuarta capa es la que separa un design system de una biblioteca de componentes bonitos. Sin reglas de uso, cada quien elige distinto y la coherencia dura hasta el siguiente proyecto.
¿En qué se diferencia de un manual de marca?
| Manual de marca | Design system | |
|---|---|---|
| Responde | Cómo se ve la marca | Cómo se construye el producto |
| Audiencia | Diseño, marketing, proveedores | Diseño y desarrollo |
| Contenido típico | Logo, usos correctos, paleta, tipografías | Componentes, estados, espaciado, reglas |
| Formato | Documento | Biblioteca viva en Figma y en código |
| Cambia | Rara vez | Continuamente |
La diferencia práctica: un manual de marca se aprueba y se archiva; un design system que se archiva deja de servir en seis meses.
¿Cuándo se justifica construirlo?
Cuando se cumple al menos una de estas tres condiciones:
- Varias personas construyen. Dos diseñadores o dos desarrolladores ya producen divergencia; el sistema es el acuerdo escrito.
- Más de una superficie. Sitio público, aplicación interna, landings de campaña: sin sistema, cada una deriva por su lado.
- Se redecide lo ya decidido. Si en cada proyecto se vuelve a discutir el tamaño de los botones, estás pagando esa discusión repetidamente.
¿Cuándo es gasto prematuro?
Cuando hay una sola persona construyendo una sola superficie que no va a crecer pronto. En ese escenario el sistema tarda más en construirse de lo que ahorra, y envejece antes de rentabilizarse.
La alternativa razonable es un conjunto de variables de estilo bien nombradas —color, tipografía, espaciado— y un puñado de componentes reutilizables, sin la documentación formal ni la biblioteca en Figma. Es un 20% del esfuerzo con buena parte del beneficio, y se puede formalizar después si el equipo crece.
¿Qué hace que fracase?
Tres cosas, en orden de frecuencia. Que nadie lo mantenga: un sistema sin dueño se desactualiza y el equipo vuelve a improvisar, ahora con la carga extra de una biblioteca que miente. Que diseño y código diverjan: si el componente en Figma y el del sitio no coinciden, el sistema deja de ser fuente de verdad. Y que se construya desde la teoría en lugar de desde lo que ya existe: sistemas exhaustivos con cuarenta componentes de los que se usan seis.
Lo que funciona es empezar por inventariar lo que el producto ya usa, consolidar las variantes accidentales y documentar eso. En Articod Digital Lab entregamos el sistema en Figma junto con la documentación mínima para desarrollo, precisamente para que ambas mitades nazcan sincronizadas.