Design system propio o biblioteca: quién paga mantenerlo

Un design system que construyes y una biblioteca de componentes que adoptas resuelven el mismo problema. La diferencia está en quién paga el mantenimiento y en quién decide cuándo algo cambia. Adoptar alquila esa decisión a un proveedor. Construir la compra y paga después. Elige preguntando qué cuenta puede cargar tu equipo en el tercer año.

Qué cambia entre construir y adoptar

Adoptar una biblioteca es comprar decisiones ya tomadas. Espaciado, estado de foco, navegación por teclado y el trabajo de accesibilidad detrás de un select llegan listos. El costo es una dependencia. La biblioteca decide qué hace el componente, y tú decides cómo se ve.

Construir le da la vuelta a esa cuenta. Eres dueño del comportamiento, de los tokens y de la cadencia de release. También eres dueño del bug en el dropdown, de la migración de un prop renombrado y de la revisión que impide que un hex crudo entre en un botón. La guía de tokens y tema cubre qué significa ser dueño de esa capa en la práctica.

El trabajo que desaparece cuando adoptas es el trabajo que queda invisible cuando construyes. El trabajo que aparece cuando adoptas queda invisible hasta que el proveedor cambia de rumbo.

Quién paga el mantenimiento en cada camino

La adopción reparte el mantenimiento entre todos los equipos que usan la biblioteca. Un parche de seguridad, una diferencia de navegador o un patrón nuevo de ARIA entra una vez y todos lo heredan. El problema es que nadie dentro de tu empresa responde por el calendario.

El Material Components for the web (en inglés), de Google, muestra cómo se ve ese calendario desde afuera. Su README dice que el proyecto ya no se mantiene activamente y que las actualizaciones se apagarán en el futuro. El mismo README dice que la biblioteca publica cambios que rompen compatibilidad casi cada mes, siguiendo semver, con una cadencia de dos semanas y un major por mes. Un equipo que lo adoptó temprano no pagó nada durante años y hoy tiene una migración sin origen.

Construir concentra el mantenimiento en un equipo. Ese equipo responde las preguntas, entrega las correcciones y asume la guardia de los componentes. Nielsen Norman Group nombra el costo directo en Design Systems 101 (en inglés). Crear y mantener un design system exige tiempo y un equipo dedicado. El artículo agrega que un design system no es una solución de una sola vez, porque evoluciona según los comentarios de los equipos.

Ningún camino elimina el trabajo. La adopción convierte un costo interno fijo en un costo externo variable.

Quién controla la decisión de cambio

Esto es lo que decide la mayoría de los casos, y no tiene que ver con el costo.

Con una biblioteca adoptada, la decisión de cambio pertenece a personas que no conocen tu producto. Leen su propio roadmap, su propio lenguaje visual y su propia matriz de navegadores. Tu solicitud se vuelve un issue en un backlog público.

El patrón aparece en el versionado. Radix Primitives publica un changelog con fecha por componente (en inglés), y sus notas marcan entradas como cambios incompatibles cuando el cambio exige acción de quien llama. Una entrada temprana marca Accordion como major porque la API renombró Accordion.Button a Accordion.Trigger y Accordion.Panel a Accordion.Content. Nadie que usaba ese componente eligió esa fecha.

Con un sistema que construyes, la decisión pertenece a un equipo dentro de la empresa. Ese equipo avanza más rápido en tu requisito y más lento en todo lo demás, porque las mismas personas que deciden también implementan.

El control vale el precio solo cuando tu requisito difiere de lo habitual. Si tu producto necesita lo que necesita todo el mundo, la decisión del proveedor suele ser mejor que la tuya.

Cuánto cuesta la excepción

Todo design system se sobrescribe en algún punto. La pregunta es el precio de la sobrescritura y quién lo paga.

En una biblioteca adoptada, la excepción es local y barata al principio. Un componente wrapper, un CSS de sobrescritura, un selector con mayor especificidad. El costo aparece después, cuando la biblioteca cambia el markup y la sobrescritura se rompe de un modo que ningún test cubre.

En un sistema que construyes, la excepción es cara al principio y barata después. Alguien tiene que decidir, nombrar la variante nueva y entregarla a todos los que llaman. Después de eso, la excepción es parte documentada del sistema, y el próximo equipo la hereda.

Esa diferencia pesa. Una biblioteca adoptada deja la primera excepción gratis y la número cien cara. Un sistema construido deja la primera excepción cara y la número cien barata.

Cuando el requisito no cabe en el componente ajeno

Este es el momento en que la decisión se pone a prueba, y llega en una fecha que nadie controla.

Hay cuatro formas comunes en que el requisito no cabe. El componente no tiene un estado que tu producto necesita. El lenguaje visual diverge del lenguaje del proveedor. El comportamiento choca con una regla o una convención de plataforma de tu mercado. O el componente sirve, y la versión que necesitas quedó descontinuada antes de tu lanzamiento.

El Material Components for the web (en inglés) es el caso limpio de la última hipótesis. Un equipo que construyó sobre él en 2019 tiene código funcionando y ningún camino hacia adelante, salvo hacer un fork. El fork significa que el mantenimiento externalizado vuelve, con intereses, a un equipo que ya no tiene el contexto original.

Radix (en inglés) toma la posición opuesta para el mismo problema. Sus primitivas entregan comportamiento y dejan el estilo a quien llama, así que una divergencia de diseño no es un fork. Es el uso previsto.

El error que conviene evitar no es ninguno de los dos caminos. Es adoptar una biblioteca estilizada por el comportamiento y pelear con sus estilos durante dos años en vez de hacer fork o cambiar.

El camino del medio: biblioteca headless con capa de estilo propia

Construir o adoptar no agota la elección. Hay un camino intermedio, que carga el comportamiento de una biblioteca adoptada y las decisiones de un sistema construido.

Una biblioteca headless entrega la parte difícil. Gestión de foco, navegación por teclado, cableado de ARIA, posicionamiento y portal llegan probados. Tú te quedas con los tokens, con la capa visual de los componentes y con el lenguaje de diseño. Radix Primitives mantiene un historial público de versión por componente (en inglés) para el comportamiento que sí controla.

La división refleja quién es bueno en qué. Acertar en accesibilidad y en los detalles de interacción cuesta caro, y ese trabajo se comparte ampliamente. El lenguaje visual es propio de un producto y barato de cambiar cuando los tokens son tuyos.

Esto tiene un costo. Ahora mantienes una capa de estilo entre las primitivas y las pantallas. Esa capa necesita dueños, tests y política de descontinuación, igual que un sistema construido. El ahorro es no ser dueño nunca de la trampa de foco.

Headless es el punto de partida correcto para un producto con identidad visual propia y un equipo de plataforma chico. Es la elección equivocada para un equipo sin capacidad de mantener una capa, y para un producto contento con el lenguaje del proveedor.

Cuando la biblioteca lista es la elección correcta

La adopción gana más veces de las que admite quien defiende un design system.

Adopta cuando el producto tiene un equipo, un ciclo de vida corto, o un lenguaje visual que ya coincide con una biblioteca madura. Adopta cuando el equipo no puede nombrar un dueño del mantenimiento en los próximos doce meses. Adopta cuando la superficie de plataforma es chica y el trabajo de accesibilidad es el riesgo principal.

El caso más fuerte de adopción es un producto que necesita lo que necesita todo el mundo. Un panel, una herramienta interna y un checkout resuelven problemas que miles de equipos ya resolvieron, y el proveedor absorbió ese costo.

Cuando el sistema propio es un desperdicio

Un design system es una apuesta al reúso. Cuando el reúso no existe, el mantenimiento no tiene qué pagar.

Construir es desperdicio cuando el producto entrega una sola interfaz y no tiene segundo consumidor. Es desperdicio cuando el mismo equipo cuidaría el sistema y el producto, porque el sistema pasa a competir con el roadmap. Es desperdicio cuando el lenguaje visual todavía cambia cada trimestre, porque los tokens se van a reescribir antes de reusarse.

NN/g lista las mismas condiciones desde el otro lado. Un design system necesita equipo dedicado, necesita tiempo para enseñar y enfrenta la percepción de que los proyectos son creaciones aisladas.

Dónde las fuentes discrepan

Los tres artículos de NN/g no describen el mismo sistema, y vale nombrar la diferencia antes de presupuestar uno.

Design Systems 101 (en inglés) trata el equipo dedicado como requisito previo y como costo de entrada. El artículo de equipos reducidos de design system (en inglés) reporta la forma opuesta en la práctica. Los equipos de dos a cinco personas son la norma, y ese tamaño reducido es lo que los hace eficaces, no una concesión. El artículo de madurez de design system (en inglés) agrega la parte que el plan suele olvidar. La madurez no es lineal, y los sistemas retroceden después de lanzarse.

Los tres coinciden en dos puntos, y son los que quedan. El sistema necesita un dueño nombrado, y sigue cambiando después del lanzamiento. El artículo de consistencia y patrones (en inglés) explica por qué el dueño tiene trabajo. La consistencia es una propiedad que alguien mantiene, no un estado al que el sistema llega.

Dimensiona el equipo por tu propia evidencia, no por el requisito previo. Si dos a cinco personas pueden con él, el caso de construir mejora, no empeora.

La señal para empezar a construir es específica. Aparece un segundo equipo, o el mismo patrón de pantalla se reconstruye por tercera vez. Los dos casos significan que alguien ya paga la duplicación.

Cómo decidir, y qué medir

Decide con tres preguntas, respondidas antes de escribir código.

Quién responde cuando el componente necesita un cambio, y cuánto tarda eso hoy.
Cuánto cuesta una excepción en horas, en cada opción, y quién la aprueba.
Qué pasa con este producto en tres años si la biblioteca deja de publicar o el requisito se mueve.

Después de la decisión, sigue esos tres números, y no el tamaño de la biblioteca de componentes.

Tiempo desde la solicitud hasta el componente cambiado, contado desde el primer mensaje hasta el release publicado.
Cantidad de sobrescrituras locales contra componentes del sistema, contada por equipo y revisada con una cadencia.
Costo de upgrade por versión major, en horas, incluidas las partes que se rompieron en silencio.

Dos más ayudan del lado del mantenimiento. La porción de componentes con dueño nombrado en el repositorio, y la edad de la solicitud más antigua sin respuesta.

Mide por equipo, nunca como promedio. Un adoptante fuerte puede cargar un número que esconde a tres equipos construyendo fuera del sistema.

Revisa antes de firmar la decisión

Confirma que la decisión de cambio tiene dueño nombrado, en los dos caminos.
Confirma que el costo de salida está escrito antes de la adopción, incluido el escenario de fork.
Confirma que cada excepción tiene motivo registrado y condición de cierre.
Confirma que la capa de estilo tiene política de descontinuación si elegiste headless.
Confirma que las tres métricas tienen un lector que actúa sobre ellas.

Construir o adoptar importa menos que tres cosas: un dueño nombrado para la decisión de cambio, un costo medido para la excepción y un plan para el año en que la biblioteca o el producto se mueve.