Qué es un design system y cuándo tu producto lo necesita

Las cuatro capas de un sistema real

Cuando entrego un design system, tiene siempre estas capas:

• ★Tokens: color, tipografía, espaciado, radios, sombras y elevación como variables nombradas, no como valores sueltos. Un token cambia en un lugar y se propaga a todo el producto.
• ★Componentes: botones, campos, tarjetas, tablas, navegación, cada uno con sus variantes y todos sus estados: normal, hover, foco, activo, deshabilitado, cargando, error y vacío.
• ★Patrones: cómo se combinan los componentes para resolver situaciones repetidas — formularios largos, filtros, listados, confirmaciones destructivas.
• ★Documentación: cuándo usar cada cosa, cuándo no, y qué criterios de accesibilidad debe cumplir. Sin esta capa el sistema se degrada en tres meses.

Los estados son el sistema

El error más común es diseñar solo el estado feliz. Las pantallas del portafolio siempre tienen datos perfectos, nombres cortos y listas llenas. La realidad tiene nombres de 60 caracteres, listas vacías el primer día, conexiones lentas y errores de servidor.

Un sistema que define esos estados le ahorra a desarrollo decenas de decisiones improvisadas, que son justo las que hacen que un producto se sienta inconsistente aunque cada pantalla se vea bien por separado.

¿Cuándo lo necesitas?

No siempre. Una landing de una sola página no necesita un sistema, necesita buen criterio. El sistema empieza a pagar cuando: tienes más de 15 o 20 pantallas; hay más de una persona diseñando o desarrollando; el producto va a seguir creciendo por meses; o tienes varias plataformas (web y móvil) que deben verse hermanas.

Y hay una señal clara de que ya lo necesitabas ayer: cuando el equipo pregunta seguido «¿de qué azul es este botón?» o cuando aparecen tres variantes distintas del mismo campo de texto en el mismo producto.

Cómo evitar que se quede sin usar

La mitad de los design systems muere por sobreingeniería: se documenta todo antes de que exista el producto y nadie lo mantiene. La estrategia que funciona es la inversa: empiezas por los tokens y los seis u ocho componentes que ya se repiten, los dejas impecables, y creces el sistema a medida que aparecen necesidades reales.

El otro factor decisivo es la cercanía con desarrollo. Si los nombres de los tokens y de los componentes coinciden entre Figma y el código, el sistema se usa. Si no coinciden, se traduce a mano cada vez y termina abandonado.

Qué recibes cuando trabajo un sistema contigo

Entrego el design system documentado — tokens de color, tipografía y espaciado, componentes con estados y variantes, grillas y documentación de uso — junto a archivos listos para desarrollo: Figma ordenado y nombrado, specs de espaciado y responsive, assets exportados y criterios de accesibilidad WCAG. En la mayoría de proyectos añado también una sesión de handoff con el equipo técnico.