Contribuir a un design system: el proceso paso a paso
Contribuir a un design system es proponer un cambio, justificarlo con un caso real y pasar revisión. Cuándo basta un ticket, cuándo un RFC y qué se evalúa.
¿Qué significa contribuir?
Un design system es un bien común. Cada equipo que añade un componente sin consultar crea otra versión del botón, y en seis meses hay cuatro botones casi iguales. Contribuir es llevar la necesidad a ese espacio compartido, con un argumento que sirva a más de un equipo.
Carbon, el sistema de IBM, lo plantea de forma abierta: cualquiera puede contribuir con código, diseño y documentación (Carbon, “Contributing”).
¿Cuándo basta un ticket y cuándo un RFC?
Una división práctica es separar los cambios pequeños de los grandes:
- Cambios pequeños. Una corrección, un nuevo estado o una mejora de documentación. Van por ticket, con criterios de aceptación claros y revisión rápida.
- Cambios grandes. Un componente nuevo, una API nueva o un cambio que afecta a varios equipos. Van por RFC: un documento que se discute antes de implementar.
El Australian Government Design System lo organiza por etapas: el RFC tiene estado de borrador mientras se discute en el pull request y se fusiona cuando recibe la mayoría absoluta de aprobaciones de los mantenedores (Australian Government Design System, “RFCs”). Ese proceso formal no es necesario en todos los equipos, pero la lógica sirve.
¿Qué lleva una propuesta?
Una propuesta útil responde a cinco preguntas:
- ¿Qué problema resuelve? Con un caso real: la pantalla, el flujo y el equipo que lo necesita.
- ¿Ya existe algo parecido? Si hay un componente que resuelve el 80%, la propuesta debe explicar por qué no basta.
- ¿Quién lo usaría? Cuantos más equipos, más fácil de justificar.
- ¿Cómo se ve y cómo se usa? Con un boceto en Figma y una descripción de estados, variantes y comportamiento.
- ¿Qué criterios de aceptación tiene? Cuándo se considera terminado.
Carbon añade una regla que conviene copiar: todas las categorías de requisitos deben completarse antes de dar un componente por terminado, y todo componente o patrón necesita guía de uso, de estilo, de código y de accesibilidad (Carbon, “Contribute design”). Esas guías son parte del trabajo, no un extra.
¿Qué criterios suelen decidir?
El GOV.UK Design System publica sus criterios de contribución. Antes de proponer, exige evidencia de que el componente o patrón serviría a muchos equipos o servicios (por ejemplo, capturas o enlaces a usos reales) y que no repite algo que ya existe; si reemplaza algo existente, hay que demostrar que funciona mejor. Antes de publicarlo, pide que se haya probado en investigación con una muestra representativa de usuarios, incluidas personas con discapacidad, y que reutilice los estilos y componentes del sistema (GOV.UK Design System, “Contribution criteria”). Para proponerlo, busca primero si alguien ya lo sugirió en las discusiones de GitHub y, si existe, súmate en lugar de abrir otro hilo (GOV.UK Design System, “Propose a component or pattern”).
Como regla práctica de equipo: si el componente se usará en tres o más lugares, merece un espacio en el sistema; si se usará en uno, probablemente sea un componente local.
¿Qué pasa después de proponer?
El proceso no termina con la propuesta. En el repositorio australiano, cualquier persona puede pedir implementar un RFC aprobado añadiendo su nombre en la sección Implementer. GOV.UK prioriza cada año las propuestas de la comunidad, y si la tuya no entra, puedes desarrollarla tú o dejarla para otra persona. Carbon invita a suscribirse a sus horas de oficina, donde ayudan a encontrar una primera contribución según tus habilidades. En cualquier caso, cuenta con que la revisión pida ajustes.
Ejemplo
Ejemplo ilustrativo: un equipo de producto necesita un selector de fechas con rango. Ya existe un calendario simple en el sistema. Antes de crear un componente nuevo, la persona que propone revisa el catálogo y ve que el calendario no maneja rangos ni accesibilidad con teclado. Escribe un RFC con tres casos reales de otros equipos, un boceto en Figma con los estados y una lista de criterios: navegación con teclado, anuncio de rango seleccionado y documentación de uso. El RFC pasa la revisión con dos cambios pedidos por ingeniería. El componente se implementa en dos sprints y, después, el equipo actualiza la documentación de diseño con su uso y sus límites.
¿Cuándo NO conviene proponer algo al sistema?
- Cuando el caso es de un solo equipo. Un componente muy específico se queda mejor en el producto que lo usa.
- Cuando el sistema no tiene mantenimiento. Proponer sobre un sistema que nadie revisa añade deuda.
- Cuando la propuesta no tiene caso real. Un componente hipotético no justifica un RFC.
- Cuando buscas aprobación de una decisión de producto. El sistema define cómo se construye, no qué se vende.
Errores comunes
- Proponer sin revisar el catálogo y duplicar un componente existente.
- Enviar un RFC sin caso real ni boceto.
- Olvidar la accesibilidad y la documentación de uso.
- Crear variantes en lugar de ampliar un componente que ya existe.
- Dejar la propuesta abierta sin responsable ni fecha de revisión.
Cómo empezar mañana
Abre el catálogo de tu design system y busca el componente que más veces has hecho a mano en el último trimestre. Si existe algo parecido, anota qué le falta. Si no existe, escribe la propuesta en una página con problema, caso real, boceto, criterios y quién lo usaría. Pásala a la persona que mantiene el sistema antes de pedir un RFC formal. Y coordina la implementación con el equipo de desarrollo, porque la propuesta solo vale si se puede construir.