Un sistema de diseño es un conjunto mantenido de tokens, componentes, patrones y documentación que da a los equipos de producto una fuente de verdad para UI coherente a escala. Este artículo responde la pregunta fundacional: qué es, cómo se apilan las capas, cuándo falla y cuándo no lo necesitas. Para profundidad por herramienta, usa otras guías de la serie en lugar de repetir la misma definición: qué es un sistema de diseño en Figma (Variables y bibliotecas), madurez del sistema de diseño (cinco niveles y scorecard) y cómo construir un sistema de diseño en Figma (pasos de implementación).
Flujos relacionados: Que es un sistema de diseno en Figma, Madurez del sistema de diseno, y Guia de design tokens de Figma.
Sistema de diseño en una frase
Un sistema de diseño son reglas compartidas y versionadas de cómo se ve y se comporta tu producto - expresadas como tokens con nombre, componentes reutilizables, patrones probados y documentación que diseño e ingeniería usan por igual.
Cómo encaja este artículo en la serie
- Esta página = definición, cuatro capas, modos de fallo, cuándo omitir o empezar.
- Qué es un sistema de diseño en Figma = archivos Figma, Variables, bibliotecas (no repite esta intro).
- Madurez del sistema de diseño = evaluar niveles 1-5 y puntuar al equipo.
- Cómo construir un sistema de diseño en Figma = checklist de implementación tras decidir construir.
Un sistema de diseño es un conjunto de estándares para gestionar el diseño a escala reduciendo la redundancia y creando un lenguaje compartido y consistencia visual en páginas y canales. - Nielsen Norman Group
Qué es realmente un sistema de diseño
No es un archivo Figma, un paquete npm ni Storybook - es el acuerdo que representan: decisiones mantenidas, versionadas y con dueno que conectan diseno con codigo de produccion. El Nielsen Norman Group lo define como estandares para gestionar diseno a escala con componentes y patrones reutilizables. La palabra mantenido es clave: componentes en Figma que nadie actualiza son una instantanea. En la practica, la brecha mas comun es tratar un kit como sistema - sin tokens, sin proceso de release ni propietario, y la deriva vuelve en meses.
Las cuatro capas
Todo sistema maduro apila cuatro capas. Cada una depende de la inferior. Sin tokens, rebrands y temas nuevos obligan a repintar manualmente cientos de componentes.
Tokens
↓
Componentes
↓
Patrones
↓
DocumentaciónMuchos archivos Figma etiquetados como «sistema de diseño» son kits estáticos: estilos en lugar de Variables, sin estructura de colecciones, sin camino al código. El equipo lo nota en el primer rebrand al editar hex archivo por archivo.
Design tokens
Los tokens son decisiones visuales con nombre: color, espaciado, tipografía, radio, sombra y movimiento - no hex sueltos. El Grupo Comunitario de Design Tokens del W3C estandariza JSON portable. En Figma viven como Variables; en código son custom properties o constantes TypeScript con los mismos nombres.
Sistemas fuertes usan primitivos (gray/50, blue/600) y semánticos (text/primary, interactive/default). Los componentes se vinculan a semánticos para que el modo oscuro sea un interruptor, no un repintado. Detalle: guía de tokens de Figma.
/* Primitivos - valores en bruto */
gray/50 → #f9fafb
gray/950 → #030712
blue/600 → #2563eb
/* Semánticos - modo claro */
background/default → gray/50
text/primary → gray/950
interactive/default → blue/600
/* Semánticos - modo oscuro (mismos nombres) */
background/default → gray/950
text/primary → gray/50
interactive/default → blue/500Biblioteca de componentes
Componentes reutilizables documentados: botones, inputs, navegación, modales, tablas. Los de sistema usan tokens, variantes claras y actualización desde un master. Un conjunto enfocado suele cubrir la mayor parte de la UI. Pasos: cómo construir un sistema de diseño en Figma.
Patrones
Patrones sobre componentes: auth, estados vacíos, onboarding, tablas filtradas. Son composiciones probadas más rationale - no un solo widget.
Documentación
La documentación explica intención: cuándo usar acciones primarias o destructivas, contrastes WCAG, espaciado por breakpoint. Sin ella, el mal uso crece con el tamaño del equipo.
Sistema de diseño vs biblioteca vs guía de estilo
Tres niveles de madurez, no sinónimos. Equipos llaman «sistema» a un kit y no escala sin tokens, código y gobernanza. Identifica tu nivel real antes de construir; usa madurez del sistema de diseño para puntuar.
Comparación de madurez
| Guía de estilo | Biblioteca de componentes | Sistema de diseño | |
|---|---|---|---|
| Referencia visual | Sí | Sí | Sí |
| Componentes reutilizables | No | Sí | Sí |
| Design tokens | No | Rara vez | Sí |
| Conexión con código | Ninguna | Opcional | Requerida |
| Theming / modo oscuro | No | Manual | Automático vía tokens |
| Gobernanza | Ninguna | Informal | Propietario + proceso |
| Escala con el equipo | No | Parcial | Sí |
La guía de estilo documenta decisiones. La biblioteca las empaqueta. El sistema de diseño las conecta al código de producción y les da proceso para mantenerse actuales.
Guías relacionadas en español
Si ya tienes impresiones en Search Console pero pocos clics, empieza por las guías con más tráfico en /es/blog/: Claude Design, modo oscuro con Variables, Figma vs Pencil y plugins de tokens. El índice completo está en /es/blog/.
Por qué fallan los sistemas de diseño
La mayoría de fallos son de gobernanza. Se añaden tokens, se publica Storybook y sigue la deriva porque nadie posee releases y la documentación envejece. Patrón recurrente: biblioteca con hex codificado, sin responsable, abandonada tras v1. Solución: propietario, tokens en código, tratar el sistema como producto con cadencia de release.
- Componentes sin tokens - rebrands y temas exigen repintados manuales.
- Sin propietario nombrado - deriva en meses.
- Documentación escrita una vez - workarounds y desconfianza.
- Tokens que no llegan al código - ingeniería mantiene un set paralelo.
- v1 demasiado grande - lanzamientos de seis meses se abandonan; releases lean de cuatro semanas se usan.
Sistemas sanos: tokens primero, nombres compartidos, pipeline de export y trabajo de adopción. Ver mejores prácticas.
Calidad del sistema: sano vs en decadencia
| Dimensión | Sistema sano | Sistema en decadencia |
|---|---|---|
| Estructura de tokens | Primitivos + semántica, sync con código | Hex plano sin alias |
| Nombres | Diccionario compartido | Nombres solo en diseño |
| Sync de código | Pipeline y PRs de tokens | Copiar-pegar manual |
| Docs | Actualizadas al publicar | Wiki obsoleta |
| Gobernanza | Propietario e intake | Peticiones ad hoc |
| Mantenimiento | Auditorías y deprecaciones | Componentes obsoletos sin retirar |
Ejemplos reales de sistemas de diseño
Material, Polaris, Carbon y Atlassian comparten: tokens como capa de primera clase, bibliotecas Figma y paquetes de código con la misma nomenclatura, pipelines explícitos diseño-producción. Úsalos como arquitecturas de referencia.
- Google Material Design - sistema tonal, motion, componentes multiplataforma.
- Shopify Polaris - tokens, biblioteca Figma, npm alineados.
- Carbon (IBM) - open source, custom properties, Style Dictionary; niveles primitivo y semántico.
- Atlassian Design System - tokens semánticos claro/oscuro, objetivos WCAG AA.
Cuándo NO necesitas un sistema de diseño
Un sistema completo es overhead que puedes omitir cuando la superficie de UI es pequeña, las convenciones son estables o nadie lo mantendrá. Casos habituales:
- Un producto, un diseñador y pocas pantallas recurrentes - basta un kit ajustado.
- MVP pre-PMF con UX que cambia cada semana - el coste de proceso supera el beneficio.
- Web o campaña de marketing puntual con marca fija en PDF o slides.
- Entrega de agencia al cliente sin sistema propio - documenta el archivo, no construyas gobernanza org-wide.
- Equipo de menos de tres personas sin plan de escalar diseño o front-end - solo tokens + cinco componentes si los mantendrás.
- Herramientas internas con poco riesgo de marca - la velocidad prima hasta que crezca el uso.
Omitir un sistema es válido; fingir que un kit estático es un sistema, no. Si luego llegan rebrand, segundo producto o auditoría fallida, revisa los disparadores de la siguiente sección.
Cuándo construir uno
Construye cuando un coste medible fuerza la decisión - no por sensación de madurez. Rebrand en cientos de pantallas, auditoría de accesibilidad fallida o segundo producto ya desalineado son disparadores típicos.
- Rebrand que exige tocar 300+ pantallas a mano
- Auditoría a11y fallida por componentes one-off
- Nuevos ingenieros no pueden enviar durante semanas porque las reglas están solo en la cabeza del equipo
- Segundo producto debe parecerse al primero y ya se ve distinto
- Hay presupuesto para propietario y cadencia de release, no solo un archivo Figma
v1 lean: tokens de color y espaciado, cinco componentes (botón, input, nav, tarjeta, alerta), biblioteca publicada, propietario. Profundidad de tokens: guía de tokens de Figma. Export: Tokens Studio, Style Dictionary o plugins que emiten DTCG, CSS o TypeScript.
Si más adelante adoptas asistentes de código IA, tokens y docs importan aún más - ese flujo está en tokens para generación de código IA, no aquí, para mantener esta página en la definición central.
Veredicto final: sistemas de diseño
Un sistema de diseño es infraestructura, no un entregable único. Compensa cuando los tokens llegan al código, un propietario mantiene componentes y el equipo lo trata como producto. Empieza por tokens, publica una biblioteca lean, conecta export, asigna propietario. Mide progreso con el scorecard de madurez cuando superes la definición.
