Cuando una empresa crece y multiplica sus productos digitales, mantener la coherencia visual y funcional se convuelve un reto enorme. Los design systems surgen como la respuesta más efectiva para garantizar calidad, accesibilidad y velocidad de desarrollo en todos los proyectos de una organización.
¿Qué es un design system y por qué es la única fuente de la verdad?
Un design system es un conjunto de estándares que define cómo funcionan la UX y la UI de una empresa [0:18]. Su propósito es convertirse en la única fuente de la verdad: el lugar donde cualquier persona del equipo puede consultar información sobre colores de texto, bordes de botones, estados de hover, colores de foco o la tipografía de un heading de nivel dos.
Pero no se limita a documentación visual. Un buen design system incluye su propia librería de componentes con elementos como botones, dropdowns, tablas, cards y headings [0:48]. Estos componentes se distribuyen generalmente como un paquete a través de NPM o como un submodule de Git, listos para integrarse en el framework de preferencia: React, Angular o Vue [1:03].
¿Cómo se garantiza la calidad de los componentes?
La librería de componentes debería tener su propio sitio web, algo que se logra con Storybook [1:48], una herramienta que permite organizar y visualizar cada componente con sus opciones, estados y documentación. A Storybook se le pueden agregar unit tests con React Testing Library y configurar Jest para establecer un mínimo de coverage [2:06]. Aunque cumplir con un noventa por ciento de cobertura puede parecer tedioso, ayuda enormemente a prevenir errores en producción [2:26].
Además, se puede integrar Axe para ejecutar tests de accesibilidad directamente dentro de Storybook [2:36]. Esto genera confianza en que cada componente cumple con estándares de accesibilidad antes de llegar a cualquier producto.
¿Por qué un componente accesible construido una vez beneficia a toda la empresa?
La gran ventaja de las librerías de componentes es la reutilización con garantía de calidad [2:48]. Si construimos un acordeón accesible, responsive y bien testeado una sola vez dentro del design system, cada proyecto que lo utilice hereda automáticamente esas propiedades [3:12]. Existe un único lugar donde se testea la accesibilidad, y ese resultado se replica en todas las instancias.
Esto también libera a los desarrolladores de back end de preocuparse por la accesibilidad o el diseño responsive de los componentes que consumen [3:42]. Pueden concentrarse en lo que mejor hacen, confiando en que la librería ya resolvió esos aspectos.
¿Qué podemos aprender de los casos de estudio reales?
Dos ejemplos ilustran el impacto concreto de implementar un design system.
En una empresa referida como Fábrica, un equipo de front end y diseño trabajó en conjunto para convencer al C Level de invertir en un sistema de diseño [4:20]. La motivación surgió cuando la empresa, que originalmente tenía un solo producto, comenzó a planificar múltiples productos nuevos. Querían soportar todos los productos desde un único lugar de la verdad, reutilizar componentes y mantener altos estándares de calidad.
- La primera versión funcional se implementó en un proyecto piloto en dos meses [5:00].
- El design system se llamó Minerva y aportó valor inmediato a los proyectos posteriores.
¿Qué hizo Carbon de IBM para resolver el contraste de colores?
Carbon, el design system de IBM, es uno de los más reconocidos del mundo [5:28]. Su documentación es una referencia obligada para cualquier equipo que construya su propio sistema.
Lo más ingenioso de Carbon es su sistema de números para manejar colores accesibles [6:05]. Las tonalidades de gris se nombran con múltiplos de diez: gris 10, gris 20, gris 30. La regla es simple:
- Si la diferencia numérica entre el color de fondo y el color de texto es de 60 o más, la combinación es accesible [6:30].
- Si la diferencia es menor a 60, no debería usarse.
Por ejemplo, un fondo gris 20 requiere mínimo un texto gris 80. Un fondo gris 30 necesita un texto gris 90. Este enfoque elimina la incertidumbre que enfrentan los desarrolladores al elegir combinaciones de colores y demuestra lo que se puede lograr cuando diseñadores y desarrolladores trabajan juntos [6:55].
Si estás considerando implementar un design system en tu equipo, revisar la documentación de Carbon es un excelente punto de partida. ¿Ya has trabajado con algún design system? Comparte tu experiencia en los comentarios.
