Adopción del design system estancada: 5 causas y cómo resolverlas

La adopción de un design system se estanca cuando la infraestructura está lista y los hábitos no: el paquete está instalado en cada repositorio, la librería de Figma está publicada y, aun así, las pantallas nuevas salen con botones locales, instancias desvinculadas y colores hexadecimales escritos a mano. Las instalaciones suben y el uso real no se mueve. Aquí van las cinco causas que buscamos cuando un sistema deja de extenderse, y cómo se resuelve cada una.

Es fácil pasarlo por alto, porque todas las métricas de infraestructura parecen en orden. La dependencia está, los tokens se generan, la web de documentación funciona. Lo que no ha cambiado es la decisión que toma un diseñador o un desarrollador al final del día, con una entrega encima: usar el sistema, o escribir la pieza en local y seguir.

¿Cómo se ve una adopción estancada en un código real?

Hay cuatro señales, aparecen juntas y todas se pueden contar.

• Instalado, pero no importado. Todas las apps tienen el paquete entre sus dependencias, y un escaneo muestra que tres o cuatro componentes concentran casi todas las importaciones.
• Copias locales. Un PrimaryButton.tsx o un CardWrapper en la carpeta de la app que reproduce un componente del sistema con una prop cambiada.
• Instancias desvinculadas en los archivos de diseño. Figma registra un detach cada vez que alguien rompe el vínculo entre una instancia y su componente principal, y las analíticas de la librería muestran el recuento por componente (Figma Help Center).
• Valores sueltos en los estilos. Colores hexadecimales y espaciados en píxeles escritos directamente en el CSS, donde ya existe un token.

Ninguna de estas señales es un fallo por sí sola. Una instancia desvinculada puede ser un boceto; un componente local, un prototipo. Lo que cuenta es la tendencia: si los cuatro recuentos suben en cada versión mientras el paquete sigue al día, el sistema está instalado y se esquiva.

¿Por qué se estanca la adopción después del lanzamiento?

Las encuestas siguen el problema desde hace años. En el Design Systems Survey 2021 de Sparkbox, el 44% de los encuestados internos marcó aumentar la adopción como una dificultad, y la adopción figura en esa lista desde la edición de 2018. La misma encuesta la vincula a los resultados: entre quienes califican su sistema de «no exitoso», el 83% señala la adopción como uno de sus problemas principales, frente al 9% de quienes lo califican de «muy exitoso» (Sparkbox).

Los equipos que llevan los sistemas también van justos. El Design Systems Report 2026 de zeroheight, con 147 respuestas, indica que 3 de cada 5 equipos de design system no tienen gente suficiente para cumplir sus objetivos, y que la satisfacción con el apoyo que consigue la organización bajó en un año del 42% al 32% (zeroheight). Un equipo pequeño y con poco apoyo puede sacar la infraestructura. Le quedan muchas menos horas para cambiar cómo trabajan los demás equipos, y ahí es donde se decide la adopción.

Las cinco causas que buscamos

1. El componente falta justo el día que hace falta

El martes, un desarrollador necesita un selector de rango de fechas. El sistema tiene selector de fecha, pero no de rango. El ticket se entrega el jueves. La versión local se escribe, se revisa y se fusiona, y desde entonces es la que reutiliza ese equipo. Cada hueco del catálogo es un fork en espera, y el fork sobrevive al hueco: cuando el sistema añade el rango dos meses después, nadie vuelve atrás para cambiarlo.

Solución: mantener pública la lista de huecos conocidos, cada uno con una fecha prevista, y publicar para cada uno un patrón provisional aprobado: una composición de piezas existentes, explicada en un párrafo. Con una alternativa oficial sale un único fork compartido en lugar de seis privados, y un solo fork se migra sin problema.

2. Pedir cuesta más que hacerlo uno mismo

Si proponer un cambio al sistema supone un formulario, una reunión de revisión y dos semanas de espera, con la entrega encima lo racional es construirlo en local. La adopción sigue al coste del camino. Cuando contribuir es más lento que esquivar, esquivar gana cada vez que se compara con un sprint.

Solución: fijar un tiempo de respuesta para las propuestas de contribución (dos días laborables para una primera respuesta es un objetivo realista) y un camino ligero para los cambios pequeños: una prop, una variante, un token. La revisión completa queda para los componentes nuevos. Cómo decidimos si un componente nuevo merece existir lo contamos en la dieta del design system.

3. La documentación explica qué, no cuándo

Una tabla de props y un ejemplo en vivo explican qué hace un componente. No dicen cuándo usarlo, cuándo usar el de al lado ni qué hacer cuando ninguno encaja. Y esa es justo la pregunta que alguien se hace en el momento de elegir. La investigación de zeroheight de 2026 sobre IA en design systems indica que solo el 17% de 123 encuestados considera su documentación «muy preparada para la IA» (zeroheight). Agentes y personas se atascan en la misma pieza que falta: la regla para elegir.

Solución: añadir a cada página de componente un bloque «Cuándo usarlo» y otro «Cuándo no usarlo», cada uno con la alternativa. Después, leer durante un mes el canal de soporte y convertir cada pregunta repetida en una línea de esos bloques.

4. Nadie mide el uso, así que nadie ve la deriva

Sin un recuento, desde dentro un sistema estancado y uno que crece parecen iguales. Medir sale barato. El equipo de ingeniería de Brevo pasa react-scanner por todos sus repositorios con una matriz de GitHub Actions, guarda los informes y muestra en Metabase el uso de componentes por proyecto (Brevo Engineering). En diseño, las analíticas de librerías de Figma dan inserciones y detaches por componente. El escaneo del código está explicado con más detalle en component drift: cómo se degrada un design system.

Solución: seguir tres cifras por producto, cada mes: la parte de las importaciones de interfaz que viene del sistema, el número de componentes locales que duplican uno del sistema y la tasa de detach por componente de la librería. Y publicarlas donde los equipos de producto las vean.

5. La adopción no es un objetivo del equipo de producto

El equipo del sistema se ocupa del sistema. El equipo de producto se ocupa de una hoja de ruta con fechas. Si ningún objetivo de producto menciona el sistema, cada tarea de migración compite con una funcionalidad y pierde. A quien tendría que adoptar el sistema se le evalúa por otra cosa.

Solución: incluir la adopción en los objetivos del propio equipo de producto, como una cifra ligada a sus pantallas («a final de trimestre el checkout usa solo componentes del sistema»), y presupuestar las horas en el mismo plan. Con muchos productos sobre un mismo sistema, la parte de gobierno está en cómo gobernar un design system en 10 proyectos.

¿Cuánto cuesta una adopción estancada?

El coste aparece el día que cambia el sistema. Una corrección de accesibilidad en el botón del sistema llega a todas las pantallas que lo importan, y a ninguna de las que lo copiaron. Un rebranding actualiza los tokens, y los colores escritos a mano se quedan con el tono antiguo. Cada fork convierte un cambio en una búsqueda por todo el código. Para ponerle cifra, está el ROI de un design system como partida de la cuenta de resultados.

¿Cómo se recupera una adopción que ya se ha estancado?

1. Sacar una foto inicial. Lanzar un escaneo de uso en cada repositorio y exportar el informe de detaches. En una tarde se tienen las tres cifras de arriba.
2. Ordenar los forks. Listar las copias locales según cuántas pantallas las usan, y empezar por la primera.
3. Cerrar el hueco detrás de cada fork. Si un fork existe porque falta una variante, primero se añade la variante al sistema y luego se migra.
4. Migrar con un equipo de producto cada vez. Poner a alguien del sistema con ese equipo durante un sprint, meter la migración en su hoja de ruta y publicar las cifras de antes y después.
5. Tratar los detaches como informes de error. Un detach en un componente de la librería dice que el componente no encajaba. Cada mes se revisan los diez más desvinculados y se decide: variante nueva, mejor documentación o excepción aceptada.

¿Cómo evitar que se vuelva a estancar?

Las reglas van donde se trabaja. La regla color-no-hex de Stylelint marca los colores hexadecimales en las hojas de estilo (Stylelint), y no-restricted-imports de ESLint puede bloquear importaciones desde una carpeta de componentes locales obsoleta o desde una segunda librería de interfaz (ESLint). Con una regla de lint, una pauta se convierte en un comentario en la pull request, justo en el momento de elegir.

Después, las tres cifras se revisan cada mes, el tiempo de respuesta a las contribuciones se cumple y la lista de huecos sigue pública. La adopción se mantiene mientras usar el sistema siga siendo el camino más barato para quien tiene la entrega encima.