Design System: fundamentos y estructura

Un Design System no es solo una librería de botones. Es el conjunto de decisiones de diseño que el equipo ha acordado, documentado y puede reutilizar de forma consistente.

La diferencia entre tener una librería de componentes y tener un sistema de diseño es la misma que entre tener código y tener arquitectura: el segundo escala, el primero se derrumba.

Por qué existe un Design System

Sin un sistema, cada diseñador toma sus propias decisiones sobre color, espaciado, tipografía y comportamiento. Cada desarrollador interpreta esas decisiones a su manera. El resultado es un producto que se ve diferente en cada pantalla, que tarda más en construir y más en mantener.

Un Design System bien construido produce:

• Consistencia: el mismo patrón, el mismo aspecto, el mismo comportamiento en todo el producto.
• Velocidad: los diseñadores trabajan con componentes, no desde cero. Los desarrolladores tienen referencias claras.
• Calidad estable: las decisiones de accesibilidad, estado y comportamiento se resuelven una vez y se aplican en todos los sitios.
• Vocabulario compartido: diseño, producto y desarrollo hablan el mismo idioma cuando dicen “card”, “modal” u “badge”.

Las capas de un Design System

Un Design System se construye en capas. Cada capa depende de la anterior.

Capa 1: Fundaciones

Las fundaciones son las decisiones visuales más básicas del sistema. Todo lo demás se construye sobre ellas.

• Color: paleta primaria, secundaria, semántica (éxito, error, alerta, información) y de grises. Cada color tiene un nombre de token, no solo un valor hexadecimal.
• Tipografía: familias, escala de tamaños, pesos, alturas de línea y espaciado entre letras. Definida en una escala con nombres (heading-xl, body-md, label-sm) no en píxeles sueltos.
• Espaciado: una escala fija de valores (4, 8, 12, 16, 24, 32, 48, 64…) que se usa en márgenes, paddings y gaps. El espaciado libre lleva a la inconsistencia visual.
• Grid y layout: número de columnas, gutters y márgenes para cada breakpoint.
• Elevación y sombras: valores de box-shadow para cada nivel de elevación (0 = plano, 4 = card, 8 = dropdown, 16 = modal).
• Bordes y radios: valores de border-radius para cada tipo de elemento.
• Motion: duraciones y curvas de animación estándar para transiciones e interacciones.
• Iconografía: estilo definido (outline, filled, duotone) y tamaños permitidos.

Capa 2: Tokens

Los tokens son variables nombradas que conectan las decisiones de las fundaciones con el código. Son el puente entre diseño y desarrollo.

Esto lo cubriremos en detalle en la lección siguiente.

Capa 3: Componentes

Los componentes son elementos de interfaz reutilizables: botón, input, card, badge, modal, dropdown, table…

Un componente bien definido en un Design System incluye:

• Anatomía: qué partes lo componen y cómo se relacionan.
• Variantes: las distintas versiones posibles (primario, secundario, destructivo…).
• Estados: default, hover, focus, active, disabled, loading, error.
• Tamaños: si el componente tiene versiones de tamaño (sm, md, lg).
• Comportamiento: qué pasa cuando se interactúa con él.
• Reglas de uso: cuándo usarlo y cuándo no.
• Anti-patrones: qué combinaciones o usos están explícitamente prohibidos.

Capa 4: Patrones

Los patrones son soluciones reutilizables a problemas de diseño recurrentes que combinan varios componentes. Por ejemplo:

• Formulario de registro: cómo se organizan los campos, cuándo se valida, cómo se muestran los errores.
• Tabla con filtros y paginación: qué controles van dónde, cómo se comporta cuando no hay resultados.
• Pantalla de error: qué contiene, qué acciones ofrece, cuándo aparece.
• Empty state: estructura, ilustración, mensaje y llamada a la acción.
• Notificaciones y toasts: cuándo usar cada tipo, cuánto tiempo duran, dónde aparecen.

Los patrones documentan el “cómo” para que nadie tenga que reinventar la rueda cada vez que necesita añadir un formulario a una nueva pantalla.

Capa 5: Documentación

Sin documentación, el Design System solo vive en la cabeza de quien lo creó. La documentación lo hace usable por el resto del equipo.

Cada componente y patrón necesita:

• Cuándo usar y cuándo no usar.
• Ejemplos de uso correcto.
• Ejemplos de uso incorrecto.
• Consideraciones de accesibilidad.
• Código o referencia al componente en Storybook.

Herramientas habituales: Zeroheight, Notion, Storybook, la documentación integrada de Figma.

Capa 6: Gobernanza

La gobernanza define quién puede cambiar el sistema, cómo se proponen y aprueban esos cambios y cómo se comunican al equipo.

Sin gobernanza, el Design System se fragmenta. Cada equipo hace su propia variante de los componentes y en seis meses tienes cinco versiones distintas del botón primario.

Cuándo tiene sentido empezar a construirlo

No todos los proyectos necesitan un Design System desde el primer día.

Señales de que es el momento:

• El producto tiene más de una pantalla y más de un diseñador.
• Los desarrolladores están reimplementando los mismos componentes en distintas partes del código.
• Hay inconsistencias visuales notables entre distintas secciones del producto.
• El equipo tarda más en mantener que en construir.

Señales de que es demasiado pronto:

• Estás en fase de validación y el producto cambia cada semana.
• El equipo tiene una sola persona.
• No hay acuerdo sobre el producto en sí todavía.

Construir un Design System demasiado pronto sobre un producto que no ha encontrado su dirección es un desperdicio. Espera a que haya suficiente estabilidad para que las decisiones que documentes sigan siendo válidas en seis meses.

Tipos de Design System según el equipo

• Sistema mínimo: tokens de color y tipografía + 10-15 componentes core. Para equipos pequeños que necesitan consistencia básica sin mantenimiento intensivo.
• Sistema completo: todas las capas, con documentación detallada y componentes en código. Para equipos medianos o grandes con múltiples productos.
• Sistema federado: un core compartido entre productos con extensiones por producto. Para organizaciones con varios equipos que comparten marca pero tienen necesidades distintas.

¿Qué hemos aprendido?

• Un Design System es el acuerdo documentado sobre cómo se ve y se comporta el producto.
• Se construye en capas: fundaciones, tokens, componentes, patrones, documentación y gobernanza.
• Tiene sentido cuando hay suficiente estabilidad en el producto y suficiente equipo para que la consistencia sea un problema real.
• Sin gobernanza, el sistema se fragmenta.

Siguiente paso

En la próxima lección veremos Tokens y componentes: qué son exactamente los tokens de diseño, cómo se nombran, cómo se estructuran y cómo se sincronizan con el código.