Estructura de un design system: las 7 categorías y el orden

Un design system escalable se compone de siete categorías: tokens, componentes, patrones, layout, accesibilidad, documentación y governance. Tenerlas todas no es lo difícil. Lo difícil es construirlas en el orden correcto, y ahí es donde los sistemas se tuercen.

Construimos y mantenemos design systems en más de diez proyectos. El mismo hueco aparece siempre: las partes están, pero se añadieron en el orden equivocado, así que cada una trabaja contra las demás. La librería de componentes llega antes que la capa de tokens. La accesibilidad acaba siendo una auditoría final. La governance es una ocurrencia tardía. El sistema funciona el primer mes y se desalinea para el mes doce. Abajo van las siete categorías en el orden en que las construimos, con el fallo que evita cada una.

Cómo elegimos las siete

Tres pruebas deciden si algo merece categoría propia. Tiene que ser referenciado por las categorías que se construyen después. Tiene que fallar de forma evidente cuando falta. Y tiene que poder tener un dueño, una persona, no cinco equipos. Lo que no pasa las tres pruebas es una pieza de otra categoría, no una categoría.

1. Design tokens (los primeros)

Los tokens son los valores con nombre de los que lee el resto del sistema. Vienen en tres niveles. Los tokens primitivos guardan los valores en bruto (un azul es blue-600 = #1A73E8). Los tokens semánticos asignan intención (color-primary = blue-600). Los tokens de componente atan la intención a un contexto (button-bg = color-primary). El sentido de los tres niveles es un solo cambio: cambias un color de marca actualizando un único token semántico, y cada componente que lo lee cambia con él.

Ya no es una convención casera. El Design Tokens Community Group del W3C publicó la primera versión estable de la especificación en octubre de 2025, y Figma, Sketch, Tokens Studio y Style Dictionary leen el mismo formato. Los tokens van primero porque todo lo demás los referencia. Empieza por los componentes y acabarás escribiendo los valores hexadecimales a mano; luego un rebrand te toca trescientos archivos en vez de tres. La diferencia entre tokens, variables CSS y Tailwind la vemos en otro artículo.

2. Componentes (los segundos)

Los componentes son las piezas de interfaz reutilizables: botón, campo, card, modal, navegación. El modelo atómico de Brad Frost es el mapa mental más común: los átomos forman moléculas y las moléculas forman organismos. El trabajo de esta categoría es tener una sola versión del botón, no catorce versiones que se separaron en catorce pantallas.

El fallo es construir esta categoría primero. Una librería de componentes sin una capa de tokens debajo aguanta seis meses; después hay que llevar cada valor a los tokens a mano. Ese trabajo de recuperación es la causa más frecuente de desalineación que vemos. El segundo fallo es el número: un sistema con trescientos componentes es más difícil de mantener coherente que uno con sesenta.

3. Patrones (los terceros)

Los patrones son decisiones de UX, no piezas de interfaz. Dicen cómo debería funcionar un flujo: validación de formularios, navegación, estados vacíos, manejo de errores, confirmación de una acción destructiva. Nathan Curtis, de EightShapes, traza la línea con claridad: los componentes son cómo funciona algo, los patrones son cómo debería funcionar. Un componente se construye y se publica. Un patrón es una guía que aplicas mientras construyes.

Hacen falta bastantes componentes antes de que escribir patrones tenga sentido, y por eso llegan los terceros. Salta los patrones y tendrás un sistema con botones coherentes y flujos incoherentes. Cada equipo se inventa su comportamiento para los errores de un formulario, y el producto parece cosido a mano aunque los píxeles encajen.

4. Layout (en paralelo a los componentes)

El layout es la rejilla, la escala de espaciado aplicada a la estructura de página, las reglas responsive y un conjunto pequeño de plantillas. Lee de los mismos tokens de espaciado que los componentes, así que puede crecer junto a la segunda categoría en vez de esperar.

Aquí el fallo es sutil. Sin una categoría de layout compartida, dos pantallas hechas por dos personas usan 24px y 20px de margen para lo mismo. La incoherencia no se ve en revisión y salta a la vista de quien pasa de una página a otra.

5. Accesibilidad (dentro de cada categoría, no la última)

La accesibilidad es la única categoría que no es una fase. Es una restricción que vive dentro de las otras seis. Los ratios de contraste van en la capa de tokens. El foco y el orden de teclado van en los componentes. Los enlaces de salto y los landmarks van en el layout. La European Accessibility Act está en vigor en toda la UE desde junio de 2025, y eso movió la accesibilidad de un extra a un mínimo legal para los productos que se venden en Europa.

El fallo es tratarla como una auditoría al final. Una violación de contraste metida en un token primitivo es un arreglo. La misma violación descubierta cuando ya se ha extendido por cuarenta componentes son cuarenta arreglos.

6. Documentación (de forma continua)

La documentación es lo que convierte una librería de código en un sistema que usa más gente. La regla de Curtis es la buena: empieza por las variantes renderizadas y el código que se puede copiar, escribe las guías en imperativo y cambia los muros de texto por contrastes de haz y no hagas. Un token que nadie encuentra se escribe a mano. Un componente que nadie entiende se rehace.

La adopción es el problema que se repite en lo alto de la encuesta de varios años sobre design systems de Sparkbox, y la documentación floja es su causa más común. Un sistema puede ser técnicamente excelente y fallar igual si quien debería usarlo no sabe qué existe ni cómo aplicarlo.

7. Governance (definida pronto, aplicada con el segundo consumidor)

La governance es el modelo de contribución, el esquema de versiones y un dueño con nombre. Responde a quién puede añadir un componente, cómo sale un cambio que rompe la compatibilidad y qué pasa cuando dos equipos piden lo mismo. La defines pronto y empiezas a aplicarla en cuanto un segundo producto depende del sistema. Cómo lo hacemos en más de diez proyectos lo contamos aquí.

Sparkbox encontró que el 36% de los equipos no tiene un proceso definido para aceptar contribuciones. Sin él, el sistema se bifurca: cada equipo pone un parche en local, los parches divergen y en un año tienes un design system sobre el papel y cuatro en la práctica.

Las siete categorías de un vistazo

El orden de construcción, en un párrafo

Primero los tokens, porque todo los referencia. Luego componentes y layout, en paralelo, los dos leyendo de los tokens. Los patrones cuando tengas componentes suficientes para que la guía signifique algo. La accesibilidad tejida en todas las categorías desde los tokens, nunca pegada al final. La documentación escrita sobre la marcha, no al terminar. La governance definida el primer día y aplicada cuando llega el segundo consumidor. Puedes saltarte el orden y publicar un sistema igual. Solo que no escala, y la factura de las reparaciones llega unos doce meses después.