← Volver al blog

Qué es un design system (y cuándo NO necesitás uno)

"Design system" es una de esas frases que se usan para justificar tanto trabajo necesario como trabajo desperdiciado, y la diferencia entre las dos cosas no está en la definición del término. Está en si el proyecto realmente lo necesitaba.

La definición sin marketing

Un design system es la combinación de tres cosas: tokens (los valores nombrados: color, espaciado, tipografía), componentes (las piezas construidas con esos tokens: botones, tarjetas, inputs) y reglas de uso (cuándo usar cada componente y cuándo no).

No es una librería de componentes. Una librería de componentes es solo la segunda pieza de las tres. Podés tener cuarenta componentes bien hechos y no tener un design system, si no hay tokens consistentes detrás y nadie documentó cuándo usar cada uno.

Cuándo sí vale la pena

Cuando el mismo patrón visual se repite en tres o más pantallas. Si el mismo tipo de tarjeta, con la misma estructura, aparece en el listado de proyectos, en el blog y en la página de recursos, ya hay evidencia de que vale la pena convertirla en un componente reutilizable con reglas claras.

Cuando más de una persona va a tocar la interfaz. Sin un sistema documentado, cada persona nueva toma sus propias micro-decisiones — un espaciado ligeramente distinto, un tono de gris levemente diferente — y esas decisiones se acumulan hasta que el producto se ve como si lo hubieran diseñado tres personas distintas, porque efectivamente así fue.

Cuando el producto va a crecer en pantallas, no solo en usuarios. Un design system amortiza su costo en la pantalla número quince, no en la número dos. Si el proyecto tiene un roadmap de crecimiento real, el sistema paga la inversión inicial con creces.

Cuándo es sobre-ingeniería

Un proyecto de una landing page. Si el producto entero es una página, construir tokens semánticos, variantes de componentes y documentación de uso es trabajo invertido en flexibilidad que ese proyecto nunca va a necesitar. Ahí alcanza con tener valores consistentes copiados con criterio, sin la maquinaria completa.

Un prototipo de validación. Si todavía no sabés si el producto va a sobrevivir a la primera versión, invertir en un sistema escalable es apostar tiempo a un futuro que quizás no llega. La disciplina correcta ahí es velocidad, no reutilización.

Cuando sos el único que va a tocar la interfaz, para siempre. Esto es más raro de lo que parece, pero existe: un proyecto interno, de una sola persona, sin planes de crecer en equipo. Ahí, un sistema formal de documentación de reglas de uso es overhead que no tiene a quién servir — vos ya sabés las reglas, las tenés en la cabeza.

La señal más confiable que uso

Me pregunto: ¿ya vi este patrón repetirse dos veces, o creo que se va a repetir alguna vez?

Si ya se repitió dos veces, sistematizarlo ahorra trabajo real, porque la tercera repetición ya está por venir y conviene que sea más rápida que las dos anteriores. Si todavía no se repitió y estoy anticipando, generalmente estoy adivinando mal la forma que el sistema necesita tener — porque un patrón que nunca vi usado dos veces no me dio suficiente información sobre qué variantes de verdad hacen falta.

El punto medio que uso en la mayoría de los proyectos

No siempre hace falta el extremo completo — Storybook, documentación exhaustiva, tokens en tres capas. En proyectos chicos-medianos, uso una versión liviana: tokens definidos desde el principio (eso casi nunca sobra, cuesta poco y ahorra mucho), un puñado de componentes base bien hechos, y las reglas de uso viviendo en mi cabeza y en comentarios de código, no en un documento aparte que hay que mantener sincronizado.

El sistema completo, con documentación formal, lo reservo para proyectos donde sé que otra persona va a tener que entender las reglas sin poder preguntarme directamente. Ese es el caso que realmente justifica el costo extra.