Contexto

A medida que el Design System crecía en volumen y complejidad, también aumentaban los problemas de coherencia, duplicación de componentes y falta de control sobre su evolución. Diferentes equipos diseñaban y desarrollaban variantes propias, nacían tokens duplicados o mal nombrados, y las decisiones quedaban muchas veces fuera de control centralizado.

Esto generaba:

• Inconsistencias visuales entre productos y marcas.
• Pérdida de tiempo en discusiones sobre qué componente usar o si uno era “el oficial”.
• Falta de visibilidad sobre cambios, propuestas y adopción del sistema.
• Frustración en los equipos, que no sabían si estaban usando el DS correctamente o si podían proponer mejoras.

El problema no era técnico, era de gobernanza y de procesos compartidos. El Design System no solo necesitaba crecer, sino organizarse con criterios claros, colaboración y responsabilidad compartida.

El Desafío

¿Cómo podíamos establecer una estructura de gobernanza clara y ágil, que permitiera mantener la calidad del DS sin frenar la innovación ni saturar a los equipos con burocracia?

Era clave encontrar el equilibrio entre:

• Control y flexibilidad.
• Centralización y autonomía.
• Escalabilidad y calidad.

La Solución

Desde Design Ops diseñamos un modelo de gobernanza colaborativa, centrado en la claridad de roles, flujos de trabajo definidos y visibilidad compartida.

Estructura de gobernanza

• Design System manager: Se asigna uno responsable de mantener la calidad, validar propuestas y priorizar mejoras.
• Colaboradores por equipos: diseñadores, developers y especialista en accesibilidad que actúan como enlaces y embajadores del DS.
• Canal único de propuestas de cambio: Mediante formularios + seguimiento en Jira.

Flujo de gestión de componentes

• Propuestas estructuradas con contexto, uso esperado y necesidades.
• Evaluación por el responsable de DS.
• Prototipo y validación en entornos reales.
• Aprobación, documentación y publicación.
• Comunicación activa a todo el equipo (changelog, demos, updates).
• Meeting regular llamado Foro de DS, para exponer actualizaciones, dudas, generar debate y tomar decisiones en equipo.

Herramientas y recursos

• Task flow para evaluar qué camino y decisiones tomar para la solicitud y creación de nuevos componentes, modificaciones e incidencias.
• Documento Naming & Convetion, con el acuerdo de cómo nombrar los elementos.
• Checklist de criterios para evaluar si algo entra o no en el DS.
• Documentación abierta.
• Librería de componentes auditada y otra en WIP.

Plan de Medición

Para evaluar el impacto de la gobernanza, diseñamos un plan de medición con KPIs centrados en uso, adopción y calidad del sistema:

Métricas clave

• Número de solicitudes de nuevos componentes y su tiempo de resolución a través de Jira.
• Uso real del DS en archivos Figma (vs. componentes duplicados o sin usar).
• Errores en QA por uso incorrecto del DS.

Métricas cualitativas

• Feedback de diseñadores y desarrolladores sobre el proceso de contribución.
• Nivel de satisfacción con la documentación y la claridad del sistema.
• Detección de frustraciones o bloqueos para ajustar el proceso.

Resultados

• Reducción en la creación de componentes duplicados.
• Mayor participación activa de diseñadores en la evolución del sistema.
• Tiempos de respuesta más claros y transparentes ante propuestas de mejora.
• Mejora en la consistencia visual entre proyectos de distintos equipos.
• Mejora en la percepción de que el DS es “vivo y útil”, no una imposición.