Un design system no tiene que empezar siendo una plataforma interna, una librería publicada en npm ni una documentación enorme con todos los casos posibles.
Para mí, un design system sencillo empieza mucho antes: cuando decides que los botones no van a tener cinco estilos distintos según el día, que los espacios siguen una lógica, que los colores tienen nombre y que los componentes se pueden reutilizar sin miedo.
No hablo de crear algo perfecto. Hablo de crear una base que ayude a trabajar mejor.
Qué entiendo por un design system sencillo
Cuando trabajo en proyectos pequeños o medianos, intento evitar dos extremos.
El primero es no organizar nada. Cada pantalla tiene sus estilos, cada componente inventa sus tamaños y cada nueva sección parece venir de otro producto.
El segundo es montar un sistema demasiado grande para el problema real. Tokens infinitos, documentación pesada, variantes que nadie usa y una estructura que da más trabajo del que ahorra.
El punto que suelo buscar está en medio:
- Estilos base para colores, tipografía, espaciado, radios y sombras.
- Componentes reutilizables para las piezas que aparecen una y otra vez.
- Tokens con nombres claros para no depender de valores sueltos.
- Reglas simples para saber cuándo crear algo nuevo y cuándo reutilizar.
Eso ya es muchísimo.
Primero organizo los estilos
Antes de pensar en componentes, intento dejar clara la base visual del proyecto.
No hace falta tener una guía de marca gigante. Pero sí necesito saber cuáles son los colores principales, cómo se comportan los textos, qué escala de espacios voy a usar y qué aspecto tienen las superficies.
Normalmente separo esta base en grupos muy sencillos:
- Color: fondo, superficie, borde, texto principal, texto secundario, acento y estados.
- Tipografía: familias, tamaños, pesos y alturas de línea.
- Espaciado: una escala corta que pueda repetirse sin pensar demasiado.
- Bordes: radios y grosores.
- Elevación: sombras o capas, si el producto las necesita.
La clave está en que estos valores no vivan escondidos dentro de cada componente.
Si un botón usa #dcf05d, una card usa otro verde parecido y un badge usa un tercero casi igual, el sistema empieza a romperse. Prefiero tener un token tipo --color-brand y que el resto del proyecto hable ese idioma.
Después vienen los tokens
Los tokens son una forma de poner nombre a decisiones de diseño.
No son magia. No hacen que una interfaz sea buena por sí solos. Pero ayudan mucho a que el proyecto sea consistente y fácil de cambiar.
Por ejemplo, en vez de escribir valores sueltos por todo el CSS:
.button {
background: #dcf05d;
border-radius: 8px;
padding: 12px 16px;
}prefiero algo así:
:root {
--color-brand: #dcf05d;
--color-surface: #121215;
--color-border: rgba(255, 255, 255, 0.12);
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--radius-md: 8px;
}
.button {
background: var(--color-brand);
border-radius: var(--radius-md);
padding: var(--space-3) var(--space-4);
}La diferencia parece pequeña, pero se nota cuando el proyecto crece.
Cambiar un color, ajustar un radio o revisar una escala de espaciado deja de ser una búsqueda por todo el código. Además, los nombres explican intención. --color-border comunica más que rgba(255,255,255,.12).
Tokens globales y tokens semánticos
Me gusta separar mentalmente dos tipos de tokens.
Los tokens globales son valores base:
--gray-100--gray-900--green-400--space-4--radius-md
Los tokens semánticos explican para qué se usa algo:
--color-bg--color-surface--color-text--color-text-muted--color-brand--color-danger
En proyectos pequeños, muchas veces no necesito una capa enorme de tokens globales. Puedo trabajar directamente con tokens semánticos y mantenerlo simple.
Lo importante es no nombrar las cosas solo por cómo se ven hoy. Si llamo a un token --color-green-button, el día que el botón deje de ser verde el nombre se vuelve mentira. Si lo llamo --color-action-primary, aguanta mucho mejor.
Componentes: pocos, pero bien elegidos
No todo merece ser un componente reutilizable.
Una tentación habitual es convertir cualquier trozo de HTML en componente demasiado pronto. Pero si una pieza solo aparece una vez, o todavía no está claro cómo va a evolucionar, prefiero dejarla vivir un poco antes de abstraerla.
Suelo crear componentes cuando se cumple alguna de estas condiciones:
- Aparece en varias pantallas.
- Tiene estados o variantes claras.
- Encapsula una interacción.
- Tiene reglas visuales que quiero proteger.
- Reduce ruido en las páginas.
Ejemplos típicos:
ButtonInputCardBadgeModalTabsArticleCardCallout
La idea no es tener una carpeta de componentes enorme, sino una carpeta útil.
Variantes sin volverse loco
Un componente puede complicarse muy rápido si intentas cubrir todos los casos desde el principio.
Con los botones, por ejemplo, suelo empezar con pocas variantes:
primarysecondaryghostdanger
Y pocos tamaños:
smmdlg
Eso ya cubre la mayoría de interfaces. Si algún día aparece una necesidad real, se añade. Pero no diseño variantes para situaciones imaginarias.
También intento que las variantes representen intención, no decoración. primary tiene sentido. greenBigRoundedWithShadow no.
La estructura que suelo usar
Depende del framework, pero la idea general suele parecerse a esto:
src/
├── components/
│ ├── Button.astro
│ ├── Card.astro
│ ├── Badge.astro
│ └── Callout.astro
├── styles/
│ ├── global.css
│ ├── tokens.css
│ └── prose.css
└── layouts/
└── BaseLayout.astroEn proyectos muy pequeños, incluso puedo tener todo en global.css mientras no moleste.
La estructura no tiene que impresionar a nadie. Tiene que ser fácil de entender cuando vuelves al proyecto dentro de tres meses.
Documentar lo justo
La documentación de un design system pequeño no debería ser una carga.
Muchas veces basta con dejar claros tres puntos:
- Qué tokens existen y para qué se usan.
- Qué componentes hay y qué variantes soportan.
- Qué reglas no conviene romper.
Por ejemplo:
Button
- primary: acción principal de una vista
- secondary: acción alternativa
- ghost: acción ligera o de bajo peso visual
- danger: acciones destructivasNo hace falta escribir una novela para cada componente. Pero sí conviene dejar pistas para que el sistema no dependa solo de tu memoria.
Cuándo crear algo nuevo
Esta es una de las decisiones más importantes.
Antes de crear un color, un tamaño, un componente o una variante nueva, intento hacerme estas preguntas:
- ¿Ya existe algo parecido?
- ¿La diferencia tiene intención real o es solo visual?
- ¿Esto se va a repetir?
- ¿Estoy resolviendo un caso concreto o inventando flexibilidad futura?
- ¿El sistema mejora con esto o se vuelve más difícil de usar?
Si la respuesta no está clara, normalmente espero.
Un design system sencillo también se mantiene diciendo que no.
Lo que intento evitar
Hay varias señales de que el sistema se está desviando:
- Muchos tokens que nadie sabe cuándo usar.
- Componentes con demasiadas props.
- Variantes creadas para un único caso.
- Valores hardcodeados dentro de páginas.
- Diferencias visuales pequeñas pero constantes.
- Documentación que nadie actualiza.
Cuando aparece esto, no siempre hace falta rehacerlo todo. A veces basta con limpiar nombres, eliminar variantes muertas y volver a alinear componentes con los tokens.
Conclusión
Para mí, un buen design system sencillo no es el que tiene más piezas, sino el que reduce decisiones repetidas.
Si cada vez que construyo una pantalla tengo que decidir de nuevo el color del borde, el tamaño del texto, el padding de una card o el estilo de un botón, el sistema no está ayudando.
Pero si tengo una base clara de tokens, unos componentes bien elegidos y unas reglas simples, el trabajo fluye mejor. La interfaz se vuelve más consistente, el código se lee mejor y los cambios dejan de sentirse como una operación delicada.
Ese es el objetivo: no tener un design system perfecto, sino uno que acompañe al proyecto sin ponerse en medio.