Implementación de un sistema de diseño: la guía que de verdad hace que los equipos publiquen

El cementerio de sistemas de diseño es enorme. En nuestras auditorías de 47 sitios de clientes desde 2023, encontramos sistemas de diseño en distintas fases de abandono en 31 de ellos. El patrón es constante: un sistema de diseño se crea con auténtica ambición, alcanza una adopción parcial y luego diverge poco a poco del producto en producción a medida que el equipo descubre que es más rápido construir componentes desde cero que trabajar dentro del sistema. El problema casi nunca es la calidad de los componentes de Figma. Es la ausencia de tres cosas: una arquitectura de tokens que se traduce directamente a variables de código, un modelo de gobernanza que resuelve los conflictos de contribución sin crear cuellos de botella y una estrategia de adopción que convierte al sistema en el camino de menor resistencia.

Arquitectura de tokens: el modelo de tres capas

Los design tokens son variables con nombre que representan decisiones de diseño: un valor hexadecimal de color, una unidad de espaciado, un radio de borde, una sombra. Cuando se hace bien, cada propiedad visual del producto en producción hace referencia a un token, y actualizar ese token actualiza la propiedad en todos los lugares donde se usa. El modelo de tres capas que genera los sistemas de tokens más mantenibles es el siguiente: la Capa 1 son los tokens globales, valores en bruto sin significado semántico (color-blue-500: #3b82f6). La Capa 2 son los tokens semánticos, casos de uso con nombre que hacen referencia a los tokens globales (color-action-primary: color-blue-500). La Capa 3 son los tokens de componente, anulaciones específicas de cada componente que hacen referencia a los tokens semánticos (button-background-primary: color-action-primary). Esta arquitectura permite que los cambios de color globales se propaguen automáticamente, que el significado semántico se reutilice entre componentes y que los componentes individuales puedan anular valores sin romper el sistema.

Inventario de componentes: auditar antes de construir

El error más común al crear un sistema de diseño es construir componentes antes de auditar lo que ya existe. El proceso correcto: haz una captura de pantalla de cada patrón de interfaz único de tu producto en producción; agrupa los patrones visualmente similares; identifica qué patrones aparecen en más de 3 páginas o pantallas; esos son tus componentes de Nivel 1, los que generarán valor de adopción inmediato si están en el sistema. Construye primero el Nivel 1. Los equipos que usan tus patrones más repetidos son los que más tienen que ganar con una versión de sistema, y se convertirán en tus primeros adoptantes y prescriptores. No empieces por componentes raros o complejos: generan el menor impacto en la adopción y la mayor expansión del alcance.

Gobernanza: la decisión que determina la supervivencia

Hay tres modelos de gobernanza de uso extendido. Centralizado: un equipo dedicado al sistema de diseño es dueño de todos los componentes, revisa todas las contribuciones y toma todas las decisiones. Produce la mayor coherencia, pero crea cuellos de botella que ralentizan a los equipos de producto. Funciona mejor en organizaciones con más de 50 diseñadores de producto. Federado: cada equipo de producto es dueño de sus propios componentes y contribuye a una biblioteca compartida. Produce la mayor velocidad, pero corre el riesgo de incoherencia y duplicación. Funciona mejor en organizaciones con líneas de producto independientes. Híbrido: un pequeño equipo central mantiene la arquitectura de tokens y los componentes de Nivel 1; los equipos de producto tienen autonomía sobre los componentes específicos de producto que siguen los contratos de tokens pero no están en la biblioteca central. Este es el modelo que recomendamos para la mayoría de las organizaciones de entre 5 y 50 diseñadores.

• Define un protocolo de contribución antes de que contribuya el primer equipo externo: quién puede proponer, quién aprueba y cuál es el SLA.
• Versiona tu sistema de diseño de forma semántica (mayor.menor.parche) y publica un registro de cambios en cada versión.
• Mide la tasa de adopción cada trimestre: el porcentaje de interfaz nueva construida con componentes del sistema frente a componentes personalizados.
• El camino más rápido hacia la adopción es hacer que el sistema sea más rápido de usar que construir desde cero: la documentación, las plantillas de inicio y los fragmentos para copiar y pegar importan tanto como los propios componentes.

La métrica de adopción que lo predice todo

Hay una métrica que predice si un sistema de diseño sobrevivirá: ¿cuánto se tarda en construir una página o pantalla nueva usando el sistema en comparación con hacerlo desde cero? Si el sistema es más rápido (incluyendo la consulta de la documentación, la configuración de los componentes y la aplicación de los tokens), se adoptará y se mantendrá. Si es más lento, se abandonará, por muy bien que se vean los componentes en Figma. Mide este tiempo en tu primera revisión de adopción, 3 meses después del lanzamiento. Si el desarrollo basado en el sistema es más lento, el cuello de botella casi siempre es la calidad de la documentación, no la calidad de los componentes. Invierte en mejor documentación, mejores plantillas de inicio y mejores integraciones con las herramientas antes de añadir más componentes.