Los design systems están de moda. Toda empresa quiere uno. Toda charla de diseño habla de ellos. Y sin embargo, la mayoría de los design systems que he visto en la práctica son o bien una librería de componentes que nadie usa, o bien un sistema tan rígido que frena más de lo que ayuda.

Trabajé con design systems de distintas escalas — desde el sistema interno de ecoPortal hasta los que armamos para clientes en 55.design. Esto es lo que aprendí sobre cuándo realmente valen la pena.

Cuándo un design system ayuda

Cuando el equipo crece

Si sos el único diseñador y el producto tiene tres pantallas, no necesitás un design system. Necesitás consistencia, sí, pero eso lo podés lograr con un archivo de Figma bien organizado.

Cuando hay dos o más diseñadores trabajando en paralelo, las inconsistencias empiezan a aparecer. Un diseñador usa 14px para labels, otro usa 13px. Uno usa bordes redondeados de 4px, otro de 8px. Individualmente, ninguna de estas diferencias es grave. Acumuladas, crean un producto que se siente descuidado.

Ahí es donde un design system — aunque sea básico — empieza a justificarse.

Cuando la velocidad importa

Un buen design system te permite armar pantallas nuevas como si armaras con bloques. Necesitás un formulario, tenés un componente de formulario. Necesitás un modal, tenés un modal con todas sus variantes. Eso acelera el diseño y, más importante, acelera la implementación.

Cuando la consistencia es crítica

En productos como ecoPortal, donde los usuarios gestionan temas de salud y seguridad, la consistencia no es cosmética — es funcional. Si un botón rojo significa “peligro” en una pantalla y “cancelar” en otra, eso es un problema real.

Cuándo se vuelve burocracia

Cuando actualizar un componente tarda más que diseñar desde cero

He visto equipos donde proponer un cambio a un componente del design system requiere un documento de tres páginas, la aprobación de dos comités, y tres reuniones. Para cuando el cambio se aprueba, el proyecto que lo necesitaba ya lanzó con un componente ad-hoc.

Si tu proceso de gobernanza es más lento que tu velocidad de diseño, algo está mal.

Cuando se convierte en un fin en sí mismo

Hay equipos que dedican más tiempo a mantener el design system que a diseñar el producto. Puliendo animaciones de componentes que nadie pidió. Documentando variantes que nunca se van a usar. Organizando retrospectivas del design system.

Un design system existe para servir al producto, no al revés.

Cuando impide la exploración

Si cada vez que querés probar algo nuevo tenés que “verificar si está en el sistema”, el sistema se convirtió en una jaula. Los design systems deberían tener espacio para la experimentación. Componentes nuevos nacen fuera del sistema y, si funcionan, se incorporan después.

Lo que funciona en la práctica

Después de probar varios enfoques, esto es lo que me funciona:

Empezá pequeño. Colores, tipografía, espaciado, y un puñado de componentes básicos (botones, inputs, cards). Eso es suficiente para el primer año de un producto.

Documentá el “por qué”, no solo el “qué”. Un botón primario es azul: eso es el “qué”. Es azul porque necesitamos que la acción principal se destaque y elegimos un color que funcione sobre fondos claros y oscuros: eso es el “por qué”. El “por qué” es lo que permite tomar decisiones cuando el sistema no tiene una respuesta predefinida.

Mantené la gobernanza liviana. En mi equipo, cualquier diseñador puede proponer un componente nuevo. Lo discutimos brevemente, lo probamos en un proyecto real, y si funciona, lo incorporamos. Sin documentos de tres páginas.

Aceptá la imperfección. Un design system con cobertura del 70% que todo el equipo usa es infinitamente mejor que uno con cobertura del 100% que nadie adopta porque es demasiado rígido.

Mi consejo

Si tu equipo no tiene un design system, empezá con una librería de componentes simple y crecé orgánicamente. Si tu equipo tiene un design system que se siente como una carga, es hora de simplificarlo. El objetivo es consistencia y velocidad, no perfección y control.