Leí esta semana un artículo de Nielsen Norman Group escrito por Huei-Hsin Wang que me hizo repensar algo que di por sentado durante años: la idea de que un design system "madura" subiendo peldaños, del típico esquema de armar componentes, después lograr adopción, después escalar y por último llegar a un estado estable de gobernanza. Wang argumenta que ese modelo lineal, aunque cómodo para presentar en un roadmap, no refleja cómo funcionan los sistemas de diseño en la vida real. Y después de haber visto de cerca cómo un rediseño organizacional puede tirar abajo meses de trabajo de adopción de un día para el otro, coincido plenamente.
El problema de pensar la madurez como una escalera
Los modelos lineales asumen que el progreso es siempre hacia adelante: hoy estás en el escalón 2, el año que viene en el 3. Pero la autora señala algo que cualquiera que haya trabajado en un design system sabe por experiencia: los sistemas retroceden. Una fusión trae otro sistema con tokens incompatibles. Un cambio de prioridades de negocio deja al equipo de design system sin presupuesto. Una reorganización dispersa al equipo que sostenía la gobernanza. Ninguno de estos escenarios es "fracaso": es simplemente cómo se mueven las organizaciones reales. Además, un startup de 10 personas y una empresa de 10.000 pueden tener sistemas igual de maduros, aunque las condiciones que definen esa madurez sean completamente distintas. Medir todo con la misma escalera ignora el contexto.
Las 6 dimensiones que sí capturan la realidad
En lugar de una escalera, el artículo propone evaluar el sistema en seis ejes independientes, y armar con ellos un perfil, no un puntaje único:
- Alineación organizacional: si el sistema tiene un sponsor ejecutivo, presupuesto estable y es entendido como infraestructura compartida y no como un servicio opcional.
- Efectividad del equipo: si el equipo tiene la capacidad, la mezcla de disciplinas y la dinámica de colaboración para sostener el trabajo en el tiempo.
- Robustez de la infraestructura: la calidad de los componentes, los tokens, la documentación y las herramientas —lo más visible, pero no necesariamente lo más determinante.
- Gobernanza: quién decide qué entra al sistema, cómo se gestionan las excepciones y cómo se versionan los cambios sin romper a los equipos que dependen de ellos.
- Soporte: cuánto invierte el equipo en que el sistema sea encontrable, entendible y usable —un componente que nadie sabe que existe podría no existir.
- Adopción: no solo si se usa, sino si se usa bien y si los equipos confían en él lo suficiente como para no crear variaciones por su cuenta.
Lo que más me gustó es que estas dimensiones son independientes entre sí. Podés tener una alineación organizacional excelente y una gobernanza inexistente al mismo tiempo, y eso te dice algo mucho más útil que un "estamos en el nivel 3 de 5".
Leer la forma, no solo el número
El artículo propone plotear el puntaje de cada dimensión (de 1, "ausente", a 5, "excepcional") en un gráfico de radar hexagonal, y leer la forma resultante. Un sistema con un puntaje altísimo en infraestructura pero bajísimo en soporte no es un sistema maduro con un detalle pendiente: es un sistema con un desequilibrio real, porque el equipo invirtió en construir lo que le resultaba más cómodo (componentes) y descuidó lo que sostiene que la gente realmente los use. Wang lo llama detectar valles (un puntaje bajo que arrastra al resto hacia abajo) y picos (una inversión desproporcionada que puede compensar —o disfrazar— una carencia en otro lado).
Esto me parece aplicable más allá de los design systems: cualquier producto o proceso interno donde midamos "madurez" con un número único está perdiendo la información más valiosa, que es dónde está el desequilibrio.
Mi reflexión
Trabajé en equipos donde el design system se medía puramente por cobertura de componentes, como si documentar cien componentes garantizara que alguien los use bien o que el equipo detrás pueda sostenerlos. El framework de NN/g me da un lenguaje mejor para explicar por qué eso no alcanza: un sistema con infraestructura sólida pero sin gobernanza clara ni soporte activo es, en la práctica, un catálogo bonito que la gente rodea en lugar de usar. La autora agrega algo que me parece clave para llevar esta conversación a liderazgo: la evaluación en sí misma, hecha en grupo con el equipo del sistema, representantes de producto y sponsors, genera alineación —a veces más valiosa que el puntaje final.
"La madurez de un design system no es un estado fijo ni una métrica única para optimizar, sino un balance dinámico entre múltiples dimensiones."
¿Cómo mide tu equipo la salud de su design system: con una escalera o con un perfil? Me gustaría leer tu opinión. Podés escribirme en LinkedIn.