El design system que nadie sabe en qué estado está
Hace un par de años estaba hablando con el Lead de diseño de una empresa de retail con presencia digital en varios países. Tenían un design system. Tenían Figma. Tenían documentación. Y aun así, cada vez que el equipo pedía más recursos para el sistema, la respuesta de dirección era siempre la misma: "¿Y para qué lo necesitáis si ya tenéis uno?"
El problema no era que no lo tuvieran. El problema era que nadie sabía en qué nivel estaba ni qué le faltaba para ser realmente útil. Cuando llegué a revisar la situación, el design system tenía componentes bien construidos pero ningún token semántico, documentación desactualizada desde hacía ocho meses y una tasa de adopción que rondaba el 30%.
No era un buen design system. Era un design system en nivel 2 presentándose como si fuera nivel 4.
Y eso es exactamente lo que pasa cuando no tienes un marco para evaluarlo.
Madurez no es tener más componentes
El error más común que veo en equipos de diseño es medir la salud de su sistema por el número de componentes. "Tenemos 80 componentes, estamos bien."
Spoiler: no necesariamente.
Un design system puede tener 150 componentes y estar completamente roto si nadie los adopta, si la documentación no existe o si cualquier cambio requiere coordinar manualmente con 5 equipos porque no hay gobernanza.
La madurez de un design system se mide en seis dimensiones, y ninguna de ellas es el número de componentes:
Tokens: ¿Tienes design tokens definidos? ¿Son semánticos (significado) o solo primitivos (valor)? ¿Están documentados y sincronizados entre Figma y código?
Componentes: ¿Qué cobertura tienes? ¿Están todos los estados definidos (vacío, carga, error, éxito)? ¿Tienen tests de accesibilidad?
Documentación: ¿Alguien puede incorporarse al equipo y entender cómo y cuándo usar cada componente sin preguntar a nadie?
Gobernanza: ¿Hay un proceso para proponer cambios? ¿Quién aprueba qué? ¿Hay un roadmap visible para el equipo?
Adopción: ¿Qué porcentaje de las pantallas nuevas realmente usa el sistema? ¿Lo estás midiendo?
Tooling: ¿Tu librería de Figma está sincronizada con el código? ¿Los tokens se actualizan automáticamente o manualmente?
Por qué el audit cambia la conversación con dirección
Volvamos al equipo de retail. Después de hacer el audit por dimensiones, la conversación cambió radicalmente. Ya no era "necesitamos más recursos para el design system". Era: "estamos en nivel 2 en tokens y nivel 1 en gobernanza. Subir a nivel 3 en estas dos dimensiones nos permitiría reducir el tiempo de entrega de nuevas funcionalidades en un 30%."
Eso es algo que dirección puede entender, evaluar y priorizar. Una petición de recursos genérica no.
El audit no solo te dice dónde estás. Te da el lenguaje para hablar de ello con quien no diseña.
La app de evaluación
Para que puedas hacer este audit de forma estructurada, construí el DS Maturity Audit, una app donde evalúas las seis dimensiones del nivel 1 al 5 con descripciones concretas de qué significa cada nivel.
No hay respuestas correctas. Hay respuestas honestas. El valor del audit está en reconocer dónde estás realmente, no dónde te gustaría estar.
Cuando hayas evaluado las seis dimensiones, la app genera un hexágono radar que muestra el perfil de tu sistema de un vistazo. Y puedes exportarlo como Markdown para compartirlo con el equipo o incluirlo en el próximo roadmap.
Oye, si tu design system está en nivel 2 en alguna dimensión, no es un fracaso. Es información. Y la información es lo que te permite planificar.
Cuándo hacer el audit
La primera vez: cuando el equipo empieza a sentir que el sistema no está funcionando como debería pero no sabe exactamente por qué.
Después: cada trimestre o cada vez que haya un cambio significativo en el equipo o en los productos. No es un documento de una vez. Es un termómetro.
Y si vas a pedir recursos para el design system, hazlo después del audit. Así la conversación tiene datos.