Un design system funciona como la única fuente de verdad para definir cómo se ven y se comportan la UX y la UI de una empresa. Si trabajas en front-end o diseño de producto, entender qué es un sistema de diseño te ayuda a escalar productos sin reinventar la rueda y manteniendo un alto estándar de accesibilidad.

Qué resuelve un design system en un equipo de producto

Un sistema de diseño es un set de estándares que centraliza decisiones visuales y funcionales. Es el lugar donde consultas cosas tan concretas como el color de un texto, el radio de un botón, su comportamiento en hover o focus, y la tipografía de un heading de nivel dos.

La magia llega cuando ese sistema se acompaña de una librería de componentes reutilizables: botones, dropdowns, tablas, cards, headings. Esa librería se publica para tu framework favorito —React, Angular o Vue— y la consumes desde cada proyecto, normalmente como paquete de npm o como submodule de Git [2:00].

¿Qué es un design system? Es un conjunto de estándares y componentes reutilizables que define cómo funcionan la UX y la UI de una empresa, y sirve como única fuente de verdad para diseñadores y developers.

Cómo se construye y se documenta la librería de componentes

Un design system es una inversión a largo plazo y un trabajo conjunto entre diseño y desarrollo. Lleva planificación, implementación y un mantenimiento periódico, pero acelera muchísimo la creación de nuevas features porque ya no programas un botón o un submenú desde cero.

La librería debería tener su propio sitio web, y para eso existe Storybook, una herramienta que organiza y visualiza cada componente con sus opciones, estados y documentación [3:30]. Sobre Storybook puedes sumar varias capas de calidad:

• React Testing Library para escribir unit tests sobre los componentes.
• Jest para configurar un mínimo de coverage; un 90% ayuda a evitar errores en producción.
• Axe React para correr verificaciones de accesibilidad junto a tus tests.

Esta combinación te da confianza: si un componente está bien hecho, es accesible y está testeado, esa calidad se replica automáticamente en cada aplicación que lo consuma.

Por qué un componente bien hecho beneficia a toda la empresa

Imagina un acordeón. Lo desarrollas una sola vez en el design system y lo reutilizas todas las veces que quieras en distintos proyectos. Siempre apunta al mismo código fuente, así que existe un único lugar donde testeas la accesibilidad y esa decisión se propaga a todos los productos.

Esto también libera a quienes no se especializan en front-end. Un developer de back-end puede usar componentes accesibles y responsive sin tener que preocuparse por programarlos, y concentrarse en lo que hace mejor.

¿Para qué sirve Storybook en un design system? Sirve para documentar y visualizar cada componente con sus estados, y para integrar tests automáticos de funcionalidad y accesibilidad en un mismo lugar.

Cuándo conviene invertir en un sistema de diseño

El primer caso de estudio es una empresa llamada Fábrica, donde el equipo de front-end y el de diseño empujaron la idea al C-level cuando notaron que la compañía pasaría de un solo producto a varios [6:30]. El argumento de venta fue claro: soportar todos los productos desde una única fuente de verdad, reutilizar piezas y mantener un alto estándar de calidad, performance y accesibilidad.

En unos dos meses tuvieron la primera versión funcional implementada en un proyecto piloto. El sistema se llamó Minerva —porque los design systems necesitan nombre—, aportó valor a los proyectos siguientes y simplificó el mantenimiento de los existentes.

Qué hace especial al design system Carbon de IBM

El segundo caso es Carbon, el design system de IBM y uno de los más reconocidos del mundo [8:30]. Su documentación es referencia obligada y su atención al detalle en accesibilidad es lo que más lo distingue.

Carbon resolvió un problema clásico: elegir combinaciones de color accesibles. Su paleta usa una nomenclatura numérica múltiplo de 10, como gray 10, gray 20, gray 30, hasta gray 90. La regla es simple:

• Si la diferencia entre el número del color de texto y el color de fondo es 60 o más, la combinación es accesible.
• Si la diferencia es menor a 60, no deberías usarla.

Así, un fondo gray 20 exige al menos un texto gray 80, y un fondo gray 30 pide un texto gray 90. Una decisión de sistema que le ahorra a cada developer tener que validar contraste a mano.

¿Cómo asegura Carbon el contraste accesible entre colores? Usa una escala numérica múltiplo de 10 y exige una diferencia mínima de 60 entre el número del color de fondo y el del texto para garantizar contraste accesible.

¿Cuál sería el primer componente que sacarías de tus proyectos para mover a un design system? Cuéntalo en los comentarios.