Un modelo conductual para la adopción de sistemas de diseño

Cómo hacer que el equipo dependa de un sistema en lugar de ignorarlo

Evolución conductual de un sistema de diseño: de herramienta compartida a infraestructura organizacional.

Los sistemas de diseño no fallan por falta de componentes

Durante años, la industria trató los sistemas de diseño como un problema de escalabilidad que podía resolverse con más componentes, más documentación, más reglas y mayor consistencia visual.

Pero incluso sistemas técnicamente correctos terminaban fragmentándose.

Aparecían variantes paralelas. Los equipos duplicaban componentes. Las excepciones se multiplicaban. Y lentamente, los equipos dejaban de depender del sistema.

El sistema existía. El comportamiento organizacional nunca cambió.

El fracaso que cambió mi forma de ver los sistemas de diseño

En 2016 construí uno de mis primeros sistemas de diseño sin referentes claros sobre adopción, gobernanza o escalabilidad.

El objetivo parecía simple: crear consistencia.

Los componentes existían. Las reglas estaban documentadas. La estructura estaba organizada.

Pero los equipos usaban el sistema solo cuando les convenía.

Las decisiones de diseño seguían ocurriendo fuera de la lógica compartida. Cada equipo reinterpretaba el sistema según sus propias presiones, prioridades y formas de trabajo.

El problema no era visual. Era conductual.

La pregunta que cambió todo: ¿Qué hace que un equipo dependa de un sistema en lugar de ignorarlo?

Porque la verdadera adopción no ocurre cuando los equipos simplemente usan una librería.

Ocurre cuando el sistema modifica cómo los equipos toman decisiones, colaboran y escalan producto de forma coordinada.

Los sistemas de diseño no escalan mediante componentes. Escalan mediante comportamiento organizacional.

El modelo

Después de observar patrones repetidos en equipos y organizaciones, comenzó a emerger una progresión.

La adopción madura suele evolucionar en tres etapas:

• Craft
• Contribution
• Leadership

La progresión no es técnica. Es conductual.

Evolución conductual de un sistema de diseño: de herramienta compartida a infraestructura organizacional.

Craft

En la etapa Craft, los equipos usan el sistema como guía.

Diseño y desarrollo comparten componentes, patrones y decisiones visuales. La coordinación todavía depende fuertemente de personas específicas y acuerdos locales.

El sistema reduce inconsistencias, pero todavía no estructura cómo la organización toma decisiones.

El sistema existe. Pero sigue siendo opcional.

Contribution

En la etapa Contribution, el sistema deja de ser únicamente una librería centralizada mantenida por un solo equipo.

Los equipos comienzan a extenderlo, documentarlo y participar en su evolución.

Producto entra en la conversación.

Las decisiones dejan de ser únicamente visuales y empiezan a coordinar prioridades, restricciones y necesidades operacionales compartidas.

El sistema deja de pertenecer a un solo equipo. Se convierte en responsabilidad compartida.

Leadership

En esta etapa el sistema deja de funcionar como una herramienta de UI.

Se convierte en infraestructura organizacional.

Diseño, desarrollo y producto dependen de él para coordinar escalabilidad, consistencia, velocidad y alineación operacional.

El sistema ya no existe únicamente para construir interfaces.

Existe para alinear decisiones.

La organización deja de preguntarse si los equipos deberían usar el sistema.

Trabajar fuera del sistema comienza a ser más costoso que trabajar dentro de él.

Cómo colapsan los sistemas de diseño

Primero aparecen variantes paralelas.

Luego componentes duplicados.

Después excepciones locales.

Finalmente, los equipos dejan de confiar en la lógica compartida y comienzan a resolver problemas fuera del sistema.

Los sistemas de diseño rara vez desaparecen por completo.

Pierden coordinación hasta dejar de ser confiables.

Proceso de degradación de un sistema de diseño: variantes paralelas, fragmentación y pérdida progresiva de confianza organizacional.

Insight final

La diferencia entre un sistema que escala y uno que colapsa rara vez está en la calidad de los tokens, la documentación o los componentes.

Está en el momento en que el sistema deja de ser opcional y se convierte en la forma más eficiente de trabajar para la organización.

Caso relacionado

Las observaciones que dieron origen a este modelo surgieron tras seis años trabajando en sistemas digitales desplegados a escala. → Explorar el modelo completo