Contribución al design system sin romper el que ya existe

El standup del martes es donde estas cosas mueren. Ha pasado tres días en Figma construyendo lo que pensaba que era una variante limpia y pequeña de un selector de rango de fechas. El DS lead echa un vistazo al enlace, se recuesta y dice: "Ya tenemos ese componente." Y usted hace el cálculo mental. O sus tres días están perdidos, o la versión que se publica es la de uso único que construyó a las carreras, que nadie gestiona y que en ocho meses un nuevo diseñador reconstruirá llamándola por cuarta vez.

Ambos resultados son malos. La buena noticia es que la brecha entre ellos es un problema de proceso, no de talento. He visto a diseñadores IC publicar en sistemas maduros en dos semanas y he visto a profesionales senior quemar seis meses intentando hacer pasar una variante de botón por un guardián. La diferencia rara vez era el trabajo en sí. Casi siempre era el modelo de contribución.

Este es el modelo funcional de ese proceso.

Por qué esto importa ahora

Los sistemas fragmentados cuestan más que los lentos. Hay dos modos de falla que veo en todos los equipos que tienen problemas con esto, y parecen opuestos pero producen el mismo resultado.

El primero es el sistema con demasiados guardianes. El equipo de DS gestiona todo. Las contribuciones necesitan tres aprobaciones y un espacio en el roadmap trimestral. Los IC dejan de intentarlo después del segundo rechazo. La biblioteca se calcifica. Los nuevos patrones se construyen fuera de ella porque es más rápido, y ahora tiene un design system que en realidad es un museo.

El segundo es el caos sin control. Cualquiera puede publicar cualquier cosa. En el sexto mes, cada squad de producto tiene su propio componente de lista desplegable, tres botones "primarios" en distintos tonos de azul y una página de Figma llamada "TEMPORAL: NO USAR" que todos usan. Bienvenido al impuesto de la fragmentación.

Un equipo de producto típico que audito tiene entre 3 y 7 versiones del "mismo" botón en el segundo año. No porque nadie lo quisiera así. Porque el flujo de contribución era demasiado rígido o demasiado libre, y el camino de menor resistencia fue construir localmente y no reintegrarlo nunca.

El modelo que se presenta a continuación es el punto intermedio. Parte del supuesto de que contribuir es una habilidad de diseño, no política, y que el IC que publica trabajo limpio en el DS acumula influencia más rápido que quien construye una biblioteca privada de componentes.

Cuándo usar el DS y cuándo construir un nuevo componente

La mayoría de las conversaciones sobre "necesitamos un nuevo componente" terminan en el momento en que alguien aplica la prueba del 80/20. Son dos preguntas:

1. ¿Puedo resolver el 80% de esto con un componente existente más props o una variante?
2. Si lo agrego, ¿al menos el 20% de los equipos lo usará en seis meses?

Si la respuesta a la primera es sí, no necesita un nuevo componente. Necesita una variante o un prop, que es una contribución más pequeña, rápida y barata. Si la respuesta a la primera es no pero la segunda también es no, esto es un uso único. Manténgalo local, no contamine la biblioteca.

Un nuevo componente solo se justifica cuando ambas respuestas apuntan en la dirección correcta: el kit existente no cubre el caso y más de un equipo lo reutilizará.

La trampa que veo con más frecuencia es lo que llamo la trampa del "casi funciona". Un diseñador encuentra un componente que cubre el 70% del caso. Lo desvincula, ajusta el padding, cambia un token y lo publica como "basado en" el existente. Seis meses después ha divergido en siete maneras invisibles y el responsable del design system no tiene registro de que nada de eso ocurrió. El "casi funciona" es peor que empezar desde cero porque finge ser reutilización.

Un árbol de decisión más sencillo, en orden:

• Componente existente, sin cambios → úselo.
• Componente existente, nueva prop o estado → proponga una variante sobre el existente.
• Componente existente pero el comportamiento subyacente es incorrecto → proponga una refactorización, no una bifurcación.
• Patrón genuinamente nuevo, varios equipos lo necesitan → proponga un nuevo componente.
• Patrón genuinamente nuevo, solo su equipo lo necesita → constrúyalo localmente, márquelo como local, revíselo en 90 días.

La última opción está bien. Los componentes locales no son un pecado. Pretender que un componente local es un componente del sistema sí lo es.

El flujo de contribución: RFC, revisión, publicación y documentación

Una vez que ha decidido que vale la pena agregar, el flujo tiene cuatro etapas, cada una con tiempo acotado. El proceso completo debería tomar menos de dos semanas para una contribución normal. Si tarda más, algo está mal en el proceso, no en el componente.

Etapa 1, RFC (1 a 2 días). Una página. Problema, solución propuesta, alternativas consideradas, notas de accesibilidad y un boceto. No seis mockups. El error que cometí durante años fue invertir demasiado en fidelidad antes de la conversación. Un solo boceto permite al DS owner cuestionar la dirección sin que usted sienta que tiene que defender tres días de trabajo en píxeles.

El RFC también es donde se señalan las dependencias: nuevos tokens, nuevos íconos, comportamientos que afectan componentes existentes. Si descubre que necesita un nuevo token de color para que esto funcione, eso ahora forma parte del RFC, no una sorpresa el día ocho.

Etapa 2, revisión con el DS owner (1 a 3 días). Asíncrona primero, sincrónica si está bloqueada. La revisión no es teatro de aprobación. Es una sesión de co-diseño. El DS owner no es su obstáculo. Es la persona que terminará manteniendo lo que usted publica, por lo que su opinión sobre nomenclatura, props y casos límite es estructural, no estilística.

Llegue con el RFC, haga tres preguntas: ¿pertenece esto al sistema?, ¿la forma propuesta coincide con los patrones existentes?, y ¿qué me falta del lado de ingeniería? Salga con un sí/no/necesita-trabajo y un único responsable del lado del DS que revisará el PR final.

Etapa 3, publicación tras una bandera de feature (3 a 5 días). Constrúyalo en Figma, constrúyalo en Storybook, publique el componente React/Vue/lo-que-sea en una bandera de feature o un canal beta en la biblioteca publicada. Publicar tras una bandera importa porque permite que usted y uno o dos adoptantes tempranos pongan a prueba la API antes de que esté en el kit de producción. La mayoría de los errores de API aparecen en el primer uso real, no en el RFC.

Etapa 4, documentación y promoción (1 día). Story publicada, documento de uso escrito, notas de obsolescencia si reemplaza algo, anuncio en el canal del DS con un párrafo de "cuándo usar este componente." Luego promuévalo de beta a GA en la próxima versión de la biblioteca.

Si alguna etapa supera su tiempo acotado, es una señal. Que la etapa 1 se extienda significa que el problema no está claro. Que la etapa 2 se extienda significa que el DS owner tiene preocupaciones estructurales y necesita una conversación real, no otra revisión. Que la etapa 3 se extienda suele significar que la API es incorrecta y está parcheando alrededor del problema. La etapa 4 no se extiende. Si la omite, está omitiendo la parte que lo hace real.

Convenciones de nomenclatura que perduran

La nomenclatura es la mitad aburrida de la contribución y es donde la mayoría de las contribuciones fracasan en silencio. Un componente llamado BotónGrandeAzul será usado por exactamente un equipo, irónicamente, y nunca más. Un componente llamado Button/Primary/Large se adopta porque el nombre le dice qué es, dónde está y cómo se relaciona con el resto.

La jerarquía de nomenclatura que se sostiene con el tiempo es token, componente, variante, estado. Así:

• Token: color/primary/600
• Componente: Button
• Variante: Primary, Secondary, Ghost
• Tamaño: Small, Medium, Large
• Estado: Default, Hover, Disabled, Loading

De arriba abajo: Button/Primary/Large/Hover es inequívoco, ordenable y coincide con la forma en que debe aparecer en el panel de componentes de Figma y en la navegación de Storybook.

Tres reglas que conviene incorporar como hábito:

1. Sin nombres propios. Sin BotonDeBob, sin ModalT3, sin HeroMarketing. El nombre describe la cosa, no quien la solicitó.
2. Sin abreviaturas de menos de 5 caracteres. Btn no ahorra nada y reduce la búsqueda. Notif es peor que Notification.
3. Sin adjetivos de tamaño que no estén en la escala. "Grande" no es un tamaño. Large sí lo es. Si su escala es S/M/L, no introduzca XLG sin agregarlo primero al sistema de escala en toda la biblioteca.

Cuando los nombres colisionan (y lo harán, especialmente en sistemas más grandes), la regla es: el nombre más general pertenece al caso de uso más general. Si marketing quiere Card para una tarjeta hero estilizada y el sistema ya tiene Card para el contenedor de contenido genérico, el componente de marketing se convierte en Card/Hero o HeroCard. El nombre base se queda con el comportamiento base.

Mínimos de accesibilidad: WCAG AA como piso

Los componentes se publican con la prueba de accesibilidad o no se publican. No es un objetivo secundario. WCAG AA es el piso, no el techo, y es el piso porque por debajo de él está publicando componentes que excluyen a los usuarios legal y éticamente.

Los mínimos que todo componente debe superar antes de fusionarse:

Todos estos tienen herramientas automatizadas ahora. axe-core en CI detecta los estructurales. El complemento a11y de Storybook detecta los fallos obvios de contraste y ARIA. Lo que no detectará (y lo que un IC tiene que hacer de verdad) es la prueba de trampa de teclado: navegue con Tab por cada estado, incluyendo modal abierto, lista desplegable expandida y estado de error. Las trampas de teclado son el modo de falla que veo con más frecuencia y son las más fáciles de probar.

Si no está seguro de si su componente supera la prueba, ejecútela antes de enviarlo a revisión. Un DS owner que tiene que señalar un fallo de contraste en la etapa 2 acaba de descubrir que usted no hizo el trabajo. Una contribución que llega con la accesibilidad lista es una contribución que se aprueba rápido.

Higiene de la biblioteca en Figma

Figma es donde las contribuciones se deterioran silenciosamente si no presta atención. Las dos cosas que importan:

Publicados vs. locales. Los componentes publicados viven en la biblioteca del equipo y se propagan a todos los archivos que la usan. Los componentes locales viven en el archivo en el que trabaja y no se propagan a ningún lugar. El error es usar un componente local para trabajo de prototipo y luego olvidar eliminarlo o promoverlo. Seis meses después el archivo se abre y alguien copia el local porque tiene la forma correcta.

Regla: un componente local o se promueve a la biblioteca publicada en dos semanas, o se elimina. No existe un tercer estado.

Las instancias desvinculadas son una señal de alerta. Cuando un diseñador desvincula una instancia, está diciendo: "Necesitaba este componente pero ligeramente diferente y no quería lidiar con el sistema." Esa es una señal. A veces la respuesta correcta es agregar una variante. A veces es corregir el componente subyacente. A veces el diseñador simplemente tenía prisa. Pero cada instancia desvinculada es un dato, y la revisión mensual debería hacerles seguimiento.

La revisión en sí es mecánica: una vez al mes, ejecute la auditoría de instancias de Figma (o un plugin como Instance Finder), liste las instancias desvinculadas y recórrelas con el diseñador responsable. O se vuelven a vincular, se propone una variante o se eliminan. Treinta minutos de trabajo que previenen tres meses de fragmentación.

Paridad código-diseño (Storybook)

Todo componente de Figma tiene una story en Storybook o no es real. Esta es la regla que pondría en la pared.

Storybook es el único lugar donde el diseño y el código coexisten como el mismo artefacto. Figma le muestra cómo debería verse el componente. Storybook le muestra cómo es en realidad. Cuando divergen (y siempre divergen), Storybook es la fuente de verdad, porque es lo que ve el usuario.

Una story real de Storybook para un componente contribuido tiene:

• Todas las variantes renderizadas (Primary, Secondary, Ghost, etc.)
• Todos los estados renderizados (Default, Hover, Focus, Disabled, Loading, Error)
• Un panel de controles que permite a quien revisa alternar props en vivo
• Una función play que ejercita la interacción por teclado
• Un informe del complemento a11y sin infracciones
• Líneas de base de regresión visual confirmadas (Chromatic, Percy o una solución propia)

La regresión visual en CI detecta la divergencia antes que el PM. Cuando alguien actualiza el componente Button y un token de padding cambia dos píxeles en cuarenta stories, la diferencia aparece en el PR. El DS owner aprueba o rechaza. Sin roturas sorpresa en producción.

Sin ello, se entera de la divergencia cuando un cliente envía una captura de un formulario mal alineado en Twitter.

Ciclo de obsolescencia

Lo que publica dejará de ser la respuesta correcta con el tiempo. Una disciplina de obsolescencia es la forma de evitar el problema del sistema-museo.

El ciclo que aplicaría:

• Revisión trimestral. Cada trimestre, el equipo de DS más 2 o 3 diseñadores IC recorren la biblioteca y marcan los componentes que tienen: poco uso (menos de 5 instancias en todo el código), que están superados por una variante más reciente, o que ya no cumplen los estándares de accesibilidad o visuales.
• Ventana de obsolescencia de dos versiones. Una vez que se marca un componente, etiquételo como @deprecated en Storybook, agregue un banner de obsolescencia en Figma y publique un reemplazo (o una ruta de migración). Dé dos ciclos de versiones (típicamente dos meses) antes de eliminarlo.
• Proporcione el codemod. Esta es la parte que los equipos omiten. Si está marcando como obsoleto un componente usado en 200 lugares, "por favor migre" no es un plan. Publique el codemod (un pequeño script que reescribe automáticamente <BotónViejo> a <Button variant="primary">) para que la migración tome minutos, no semanas. Sin el codemod, la obsolescencia se ignora y el componente antiguo vive para siempre.

Errores comunes

Las cuatro formas en que las contribuciones fracasan, en orden aproximado de frecuencia:

1. Diseñar de forma aislada y luego presentar el resultado terminado. Pasó tres días en Figma. El DS owner tiene treinta segundos de contexto y ahora usted quiere que apruebe seis mockups. No lo hará. Lleve bocetos pronto, trabajo terminado tarde.
2. Copiar y pegar el componente más cercano y "solo ajustarlo". La trampa del "casi funciona". O comprométase con una variante real o construya algo nuevo. Nunca publique un componente desvinculado y ajustado como si fuera un componente del sistema.
3. Omitir la story de Storybook porque "el desarrollador la hará". No lo hará, o lo hará mal porque no conoce la intención del diseño. La story es su especificación, igual que el componente de Figma. Si usted no la escribe, la interpretación del desarrollador se convierte en la verdad.
4. Tratar al DS owner como un obstáculo en lugar de un co-autor. Este es el mayor error de mentalidad. El DS owner tiene más contexto que usted sobre lo que viene, lo que está obsoleto, lo que los equipos necesitarán pronto. Involúcrelo pronto y acelerará su contribución. Ocúltese de él y la ralentizará porque tiene que reconstruir su razonamiento desde cero.

Plantillas y herramientas

Tres artefactos que conviene tener a mano:

Plantilla de RFC de una página. Problema (máximo 3 oraciones), solución propuesta (1 boceto y 3 puntos), alternativas consideradas (2 o 3, con el porqué del rechazo), notas de accesibilidad, dependencias, a quién afecta. Si no cabe en una página, la contribución no está suficientemente delimitada.

Checklist del componente. Tokens usados, variantes definidas, todos los estados diseñados, prueba de accesibilidad superada, story de Storybook publicada con controles y función play, documentación de uso escrita, línea de base de regresión visual confirmada, aviso de obsolescencia si reemplaza algo. Péguelo junto a su monitor.

Plantilla de aviso de obsolescencia. Qué se está marcando como obsoleto, qué lo reemplaza, enlace a la guía de migración, comando del codemod, fecha de eliminación. Publicado en el canal del DS, agregado a la página de Storybook, banner en el componente de Figma.

Cómo medir el éxito

Sabrá que el modelo está funcionando cuando:

• Su contribución llega a la biblioteca publicada en dos semanas desde el RFC. Si tarda más, algo en el flujo está roto.
• Cero instancias desvinculadas de su componente después de treinta días. Si aparecen, la API no cubre los casos de uso.
• La story de Storybook existe, tiene funciones play y tiene cero infracciones de accesibilidad.
• Otro equipo adopta el componente sin preguntarle. Esta es la señal real: cuando la reutilización ocurre de forma orgánica, ha contribuido verdaderamente al sistema, no solo añadido.

El IC que publica trabajo limpio en el DS acumula influencia más rápido que quien construye bibliotecas de componentes privadas, porque cada contribución limpia hace que la siguiente sea más rápida, para usted y para todos los demás.

Más información

• Descripción de puesto: Product Designer
• Crítica de diseño que realmente mejora el trabajo
• Entrega a ingeniería sin el ciclo de ajuste de píxeles
• Accesibilidad más allá del checklist