Gobernanza de un design system: quién decide qué cambia y cómo
La gobernanza de un design system define quién es dueño, quién puede contribuir y cómo se aprueban, versionan y deprecian los cambios. Guía para empezar.
¿Qué problema resuelve la gobernanza?
Un design system falla casi nunca por falta de componentes. Falla porque cada equipo crea su propio botón, su propio modal y su propia versión del color de error. Según el NN/g, la gobernanza es una de las seis dimensiones que determinan la madurez de un sistema, junto con la alineación organizacional, la efectividad de los equipos, la infraestructura, el soporte y la adopción (NN/g: Design-System Maturity).
Para el NN/g, la gobernanza es el modelo operativo para decidir, contribuir y mantener coherente el sistema mientras él y la organización cambian. Cubre cinco temas: los modelos de contribución, cómo se tratan las desviaciones, el equilibrio entre expresión del producto y consistencia de marca, la estrategia de versiones y lanzamientos, y la priorización.
La gobernanza no es burocracia. Es la respuesta a preguntas concretas que alguien tendrá que contestar tarde o temprano:
- ¿Quién decide si entra un componente nuevo?
- ¿Quién revisa un cambio que rompe compatibilidad antes de que salga?
- ¿Qué pasa cuando dos equipos necesitan variantes contradictorias?
¿Qué modelos de propiedad existen?
Las guías de Figma describen tres modelos principales (Figma: Design System Governance):
| Modelo | Quién es dueño | Ventaja | Riesgo |
|---|---|---|---|
| Centralizado | Un equipo dedicado aprueba cada cambio | Consistencia alta | Cuello de botella |
| Federado | Diseñadores de varios equipos comparten la propiedad | Velocidad y pertenencia | Deriva: cada quien hace lo suyo |
| Híbrido | El equipo central es dueño de los fundamentos; los equipos, de sus patrones | Equilibrio | Se vuelve confuso si las reglas no son explícitas |
Figma señala que la mayoría de los equipos empieza centralizado y se mueve hacia un modelo híbrido a medida que el sistema escala. Es una buena referencia para un junior: no hay un modelo correcto, hay uno que corresponde al tamaño del equipo.
¿Cómo se reparten las decisiones?
Una forma práctica de dividir los permisos es por alcance. Figma sugiere que las decisiones a nivel de marca queden en el equipo dueño de los fundamentos, porque afectan a todos los productos que usan la librería (por ejemplo, un token de color base o renombrar un componente compartido). Todo lo demás es decisión de equipo y se mueve más rápido, como una variante nueva de tarjeta para el flujo de un solo equipo.
El GOV.UK Design System también muestra un patrón útil: en lugar de un proceso único, define etapas, desde priorizar qué trabajar hasta publicar, y asigna en cada una un rol que impulsa y otro que apoya. Son nueve etapas en total. Su página de modelo de contribución afirma que no hay un proceso «de talla única» (GOV.UK Design System: Contribution model). La página tiene fecha de revisión vencida (junio de 2024), así que tómala como referencia de estructura, no como norma. Para el detalle del flujo de una propuesta, mira contribuir a un design system.
¿Cómo se versiona y se depreca?
Figma recomienda notas de cambio cortas que digan qué cambió y qué debe hacer alguien, publicadas en la descripción de la librería o en un canal dedicado. Para las deprecaciones, sugiere dar más tiempo de aviso, nombrar el reemplazo y dar a los equipos una ventana de migración antes de que sus archivos dejen de funcionar. No fija cuánto debe durar esa ventana, así que define la tuya según cuántos equipos dependen del componente.
Una práctica común, y no una norma de Figma, es el versionado semántico:
- Mayor: cambios que rompen compatibilidad.
- Menor: componentes o variantes nuevas compatibles hacia atrás.
- Parche: correcciones sin cambio visible de API.
Una regla razonable para empezar: anuncia la deprecación en la misma versión que introduce el reemplazo y mantén el componente anterior funcionando durante al menos una versión menor antes de eliminarlo.
¿Cuándo NO conviene una gobernanza pesada?
Si un solo equipo de ocho personas usa el sistema, un comité de aprobación semanal es un gasto de tiempo. El NN/g propone evaluar la madurez del sistema en equipo y repetir la evaluación, normalmente cada trimestre o tras cambios importantes en la organización; el resultado es una foto del momento, no un diagnóstico permanente. Úsala para decidir cuánta estructura hace falta en vez de imponer la máxima desde el primer día. Empieza con el proceso más ligero que evite la deriva y agrega reglas cuando el problema aparezca de verdad.
Tampoco conviene una gobernanza sin dueño. Un modelo federado sin una persona con la última palabra sobre estándares termina con cuatro versiones del mismo botón.
Ejemplo ilustrativo
Ejemplo ilustrativo: un equipo de producto necesita un chip de filtro que el sistema no tiene. En lugar de crearlo en su proyecto, abre una solicitud en el canal del sistema con un caso de uso y un mockup. El equipo central revisa si ya existe algo parecido, lo decide en una reunión corta y, si entra, el chip se publica en una versión menor con nota de cambio. El equipo de producto no espera semanas por una decisión que pudo tomarse en diez minutos porque las reglas estaban escritas.
Si quieres ver cómo se conecta esto con los tokens, lee Tokens Studio: design tokens desde Figma y el artículo sobre arquitectura de tokens. Para la parte visual del sistema, mira sistema de diseño y paridad de tokens.
Errores comunes
- Escribir un modelo de gobernanza antes de tener un sistema que usar.
- Tener un proceso de contribución sin decisiones de quién aprueba.
- Cambiar componentes sin nota de versión, de modo que cada equipo descubre el cambio al romper su pantalla.
- Confundir «más reglas» con «más calidad»: las reglas que nadie sigue no protegen nada.
- Dejar la deprecación para el final, cuando ya hay veinte archivos que dependen del componente viejo.
Qué puedes hacer mañana
- Escribe en una página de una sola hoja quién es dueño de tokens, componentes y documentación.
- Define un único canal para pedir cambios y una plantilla con caso de uso y mockup.
- Acuerda cómo se numeran las versiones y dónde se publican las notas de cambio.