El design system muere tras el lanzamiento, no antes

Un design system casi nunca falla en el lanzamiento. Falla meses después, cuando un equipo entrega una pantalla con un color suelto y nadie anota el motivo. Lo que sostiene al sistema después de eso es proceso de mantenimiento, no la biblioteca de componentes. Versionado, deprecación y camino de contribución deciden si sobrevive.

El lanzamiento es la parte fácil

El día del lanzamiento es un esfuerzo coordinado, con fecha límite y responsable visible. La biblioteca sale, la página de documentación abre, y los primeros equipos la adoptan porque ayudaron a construirla.

Los meses siguientes no tienen ninguna de esas condiciones. No hay fecha límite, no hay canal de lanzamiento, y no hay atención compartida.

Carbon, el design system de IBM, modela esto en su página Product Development Lifecycle (en inglés). Divide la contribución en discovery, delivery y launch and scale. La página dice que un activo se vuelve estable en esa última fase, así que la estabilidad es una etapa posterior y no la línea de partida.

Nielsen Norman Group dice lo mismo en el artículo Design Systems 101 (en inglés). El texto llama al design system “not a one-and-done solution” y dice que el sistema sigue evolucionando a medida que los equipos envían comentarios. El artículo también nombra el costo: crear y mantener exige mucho tiempo y un equipo dedicado.

La falla no hace ruido. Nadie borra un design system. La gente deja de importarlo, un archivo por vez.

El mantenimiento es proceso, no biblioteca

Una biblioteca de componentes es un artefacto. No tiene opinión sobre lo que pasa cuando quien la usa necesita algo que ella no ofrece.

NN/g separa las dos partes de un design system: el repositorio y las personas que lo administran. El repositorio guarda la guía de estilo, la biblioteca de componentes y la biblioteca de patrones. La segunda parte es la que se degrada.

El proceso responde lo que la biblioteca no responde. Quién decide cuándo cambia un componente. Cómo llega un cambio que rompe a quien lo usa. Dónde pide un equipo algo nuevo. Qué pasa cuando el pedido se rechaza.

Una biblioteca sin proceso se queda como una foto de otro momento. Sigue instalándose y sigue correcta en la documentación, mientras el producto se aleja de ella.

Qué se vuelve componente y qué queda local

No todo elemento repetido merece un lugar en el sistema. La decisión es sobre reutilización y costo, no sobre prolijidad.

El GOV.UK Design System publica criterios de contribución (en inglés) que responden esto de forma directa. La propuesta tiene que ser útil, es decir, con evidencia de que muchos equipos la necesitan. Y tiene que ser única, sin duplicar lo que ya existe.

Los criterios de publicación suman tres más. La implementación tiene que ser usable en investigación con usuarios, consistente con los estilos y componentes existentes, y versátil para servir a varios servicios.

La versatilidad es el criterio que anticipa el costo de mantenimiento. Un campo de fecha que sirve a un solo servicio va a pedir cambios el día que llegue el segundo.

Lo sensato, por defecto, es lo local. Un elemento usado en dos pantallas de un producto, con un responsable y sin plan de reutilización, sale más barato dentro del producto. La página del ciclo de vida de Carbon (en inglés) marca una frontera parecida por otro motivo: no se hace cargo de aplicaciones completas ni de herramientas de terceros.

Lleva el elemento al sistema cuando lo necesite un segundo equipo, o cuando aparezca la tercera copia. Las dos señales dicen que otra persona ya está pagando la duplicación.

El componente que acepta cualquier cosa

Un componente con una prop para cada valor es una hoja de estilo disfrazada. El envoltorio parece un activo del sistema, y las decisiones de diseño viven en el punto de uso.

El checklist de componentes de Carbon (en inglés) muestra el patrón opuesto. Sus requisitos de spec exigen que el diseño use los tokens de color, de tipografía y de espaciado del sistema, y que los colores queden tokenizados. La página da el motivo: los tokens reducen la carga de mantenimiento y hacen posible el tema. La guía de tokens y tema cubre cómo ese conjunto de tokens se vuelve un tema.

Una prop que acepta color crudo, espaciado crudo u objeto de estilo libre elimina esa garantía. El conjunto de tokens deja de ser la fuente de verdad, porque quien usa el componente puede fijar cualquier valor sin pasar por el sistema.

La revisión es simple. Cuenta las props que aceptan un valor crudo en lugar de una opción con nombre. Cada una es un lugar donde la regla se puede romper sin revisión.

Dos límites mantienen la regla usable. Un componente de layout necesita aceptar ancho y posición, porque el sistema no conoce la página. Y un envoltorio que pasa una clase existe en casi todo sistema real, como válvula de escape.

La diferencia está en registrar la válvula de escape. Una válvula sin registrar se vuelve el camino normal en dos trimestres.

Versionado y deprecación

El versionado es una promesa sobre el contrato, no sobre el código. El número que importa es el que lee quien usa el componente antes de actualizar.

El versionado semántico da la forma. Un patch no cambia nada observable, un minor agrega, y un major rompe. La parte difícil es acordar qué cuenta como ruptura. Una prop renombrada, un valor por defecto distinto y un estado visual eliminado rompen a quien usa el componente aunque el marcado sea idéntico.

La deprecación es la parte que casi todos los sistemas saltean. Necesita cuatro campos escritos en el momento de la decisión: qué queda obsoleto, qué lo reemplaza, quién es dueño de la migración, y la fecha en que sale el camino viejo.

El GOV.UK Design System fija una expectativa parecida para los recursos que enlaza (en inglés). Un recurso de la comunidad tiene que responder tickets en un mes y quedar como máximo tres meses atrás de la última versión de GOV.UK Frontend. Son términos de mantenimiento, publicados de antemano.

La ventana importa más que la fecha. Una deprecación sin fecha de remoción acumula caminos paralelos, y cada camino duplica la superficie que el sistema tiene que probar.

Carbon resuelve el mismo problema con estados en lugar de fechas. El checklist (en inglés) asigna a cada activo un estado, de Draft y Preview candidate a Preview y Stable, y ata esos estados a las fases del ciclo de vida. Solo el equipo de Carbon mueve un activo de discovery a delivery, y la página avisa que no toda propuesta avanza.

Material Components for the web, la implementación de Material de Google, pone la puerta antes. Los requisitos de un componente nuevo están en una guía de contribución (en inglés) que cualquiera lee antes de proponerlo. Un componente que no se puede probar no se puede mantener por otra persona.

El camino de contribución

El camino de contribución es la ruta desde “necesitamos esto” hasta “el sistema tiene esto”. Si la ruta no está clara, los equipos construyen por su cuenta y el sistema pierde autoridad sobre el producto.

USWDS, el design system del gobierno de Estados Unidos, publica la ruta completa (en inglés). Cualquier persona puede sugerir un componente, empezando por una discusión en GitHub. Si la discusión junta apoyo, el equipo central la convierte en propuesta formal, y la propuesta recibe 45 días de comentario público antes de la decisión.

Los 45 días son el detalle interesante. Una ventana pública larga cuesta velocidad y compra legitimidad, porque un componente que entra al sistema con desacuerdo adjunto entra con objeciones conocidas (USWDS (en inglés)).

USWDS también maneja solicitudes de funciones y reportes de errores en listas públicas, donde los votos y los comentarios fijan la prioridad. Eso le da al equipo una segunda opción además de construir por su cuenta: sumar peso a una solicitud existente.

Tres propiedades hacen funcionar el camino. Está escrito. Tiene un responsable que responde. Y tiene respuesta de rechazo, para que el equipo sepa por qué se rechazó la solicitud en lugar de adivinar.

Registra la excepción, no la prohíbas

Toda regla de un design system se va a romper en algún momento. Lo que importa es si se puede ver cuando pasa.

Una excepción registrada carga cinco campos: la regla que rompe, el motivo, el responsable, la fecha y la condición que la cierra. El último campo convierte la excepción en decisión en lugar de costumbre.

Una excepción sin registrar es invisible de la peor manera. Parece un archivo normal del producto, y parece un componente normal en la revisión.

Un archivo corto en el repositorio alcanza. Una línea por excepción, revisada al mismo ritmo que el código, con un conteo que cualquiera puede leer.

Lo útil está en el conteo. Un sistema con cuatro excepciones abiertas es un sistema con cuatro huecos conocidos. Un sistema con cuarenta es un sistema cuyas reglas ya no describen el producto.

Qué medir después del lanzamiento

Tres números muestran si el sistema se sostiene, y ninguno es el tamaño de la biblioteca.

Adopción por equipo: la porción de pantallas construidas con componentes del sistema en lugar de copias locales, medida por importaciones o por conteo de implementaciones duplicadas.
Excepciones abiertas: cuántas están registradas, qué antigüedad tienen, y cuántas pasaron su condición de cierre sin cerrarse.
Tiempo para entregar una pantalla nueva: el intervalo entre la spec de diseño y la pantalla publicada, medido también para quien contribuye por primera vez.

Dos más ayudan del lado del mantenimiento. Tiempo para cerrar un error reportado por otro equipo, y la porción de deprecaciones terminadas en la fecha publicada.

Mide el primer número por equipo, no en el agregado. Un adoptante fuerte carga el promedio mientras tres equipos construyen por fuera.

Cuándo no vale la pena

Un design system es una apuesta a la reutilización en el tiempo. Cuando la reutilización no existe, el costo de mantenimiento no tiene qué pagar.

NN/g enumera las condiciones que hacen fallar la apuesta. El trabajo exige mucho tiempo y un equipo dedicado. Enseñar a usar el sistema lleva tiempo. Y los proyectos pueden percibirse como creaciones sueltas que no necesitan componentes compartidos.

Eso apunta a tres casos reales en contra de construirlo. Un producto único con un solo equipo que ya comparte canal y costumbre de revisión. Un equipo demasiado chico para que alguien sea responsable del mantenimiento. Un producto con ciclo de vida más corto que el tiempo de retorno del sistema en su primer año.

En esos casos, una hoja de estilo compartida, una escala tipográfica documentada y una costumbre de revisión cubren casi todo el valor por una fracción del costo.

Mientras el producto esté en uno de esos casos, mantener un sistema cuesta más de lo que devuelve. Las señales de que llegó el momento están en el post sobre construir un design system propio o adoptar una biblioteca.

Dónde divergen los artículos de NN/g

Tres artículos de la misma organización no coinciden sobre quién lleva el design system.

Para Design Systems 101 (en inglés), un sistema pide gente dedicada a él, y eso entra en la cuenta. Equipos reducidos de design system (en inglés) muestra que la mayoría de los equipos tiene entre dos y cinco personas, muchas veces dividiendo el trabajo de sistema con el de producto. El artículo trata el tamaño chico como una elección deliberada. Los dos textos divergen sobre el equipo dedicado.

También divergen sobre qué cuenta como avance. El artículo 101 ancla el valor del sistema en la escala: decenas de equipos y miles de pantallas. Madurez de design system (en inglés) dice que la madurez no es lineal, que la adopción nunca termina y que los sistemas retroceden. Un equipo de diez personas y una empresa de diez mil pueden tener sistemas maduros. Los dos textos divergen sobre la escala como regla.

Coinciden en muy poco. El sistema necesita responsables, y sigue cambiando después del lanzamiento.

Verifica antes de llamarlo mantenido

Confirma que cada componente tiene un responsable nombrado en el repositorio.
Confirma que el camino de contribución está publicado, con un plazo de respuesta declarado.
Confirma que cada activo obsoleto tiene reemplazo, responsable y fecha de remoción.
Confirma que el conjunto de tokens es el único camino a un color, un tamaño de texto y un espaciado.
Confirma que el registro de excepciones es legible, actual y contado con periodicidad.
Confirma que la adopción se reporta por equipo, no como un promedio único.
Para cada una de las tres métricas, nombra quién la lee y qué hace esa persona cuando empeora.

El design system que sobrevive al lanzamiento rara vez es el de mayor biblioteca. Es el que tiene una ruta documentada para la próxima solicitud, un plan con fecha para la próxima remoción, y un registro que muestra dónde ya se rompieron las reglas.