Medir la adopción de un design system: métricas que sirven de algo
Qué es la adopción de un design system, qué métricas usar (detach rate, reutilización, cobertura) y cómo leerlas sin convertirlas en un porcentaje que engañe.
¿Qué significa adopción?
El modelo de madurez de zeroheight parte de un modelo de cuatro etapas creado por Sparkbox (V1, Growing, Teenage y Healthy Product) que zeroheight extendió a seis ejes: fundamentos, documentación y conocimiento, gobierno y equipo, adopción, medición e impacto, y preparación para IA. Tómalo como marco para conversar, no como baremo.
La definición que propone el eje de adopción es útil: cuánto del trabajo de producto fluye por el sistema, y si usarlo es el camino de menor resistencia o un impuesto. Esa segunda parte es la clave. Un sistema puede tener cobertura formal y aun así ser más lento de usar que hacer algo a medida.
¿Por qué le importa a un diseñador junior?
Porque casi siempre el trabajo de adopción cae en las manos de quien mantiene el sistema, y a menudo se hace sin métricas. Un junior que sabe leer una métrica de uso puede detectar pronto qué componentes sobran, qué equipos los esquivan y dónde falta documentación. Esa información vale más que un informe trimestral con un porcentaje bonito. Si todavía no tienes claro qué incluye un sistema, el artículo sobre sistema de diseño es el punto de partida.
Además, las métricas de adopción pueden volverse un arma para evaluar personas. Si el sistema se mide mal, la gente deja de usarlo para no aparecer en el peor lugar del tablero.
¿Qué métricas existen?
Figma, en su artículo sobre métricas, menciona lo que muestran sus paneles de analítica de librería: inserciones de componentes, instancias totales, y inserciones y detaches de los últimos 30 días; un filtro para comparar librerías permite seguir el uso entre versiones. Estas son las métricas más útiles y su lectura:
| Métrica | Qué mide | Cómo leerla |
|---|---|---|
| Detach rate | Frecuencia con que se separan instancias del sistema | Un detach alto puede indicar un fallo o una necesidad no cubierta, pero también un componente pensado para personalizarse |
| Reutilización | Porcentaje de interfaces construidas con componentes del sistema (Netguru la llama tasa de reutilización) | Netguru no detalla la fórmula ni fija un objetivo |
| Inserciones por equipo | Qué equipos usan qué componentes | Permite ver qué áreas no adoptan el sistema |
| Migración de versiones | Cuánto se usan versiones antiguas frente a las nuevas | Señala dónde hace falta ayudar a actualizar (en Figma, con el filtro de comparación de librerías) |
| Chequeos de accesibilidad | Porcentaje de componentes que pasan chequeos de accesibilidad | Netguru propone usar herramientas automáticas como Axe, Lighthouse o complementos de Storybook, junto con pruebas manuales; no fija umbral |
Figma advierte que un detach alto no siempre es negativo, y que las métricas son un medio para entender, no un fin en sí mismas.
¿Cómo se lee un detach rate sin engañarse?
Un detach es el momento en que un diseñador separa una instancia del componente original para cambiarla. Puede significar tres cosas distintas:
- El componente no cubre una necesidad real. Se separa porque le falta una variante. Eso es información para el equipo del sistema.
- El componente está mal diseñado o mal documentado. Se separa porque es difícil de usar. Eso también es información.
- El componente está pensado para personalizarse. Se separa a propósito, y un detach alto es el comportamiento esperado.
Por eso no conviene tomar el número como una nota. Conviene revisar los detaches por componente y por equipo, y preguntar a quien lo separó por qué lo hizo. Si el sistema también vive en código, cruza estos datos con los componentes reales en la documentación de Storybook.
¿Qué porcentaje de adopción es bueno?
No hay un número universal, y conviene desconfiar de quien lo ofrece. Netguru, en un artículo que también promociona su propio sistema, incluye entre los criterios de deprecación tener menos de 5 % de adopción en seis meses. Es una heurística de un proveedor, no un estándar, y el artículo no explica cómo medir esa adopción.
Lo más útil es comparar tendencias: ¿sube o baja la reutilización en cada equipo?, ¿qué componentes crecen y cuáles se abandonan?, ¿qué equipo tiene la mayor proporción de detaches? Un número solo no dice mucho, y Figma sugiere segmentar los datos por equipo o producto para ver dónde hace falta apoyo.
¿Cuándo NO conviene medir la adopción así?
- Sin analítica de librería. Según Figma, la analítica de librería actualizada está disponible para clientes de los planes Organization y Enterprise, y su API solo para Enterprise. Sin ella, las métricas automáticas no existen y conviene hacer auditorías periódicas.
- Con pocos usuarios. Si solo tres personas usan el sistema, cualquier porcentaje es ruido. Es mejor hablar con ellas.
- Como evaluación de personas. Si los diseñadores temen que su uso se mida contra ellos, dejarán de usar el sistema o dejarán de reportar detaches.
Ejemplo
Ejemplo ilustrativo: un equipo mantiene un design system para cuatro productos. Tras seis meses, revisa tres métricas:
- Reutilización: el producto principal sube del 40 % al 70 % de pantallas con componentes. Los otros dos productos se estancan en el 30 %.
- Detaches: el componente de tabla se separa en el 60 % de los casos en uno de los productos. Al preguntar, descubren que no permite ordenar por columnas.
- Migración: el 25 % de las pantallas aún usa una versión anterior del botón.
Con eso, el equipo prioriza tres acciones: añadir orden de columnas, ayudar a los dos productos estancados con una sesión de adopción y lanzar una guía de migración del botón. El número global no habría dicho nada de esto.
Para conectar estos datos con objetivos de negocio, el artículo sobre KPIs ayuda a elegir indicadores que no se queden en la cifra técnica. Quién decide qué entra al sistema se trata en gobernanza de un design system.
Errores comunes
- Reducir la adopción a un solo porcentaje agregado.
- Leer un detach alto como fallo automático, sin preguntar por qué.
- Medir adopción sin saber qué equipos y qué componentes hay detrás del número.
- Medir a personas en lugar de medir el sistema.
- Adoptar umbrales de un proveedor como si fueran normas.
- Dejar que la métrica sustituya la conversación con los equipos.
Fuentes
- Figma, Design Systems 104: Making metrics matter
- zeroheight, Design system maturity model
- Netguru, Design system metrics (artículo de un proveedor; úsalo como ejemplo, no como norma)