Por qué matamos componentes en vez de añadirlos: la dieta del design system

Con un design system, la jugada por defecto es añadir. Una pantalla nueva pide una card un poco distinta, alguien forkea Card en CardCompact, la librería crece y un año después nadie sabe nombrar la mitad de los componentes que tiene. Cuanto más grande es la librería, más lentas son las design reviews y más a menudo dos diseñadores resuelven el mismo problema en dos archivos distintos.

Nosotros invertimos el default. Matamos componentes más a menudo de los que añadimos, y tratamos el tamaño de la librería como un número que mantener bajo, no alto. Aquí están las reglas que seguimos, por qué existe cada una, y dónde fallan.

El principio del corte

Un design system sirve para quitar decisiones del trabajo de producto, no para alojar todas las variantes que hayan existido. El design system de Atlassian enfoca la idea igual y empuja a los equipos hacia la composición: en vez de un componente ancho con dieciocho props, dos componentes pequeños que encajan. Adobe siguió el mismo camino cuando rediseñó Spectrum 2 alrededor de primitivas más estrechas.

De ahí sale la regla: cada componente cuesta. Documentación que envejece. Ruido en las analytics de Figma. Horas de ingeniería cuando cambia el tema y hay que migrar 200 instancias. Diseñadores nuevos leyendo tres casi-duplicados y escogiendo el equivocado. El beneficio (el reúso) solo aparece cuando el componente se comparte de verdad. Por debajo del umbral de reúso, lo único que tienes es el coste.

El test de entrada (antes de añadir nada)

Usamos dos preguntas antes de promover algo a la librería, sacadas del patrón que Josh Cusick describe en Design systems should do less:

1. ¿Se usa ya el patrón en tres o más sitios del producto?
2. ¿Es lo bastante genérico para que aparezca un cuarto caso de uso en dos trimestres?

Dos síes: el componente entra. Un sí: queda como patrón local en la app que lo consume. Dos noes: anota un snippet en Notion y sigue.

Es más duro de lo que suena. La mayoría de los "lo necesitamos en el sistema" llegan con un sí, a veces cero. Decir no temprano es el momento más barato en la vida de un componente. Una vez enviado, cada eliminación es una migración.

La kill list (señales para deprecar)

Una vez al trimestre recorremos la librería con la kill list delante. Un componente es candidato a depreciación si se cumple cualquiera de estas condiciones:

• Menos de 5 instancias en todos los archivos de producto tras seis meses. Figma Library Analytics lo muestra directamente en Inserts e Instances; la release de febrero de 2025 añadió la misma vista para estilos y variables, así que la regla vale también para tokens.
• Más del 30% de las instancias está desligado. El detach es la señal de que el componente no encaja con el caso de uso real y los diseñadores le dan la vuelta. La tasa de detach es lo más parecido a un score de satisfacción que un design system tiene.
• Existe un casi-duplicado. ButtonPrimary, PrimaryButton, BtnCTA. Dos componentes que comparten más de la mitad de las props son una señal fuerte de que uno tiene que morir.
• Sin owner documentado. Lo que en la librería nadie quiere firmar se mantiene mal solo. El campo owner en la spec es un kill switch. Si queda en blanco dos trimestres, el componente entra en la lista.
• El patrón se expresa componiendo dos componentes más pequeños. Card + Heading + Action es un layout, no un componente. CardWithActionButton es un componente que se forkea en cinco variantes en un año.

Candidato no es borrado. Es deprecado, y arranca un reloj.

Cómo deprecar sin romper a los consumidores

Quitar un componente de golpe es como los design systems se vuelven odiados. La cadencia que usamos, modelada sobre la ventana de depreciación de Adobe Spectrum y el patrón de rename en Figma que documenta Craig Francies:

1. Renombra el componente. En Figma, Button pasa a Button [deprecated]. Figma propaga el nuevo nombre a cada archivo consumidor en cuanto se abre, así los diseñadores ven la etiqueta sin que nadie mande un correo. Misma regla en código: renombra el export, deja un re-export del path antiguo que loguee un warning en consola en development.
2. Publica el camino de migración. Cada componente deprecado lleva un párrafo de "usa esto en su lugar" en la spec, con un diff de código. Si no hay sustituto, la depreciación está mal planteada y vas a romper consumidores.
3. Fija una fecha de retirada. A una major version vista. Atlassian y Spectrum funcionan así. La fecha vive en la spec, no en la cabeza de alguien.
4. Sigue el conteo de instancias cada semana. El número tiene que bajar. Si no baja, el mensaje de depreciación no llega y hace falta documentación de migración más afilada, no una retirada forzada.
5. Retira en la fecha, no antes. Si los equipos no han migrado, la retirada es una palanca de forzado. Si mueves la fecha, enseñas a los equipos que las depreciaciones son opcionales.

La parte difícil es el paso 4. La mayoría de los equipos de design system lo saltan, llegan a la fecha, descubren que la mitad del producto sigue consumiendo el componente deprecado, y o lo posponen (lección: las depreciaciones son opcionales) o lo retiran (lección: el design system rompe cosas). El seguimiento semanal con owners nombrados es lo que cierra el bucle. El mismo patrón aparece en nuestro enfoque de governance entre proyectos consumidores: primero los conteos de instancias, luego las opiniones.

Composición sobre componente

Una fracción sorprendente de los "necesitamos un componente nuevo" se cae cuando intentas expresar el patrón como composición. Una card con una fila de iconos, un heading, un body y dos CTAs no es una variante nueva de card. Es <Card><IconRow/><Heading/><Body/><ActionBar/></Card>. Cinco primitivas, cada una hace una cosa.

La guía de composición de Atlassian y el patrón compound component de React vuelven esto concreto. El coste es la discoverability de la API: un diseñador nuevo frente a cinco primitivas tiene que saber que encajan. El beneficio es que el sistema tiene 5 componentes haciendo el trabajo de 50, sin desfase de versión entre consumidores.

La regla de decisión: un componente nuevo se gana el sitio en la librería solo si no se puede expresar como composición de primitivas existentes con código razonable. Razonable son unas 5-8 líneas de JSX. Pasado eso, gana la abstracción.

La dieta trimestral

La cadencia importa más que las reglas. Una vez cada tres meses, dos personas del equipo de design system recorren la librería con la kill list. Marcan candidatos. La marca es pública. Los consumidores tienen una semana para oponerse. Pasada la semana, los componentes marcados entran en el ciclo de depreciación anterior.

Qué medimos a lo largo del ciclo: conteo total de componentes, conteo de los deprecados todavía presentes, número medio de instancias por componente no deprecado, y la tasa de cierre de depreciaciones (cuántas veces aguanta la fecha de retirada). El primer número debe bajar o quedarse plano año a año. El cuarto debe estar por encima del 80%. Una auditoría de design system bien hecha sigue los cuatro y saca el drift antes de que arranque la conversación del rewrite.

Una librería que crece de forma monótona es una librería en camino a un rewrite. Los equipos que evitan el rewrite son los que tratan la poda como parte del trabajo habitual.

Dónde la dieta falla

Tres casos resisten la regla.

Superficie de producto nueva. Cuando el producto tiene seis meses y el equipo está encontrando la forma de la UI, deprecar de forma agresiva genera más rework del que ahorra. Mantén la kill list quieta el primer año y deja que los patrones se asienten.

Componentes de sector con peso regulatorio. Un componente de dashboard para dispositivos médicos que codifica restricciones WCAG y FDA no es candidato a depreciación solo porque baje el conteo de instancias. El coste de equivocarse en otro sitio pesa más que la manutención dentro.

Handoff a un equipo interno. Si el design system lo construyó un estudio externo y se devuelve a un equipo interno, congela la kill list durante el traspaso. Podar un sistema que el equipo receptor todavía no entiende le enseña a tenerle miedo.

Para todo lo demás (design systems en producción con varias apps consumidoras, más de 50 componentes en librería, más de un diseñador tocando el sistema a la semana) la dieta es la diferencia entre un sistema que capitaliza valor y uno que capitaliza el tipo de deuda del que escribimos en 10 errores de design system que rompen la consistencia a escala.