Sistemas de diseño que el equipo realmente usa
De la guía viva a los componentes que sobreviven al día a día
Un sistema de diseño no se mide por la cantidad de componentes que documenta, sino por cuántos se usan sin discutir. Esa frase suena cómoda en una presentación, pero en la práctica es donde se cae la mayoría de las guías de estilos: quedan archivadas en un enlace que nadie abre, mientras el equipo sigue resolviendo cada pantalla a mano. El problema no suele ser el diseño inicial, sino el mantenimiento. Nadie definió quién actualiza, cuándo se agrega un componente nuevo ni qué pasa cuando un caso real no encaja en lo documentado.
Hay tres motivos que se repiten. Primero, la guía se construyó como un entregable cerrado y no como una referencia viva. Segundo, los componentes cubren el caso ideal pero no los bordes: estados de error, textos largos, permisos distintos, versiones móviles. Tercero, no hay acuerdos escritos sobre accesibilidad, así que cada persona decide por su cuenta si un contraste alcanza o si un foco de teclado es suficiente. Cuando eso pasa, el sistema deja de ahorrar tiempo y empieza a generar discusiones.
La alternativa es tratar la guía como parte del trabajo, no como un anexo. Reglas claras de contribución, ejemplos anotados que muestren el porqué de cada decisión y una revisión periódica de lo que se usa y lo que no. Si un componente lleva meses sin aparecer en ninguna pantalla, probablemente no resuelve un problema real. Si aparece siempre con parches locales, probablemente está mal definido. Ese tipo de señales son más útiles que cualquier inventario de piezas.
El objetivo no es tener el sistema más grande, sino el que el equipo consulta antes de inventar algo nuevo. Una guía viva se actualiza con el uso, no con la teoría.
Si querés ver cómo se aplica esto en un caso concreto, podés leer la auditoría heurística de un onboarding que perdió claridad o escribir directamente desde la página de contacto para plantear tu situación.