Sistema de diseño vs. librería de componentes: la diferencia que cuesta dinero

Una librería de componentes es un conjunto de partes de interfaz programadas y reutilizables con APIs definidas. Un sistema de diseño es el conjunto completo de decisiones que rigen cómo se ve y se comporta una interfaz, además de los artefactos que codifican esas decisiones, siendo uno de ellos, habitualmente, una librería de componentes.

Eso es preciso pero ligeramente inútil, porque no ayuda a distinguir cuál de los dos tiene. Aquí hay una prueba que sí lo hace.

La mayoría de los equipos fallan en esa prueba y se sorprenden, porque sentían que la librería de componentes era la parte difícil. Era la parte costosa. Pero no era la parte que determina si el producto tiene identidad propia.

Esa última fila es la que conviene leer dos veces. El fracaso de una librería de componentes es visible: dos selectores de fecha, tres implementaciones de botones, un error corregido en uno y no en el otro. El fracaso de un sistema de diseño es invisible desde dentro: todo es consistente, nada falla y el producto podría ser el de cualquier otra empresa.

Aquí llegamos a la parte contraintuitiva. Adoptar una librería de componentes bien construida a veces hace que un producto parezca *más* genérico, no menos; conviene entender el mecanismo en lugar de culpar a la librería.

Una librería incluye valores predeterminados. Por necesidad, estos valores son neutrales: deben funcionar para miles de productos distintos, por lo que codifican la versión menos subjetiva de cada decisión. Al instalarla, hereda un conjunto completo de decisiones de diseño elegidas específicamente por ser inofensivas.

Antes de la librería, el producto no tenía sistema y se veía inconsistente. Después, tiene un sistema, pero es el de alguien más, ajustado para una generalidad máxima. La inconsistencia se soluciona, pero se crea un problema de identidad; y como este segundo problema no produce errores, permanece sin nombre durante mucho tiempo.

Esto no es un argumento en contra de las librerías de componentes. Es un argumento a favor de que instalar una completa la mitad del trabajo, y la mitad que completa es precisamente la que ya era visible.

Se suelen utilizar varios términos adyacentes de forma intercambiable. No son sinónimos; son fragmentos diferentes.

Un conjunto de tokens merece especial atención porque es el artefacto que más a menudo se confunde con un sistema completo. Un archivo de valores nombrados es genuinamente necesario, pero no indica para qué se permite usar --color-primary, que es la decisión que determina si la interfaz se percibe como sobria o como una plantilla temática.

Cuatro elementos, ninguno de los cuales puede residir en la API de un componente, y todos los cuales deciden la apariencia del producto.

1. 1

   Reglas de composición

   Cómo conviven los componentes. Una acción primaria por sección. Controles relacionados agrupados, no relacionados separados por un paso de espaciado completo. Tablas nunca anidadas dentro de tarjetas. Una librería de componentes no tiene una opinión sobre qué rodea a sus componentes, y el espacio entre ellos constituye la mayor parte de una pantalla.

2. 2

   Densidad y ritmo

   Si se trata de una herramienta densa o de una superficie de marketing espaciosa. El mismo botón, con un padding de 8px en una fila de tabla y de 16px en un hero, produce dos productos diferentes. La librería soporta ambos y no elige ninguno.

3. 3

   Motivos

   El elemento específico y recurrente que hace que el diseño sea suyo: un tratamiento particular de las esquinas, un uso distintivo de una línea de regla, una forma consistente de dibujar los gráficos. Los motivos son la diferencia entre lo correcto y lo característico, y no existen en ninguna API de componentes.

4. 4

   Prohibiciones

   Lo que nunca se hace. Sin degradados. Sin elevación de sombras. Sin pesos de fuente superiores a 600. Sin colores fuera del conjunto de tokens. Una librería de componentes no puede prohibir nada, porque prohibir es precisamente lo que una librería de propósito general no debe hacer.

El punto de prohibición generaliza más allá del diseño. El trabajo de una librería es ser utilizable por muchos productos, lo que significa permitir todo lo razonable. El trabajo de un sistema es hacer que un producto sea coherente, lo que requiere descartar la mayor parte de aquello. Están estructuralmente opuestos, razón por la cual uno no puede sustituir al otro.

La diferencia es más fácil de ver en una sola primitiva. Una librería de componentes le ofrece un Button con una prop variant y ninguna opinión sobre cómo debería verse cada variante. Un sistema decide, y esa decisión cubre estados para los que la librería solo dejó un espacio:

La distinción era manejable cuando los humanos escribían cada pantalla. Un desarrollador que había visto las diez pantallas anteriores absorbía las convenciones no escritas y, en su mayoría, las reproducía. El sistema de diseño existía en la cabeza de las personas, sin documentar, y eso funcionaba mientras las personas permanecían en el equipo.

Un agente de código de IA no tiene esa memoria. Lee lo que hay en el repositorio, escribe una pantalla y comienza de cero. Todo lo que el equipo sabía y nunca escribió simplemente está ausente, y el agente llena el vacío con el promedio estadístico de todo lo que ha visto, que es por qué las interfaces generadas por IA convergen en la misma apariencia.

Analizamos 299 archivos DESIGN.md escritos específicamente para cerrar esa brecha. Los números indican que la mayoría no lo logra: el 86% especifica los colores como hex raw sin un rol semántico, el 76% no establece ninguna prohibición, el 57% no define motivos, el 69% no dice nada sobre el modo oscuro y el 44% no contiene ningún valor de tamaño concreto en ninguna parte. El 54% depende de al menos un adjetivo vago, con "clean" en el 39% y "modern" en el 36%.

Si se comparan con los cuatro puntos anteriores, se trata de un corpus de archivos que documentan la librería de componentes y la llaman sistema de diseño. Las reglas de composición, la decisión de densidad, los motivos y las prohibiciones brillan por su ausencia.

La buena noticia es que no tiene que reconstruir nada. Si tiene una librería de componentes y tokens, la capa del sistema de diseño es un documento, y es corto.

## Intent

A dense tool for people who work in it for hours. Quiet, information-first.
Not a marketing surface: nothing here has to convince anyone of anything.

## Density

Controls: 8-12px padding. Table rows: 32px. Section gap: 32px.
Marketing surfaces run one step up on every value.

## Elevation

A surface step plus a 1px border. Never a box-shadow.

## Composition

One primary action per section. Related controls share a group;
unrelated ones are separated by a full spacing step.
Tables are never nested inside cards.

## Motifs

Section headings carry a 2px accent rule on the left edge.
Numeric columns are always tabular-nums, always right-aligned.

## Never

- No gradients
- No drop shadows
- No font-weight above 600
- No colour value outside the token set
- No border-radius above 12px

Treinta líneas. No contiene nada que su librería de componentes ya sepa, pero sí todo lo que un nuevo ingeniero —o un agente— necesita para construir una pantalla que pertenezca a su producto y no a los valores predeterminados de la librería.

Casi siempre ambos, pero el orden depende de dónde esté el problema.