Contribuir a un design system: quién puede añadir un componente

Un modelo de contribución para un design system (en inglés, contribution model) es el conjunto de reglas que decide quién puede cambiar la librería de componentes compartida, qué tipo de cambio puede proponer cada persona y qué camino recorre una propuesta antes de publicarse. La pregunta llega la semana en que un segundo producto adopta el sistema: un diseñador o una desarrolladora de fuera del equipo central ha hecho un componente para su propia pantalla y quiere meterlo en la librería.

El modelo que elijas decide tres cosas a la vez: lo rápido que crece la librería, lo coherente que se mantiene y cuánta parte de la semana del equipo central se va en revisar el trabajo de los demás. Aquí tienes los tres modelos comparados, cómo falla cada uno según los datos, los criterios que dicen si un componente entra en el sistema y el modelo que usamos en el nuestro.

La respuesta corta

Hay tres modelos. En el centralizado solo construye el equipo central y los demás abren peticiones. En el federado diseñadores y desarrolladores de varios equipos de producto construyen el sistema juntos, sin un equipo dedicado. En el híbrido un equipo central es responsable de la librería y acepta contribuciones según su tamaño: correcciones de cualquiera, componentes nuevos solo con una propuesta que demuestre que hacen falta en más de un sitio.

Si tu organización no es un solo equipo, elige el híbrido. El federado por sí solo tiene el peor historial. Nathan Curtis, que en 2015 describió los modelos de equipo solitario, centralizado y federado, escribió en 2024 que de más de 80 design systems en los que ha trabajado como consultor, ninguno funcionó sin personas asignadas al sistema de forma central. Y sobre su propio consejo de entonces: "Favoring federated was and is wrong", apostar por el federado fue y es un error.

¿Cómo se comparan los tres modelos?

En la práctica, nueve equipos de cada diez mantienen un equipo central. En el Design Systems Report 2025 de zeroheight, el 50% de los encuestados usaba un modelo centralizado, el 41% uno híbrido y el 9% uno federado. El mismo informe nombra el problema principal de cada uno: recursos y aislamiento en los centralizados, gestionar y animar las contribuciones en los híbridos y, en los federados, el trabajo del sistema que pierde frente a prioridades cambiantes, hasta el punto de que esos equipos dicen que solo mantienen las luces encendidas.

Dónde gana el modelo centralizado

Con un modelo centralizado cada API habla con una sola voz. Las mismas personas ponen nombre a cada prop, eligen cada valor por defecto y escriben cada guía, así que un componente añadido el tercer año se lee igual que uno del primero. Esa coherencia es la razón de tener un sistema, y un equipo central la protege mejor que nadie.

Atlassian trabaja cerca de este modelo. Su página de contribuciones solo las acepta de gente de Atlassian y, entre ellas, recoge correcciones (un bug en el código, un componente erróneo en la librería de Figma, una frase confusa en la documentación) y mejoras pequeñas como un icono nuevo. Las mejoras grandes y los componentes nuevos, con la visualización de datos como ejemplo, dice que quizá no pueda aceptarlos, porque exigen coordinar todo el sistema: código, diseño y guías.

El precio es la cola. En el informe de zeroheight, el 54% de los encuestados de empresas de más de 500 empleados decía no tener gente suficiente, y entre los motivos estaba una demanda mayor que la oferta, con peticiones que a menudo reciben un "no" o un "todavía no". Un equipo de producto que oye "todavía no" publica su propia versión, y esa copia local es donde empieza el component drift.

Dónde gana el modelo federado

El federado gana cuando quienes construyen los productos son pocos, trabajan cerca y están acostumbrados a revisar el trabajo de los demás. Decide quien siente el problema, los componentes llegan a la velocidad del producto y nadie espera a otro equipo.

Deja de funcionar cuando el grupo crece más allá del punto en que todos saben qué han construido los demás. Curtis describe el patrón: una empresa disuelve el equipo del design system y encarga el sistema a un grupo federado, sin liberar a nadie de su otro trabajo. Seis meses después el sistema está parado, los componentes envejecen y la confianza se tambalea. Las prioridades de producto deciden en qué trabaja cada persona, y nadie tiene tiempo reservado para la librería.

Dónde gana el modelo híbrido

El híbrido mantiene un equipo central responsable de la calidad y abre una puerta de entrada a todos los demás. El ejemplo mejor documentado es el GOV.UK Design System. Su equipo escribió en 2023 que hoy la mayoría de las incorporaciones importantes llegan de fuera, y publica los criterios que una contribución tiene que cumplir:

1. Útil: hay pruebas de que muchos equipos o servicios lo usarían, por ejemplo capturas o enlaces a versiones que ya funcionan en servicios distintos.
2. Único: no repite algo que el sistema ya tiene, o demuestra que es mejor que lo que sustituye.
3. Usable: se ha probado en investigación con usuarios, con una muestra representativa que incluya a personas con discapacidad.
4. Coherente: reutiliza estilos y componentes existentes, y el código sigue los estándares del sistema.
5. Versátil: funciona en los distintos servicios que puedan necesitarlo, y en navegadores, tecnologías de apoyo y dispositivos distintos.

Los dos primeros se comprueban en la propuesta y los otros tres antes de publicar. La división importa, porque quien contribuye sabe si la idea tiene sitio en el sistema antes de dedicarle semanas.

GOV.UK también cambió quién arranca el trabajo. En 2022 el equipo encuestó a su comunidad (302 respuestas, 131 de ellas completas) y puntuó los resultados, dando más peso a lo que ya existía en las librerías de patrones de varios departamentos, se podía construir con componentes existentes, difícilmente necesitaba JavaScript complejo o reducía posibles daños a los usuarios. En 2023 dejó de esperar las propuestas de los equipos: ahora publica sus próximas prioridades y pide a la comunidad que se sume al trabajo.

¿Qué cambios puede enviar cualquiera?

Las contribuciones se ordenan por el tamaño del cambio. La guía de contribuciones de Curtis las divide en dos tipos, y el tipo decide el camino:

• Los cambios pequeños van directos a una pull request: corregir un defecto funcional, visual o de accesibilidad, una mejora objetiva como el estado de foco, el rendimiento, el soporte de navegadores.
• Los cambios grandes pasan por una propuesta: un componente nuevo, un cambio del lenguaje visual que atraviesa los tokens de muchos componentes, una mejora que rompe el markup o el comportamiento, documentación sobre un tema que el sistema aún no cubre.

Para los cambios grandes, Curtis toma de proyectos open source como Rust y Ember el proceso de request for comment: una conversación informal, una propuesta escrita, el triaje, un periodo de debate con la comunidad, la aprobación y, al final, la implementación. El orden protege el tiempo de quien contribuye, porque el paso caro llega después de que los baratos hayan dicho que sí. Un cambio grande que rompe a un consumidor también necesita una versión major, y eso lo decide el versionado del design system.

¿Cómo se decide si un componente entra en el sistema?

Un sistema guarda lo que comparten muchos productos y deja fuera lo que solo necesita uno. Los criterios de Curtis dan las preguntas que hay que hacer a quien contribuye antes de empezar a construir:

1. ¿Le sirve a otro producto, y a cuántos? Su escala: un producto no basta, dos merecen una conversación, tres un debate con la comunidad, cinco probablemente entran.
2. ¿Es coherente con la dirección del sistema, o metería un framework nuevo, un flujo de pruebas nuevo, un tipo de dependencia nuevo?
3. ¿Cuánto cuesta construirlo y mantenerlo? Una pill en pocos colores cuesta poco. Un date picker que cada producto quiere de una forma un poco distinta es la trampa clásica: hecho para todos, no le sirve a nadie.
4. ¿Abre una dirección útil para todos? Un tooltip trae capas, eventos y posicionamiento que luego reutilizan los popovers y los menús.
5. ¿Sabe quien contribuye decir cuándo usarlo, cómo configurarlo y qué evitar? Si nadie es capaz de escribir la guía, el componente no está listo para compartirse.
6. ¿Es el momento adecuado para las dos partes, para la hoja de ruta del sistema y para la persona responsable de quien contribuye?

Después del sí queda trabajo. Curtis escribe que en más de diez años nunca ha visto una contribución lo bastante completa como para entrar tal como llegó. Hay que ampliarla hasta un conjunto mínimo de funciones, quitarle lo que solo necesita su producto y normalizarla según cómo el sistema pone nombres y construye. Ese último paso le toca al equipo central en cualquier modelo, y por eso un modelo de contribución sin equipo central no dura. El mismo razonamiento está detrás de mantener bajo el número de componentes y de las reglas de props que evitan el mal uso.

Qué usamos nosotros y por qué

Usamos un híbrido con un cierre firme para los componentes nuevos. En nuestro design system, un proyecto que lo usa no puede añadir componentes. Cuando una página necesita algo que el sistema no dibuja, el proyecto publica la versión local más pequeña que funcione, en un solo archivo, con un prefijo propio y una línea encima que nombra la tarea que la llevará al sistema. El equipo del sistema la construye allí y la publica, y luego el proyecto actualiza la dependencia y borra su copia local. Una comprobación cuenta las versiones locales en cada build, así la deuda sigue a la vista.

Antes de un componente nuevo, buscamos uno existente que dibuje lo mismo con una prop más. Una fila de logos bajo un grupo de tarjetas se convirtió en un tamaño más pequeño del componente de logos, y la tarjeta no ganó nada. El precio es el tiempo: a veces una página espera una versión para tener su pieza. A cambio, la librería mantiene una sola voz en todas sus API, y las versiones locales forman una lista corta que podemos contar.

Un modelo de contribución vive dentro de un conjunto de reglas más amplio. Gobernar un design system en diez o más proyectos cubre el resto, y por qué se estanca la adopción de un design system explica qué pasa cuando a los equipos de producto entrar en el sistema les cuesta más que construir alrededor de él.