¿Tu sistema de diseño está fracasando?
Puede que nadie lo haya dicho en voz alta, no haya un “post mortem” oficial ni un momento dramático… pero tú ya estás viendo las señales, aunque todavía no lo tengas del todo claro.
En los últimos años se ha hablado mucho sobre sistemas de diseño. De escalabilidad, de consistencia, de tokens, de componentes y de librerías compartidas. De lo que se habla menos es de cuando no funcionan.
Y, sin embargo, los sistemas de diseño fracasan. Más de lo que parece.
No suelen explotar ni desaparecer de un día para otro. Simplemente empiezan a perder relevancia: se usan menos, se consultan menos, se esquivan más.
Siguen ahí, publicados en Figma, con su documentación más o menos ordenada, pero dejan de ser el punto de referencia real para construir producto.
Cuando eso pasa, el sistema ya no está vivo. Está en modo archivo.
Y casi nunca es por un problema visual.
Suele ser por motivos organizativos, culturales y estratégicos.
El error de creer que un sistema de diseño es una librería bonita
Durante años se ha confundido “sistema de diseño” con “librería de componentes”.
Botones bien construidos, inputs coherentes, tipografías definidas, tokens ordenados.
Todo eso importa, claro. Pero no basta.
Un sistema de diseño no es una colección de piezas. Es un acuerdo organizativo.
Es una manera compartida de tomar decisiones entre diseño, desarrollo y negocio.
Cuando ese acuerdo no existe —o nunca llegó a consolidarse— el sistema empieza a resquebrajarse.
He visto sistemas técnicamente impecables que nadie usa. No porque estén mal hechos, ¡qué va!, sino porque no encajan en la realidad del equipo, porque ralentizan, porque no resuelven casos reales o porque no evolucionan al ritmo del producto.
Y cuando el sistema no ayuda, los equipos hacen lo que haría cualquier usuario ante una interfaz que no le facilita la vida: buscan atajos.
Aquí el usuario no es el cliente final. Son los diseñadores y los desarrolladores.
Si ellos no lo sienten útil, lo abandonan. ¡Adiós!
Cuando nadie decide (o todos deciden)
Uno de los puntos más delicados —y menos visibles— es la gobernanza.
¿Quién decide qué entra en el sistema?
¿Quién prioriza mejoras?
¿Quién dice “esto sí” o “esto no”?
Cuando no hay una respuesta clara, llegan las excepciones. Después las reinterpretaciones. Y al final, las versiones paralelas.
El sistema se vuelve algo opinable. Y cuando todo es opinable, nada es estable.
La gobernanza no va de burocracia, va de diseño organizativo: reglas claras para que la consistencia no dependa del estado de ánimo de cada sprint.
Sin esa estructura, el sistema de diseño deja de ser sistema y pasa a ser una referencia opcional que cada equipo usa “si le encaja”.
El momento en el que deja de evolucionar
Otro patrón habitual: tratar el sistema como un proyecto con fecha de entrega.
Se lanza una versión inicial, se documenta, se celebra… y se pasa a otra cosa.
Pero el producto no se detiene.
Aparecen nuevas necesidades, nuevos patrones, nuevos contextos. Si el sistema no acompaña ese crecimiento, se queda atrás.
Entonces llegan las excepciones “temporales” que, casi siempre, acaban siendo permanentes.
Un sistema de diseño que no evoluciona genera fricción. Y la fricción genera abandono.
Como diseñador UX lo conozco muy bien: cuando algo dificulta avanzar, el usuario busca otra vía.
Aquí pasa lo mismo, solo que los usuarios son los equipos internos.
Cuando el sistema de diseño no habla el idioma de negocio
Hay algo que se repite en muchas organizaciones: el sistema de diseño se ve como algo “del equipo de diseño”.
Un proyecto bonito, ordenado, incluso ambicioso. Pero no estratégico.
Si no se conecta con métricas reales —velocidad de entrega, reducción de deuda técnica, coherencia entre productos, eficiencia en desarrollo— pierde peso en la conversación.
Y lo que no pesa, pierde prioridad.
Lo que pierde prioridad, pierde recursos.
Lo que pierde recursos, pierde mantenimiento.
Y lo que pierde mantenimiento, pierde credibilidad.
No es un desplome repentino. Es una caída lenta.
Las señales silenciosas
El fracaso rara vez se anuncia.
Llega en pequeños gestos:
- Los equipos duplican componentes “porque es más rápido”.
- La documentación se consulta cada vez menos.
- Nadie tiene claro cuál es el roadmap.
- Las actualizaciones no se comunican.
- El sistema de diseño deja de aparecer en las conversaciones de producto.
El día que el sistema de diseño ya no está en la mesa donde se toman decisiones, empieza su irrelevancia.
Y eso no tiene tanto que ver con el diseño visual como con cómo está montada la organización alrededor de él.
Diseñar sistemas de diseño es diseñar organizaciones
Crear un sistema de diseño no es solo diseñar UI. Es diseñar cómo se colabora.
Es definir cómo se toman decisiones compartidas.
Es estructurar cómo se escala coherencia en un entorno que, por defecto, tiende al caos.
En ese sentido, un sistema de diseño es uno de los ejercicios más complejos de UX que hay: el usuario no es uno, son muchos, y con intereses distintos.
Si solo miramos los componentes, estamos ignorando la mitad del problema.
Entonces, ¿por qué fracasan realmente?
Fracasan cuando dejan de ser útiles.
Cuando no están alineados con la realidad.
Cuando no tienen liderazgo claro.
Cuando no evolucionan.
Cuando no se conectan con la estrategia.
No se caen por un botón mal diseñado.
Se caen cuando la organización no está preparada para sostenerlos.
Y ahí está la parte incómoda: el sistema de diseño no es solo una herramienta. Es un espejo.
Refleja el nivel de madurez organizativa… y a veces no gusta lo que devuelve.