Los sistemas de diseño no fallan por diseño. Fallan por gobernanza.

En la edición 2026 del Design Systems Report de zeroheight, con 147 practicantes encuestados, apenas 7% declaró que su sistema de diseño está completamente adoptado por todos los equipos. Otro 38% dijo que está moderadamente adoptado por algunos equipos y 22% que está mínimamente adoptado por unos pocos.

Ese es el estado del arte después de una década de inversión. Siete por ciento.

Cuando un problema persiste con recursos crecientes y tecnología resuelta, el problema no es técnico.

Y no es por falta de herramientas: 97% de los equipos usa Figma para los assets de diseño, 90% define sus tokens en la herramienta de diseño y 82% ya los tiene escritos en código. Tampoco es por falta de estructura: 83% de las organizaciones tiene un equipo dedicado al sistema, contra 78% el año anterior.

Herramientas hay. Equipos hay. Adopción no hay. Cuando un problema persiste con recursos crecientes y tecnología resuelta, el problema no es técnico.

El dato que ordena todo: casi nadie mide el retorno.

En el mismo reporte, 41% de los equipos mide tasas de adopción y 38% rastrea el uso de componentes en el código. Solo 5% mide el ROI.

Cinco por ciento.

Detenete en la implicancia. Un equipo de entre tres y cinco personas —el tamaño más frecuente en la muestra— trabaja a tiempo completo en un activo transversal cuyo retorno económico nadie calcula. Cada ciclo presupuestario, ese equipo va a una discusión de asignación de recursos sin la única cifra que la discusión requiere.

El resultado era predecible. En 2026, apenas 32% de los practicantes se declaró satisfecho con el respaldo organizacional que recibe su sistema, contra 42% en 2025. La insatisfacción subió de 23% a 40% en un año. Y 61% de los equipos se siente subdotado de personal.

Ese es el mecanismo completo del fracaso, y no tiene nada que ver con la calidad de los componentes. Un activo que no se mide no se defiende. Un activo que no se defiende se desfinancia. Un activo desfinanciado deja de mantenerse. Un sistema sin mantenimiento se desactualiza respecto al producto. Y un sistema desactualizado deja de usarse, no por rebeldía, sino porque copiar y pegar es más rápido que esperar el componente.

El abandono de un design system casi nunca es una decisión. Es una consecuencia diferida de no haber contestado quién paga.

Los tres modelos de gobernanza son tres respuestas distintas a la misma pregunta.

La literatura de la disciplina insiste en tres modelos y conviene decir qué significan en términos de poder, no de organigrama.

En el modelo centralizado, un equipo dedicado decide, construye y mantiene. Es el más común: 51% de las organizaciones en 2026, 50% en 2025. Su ventaja es la consistencia. Su falla es el cuello de botella: cada producto que necesita algo nuevo entra a una fila que administra un equipo con 61% de probabilidad de estar subdotado.

En el modelo federado, los equipos de producto contribuyen al sistema y comparten la autoría. Es el menos usado: 13% en 2026, 9% en 2025. Su ventaja es la velocidad y el sentido de propiedad. Su falla es que la contribución sin un estándar de revisión produce divergencia, y que 27% de los equipos ya reporta la gestión de contribuciones como un problema principal.

En el modelo híbrido —31% en 2026, 41% en 2025— un núcleo mantiene lo estable y los productos extienden lo periférico. Es el que más se recomienda y también el que más exige: requiere una frontera explícita entre lo que es núcleo y lo que no, y alguien con autoridad para trazarla.

Ninguno de los tres es superior en abstracto. Los tres son formas de contestar tres preguntas concretas: quién puede decir que no, quién arregla el componente roto a las once de la noche, y de qué centro de costo sale el sueldo de esa persona.

La mayoría de los sistemas regionales que conocí no tiene esas tres respuestas escritas en ningún lado. Tienen, eso sí, una biblioteca muy prolija.

Los tokens resolvieron el problema técnico y por eso dejaron desnudo el otro.

Vale la pena mirar qué sí se resolvió, porque es mucho.

Los design tokens fueron el componente de más rápida difusión del ecosistema: hoy nueve de cada diez equipos los definen en la herramienta de diseño y ocho de cada diez los tienen en código. Y el 28 de octubre de 2025 el Design Tokens Community Group anunció la versión estable 2025.10 de la especificación, después de años de trabajo, con soporte para temas y multimarca, espacios de color modernos como Display P3 y Oklch, relaciones de herencia y alias entre tokens, y consistencia entre iOS, Android, web y Flutter. Participaron más de veinte editores y autores de organizaciones como Adobe, Amazon, Google, Microsoft, Meta, Figma, Sketch y Shopify.

Un matiz que se repite mal en LinkedIn y conviene corregir: el Design Tokens Community Group es un community group del W3C, no un estándar formal del W3C. La distinción importa porque cambia quién está obligado a cumplirlo. Nadie. Es un acuerdo voluntario entre implementadores, y funciona porque los implementadores se pusieron de acuerdo, no porque exista una autoridad que lo imponga.

Eso es exactamente lo que le falta a la mayoría de los sistemas de diseño corporativos: un acuerdo voluntario que los equipos consideren propio. La especificación de tokens logró en cuatro años algo que muchos design systems internos no logran en dos: que gente sin obligación jerárquica decida adoptarla porque le conviene.

Con los tokens estabilizados, la excusa técnica se acabó. El formato de intercambio existe, es abierto, tiene herramientas y funciona multiplataforma. Si tu sistema sigue sin adopción, ya no es por el pipeline.

Los casos regionales que funcionan tienen dueño y tienen frontera.

Vale mirar qué hicieron distinto los que escalaron.

El caso mejor documentado de la región es NuDS, el sistema de diseño de Nubank. Según el material publicado por Figma, el sistema soporta a más de 200 diseñadores trabajando sobre tres países y una base de clientes que la compañía reportaba entonces en 118 millones, con más de 100 componentes y plantillas reutilizables. La cifra que importa no es esa: es que reporta alrededor de 80% de adopción en pantallas de producto y 80% de cumplimiento del sistema.

Cómo llegó ahí es la parte instructiva, y no es una historia de diseño. Es una historia de control de acceso. El sistema usa un plugin nativo de cumplimiento que verifica adherencia, y acceso por roles integrado con Okta desde 2024. En otras palabras: la organización decidió que la conformidad con el sistema es una propiedad verificable por software, no una recomendación en un documento. También mantiene patrones localizados por mercado —tarjetas verticales en Brasil, horizontales en México y Colombia— lo que implica que alguien tuvo la autoridad de decidir qué se localiza y qué no.

En el otro extremo del espectro está el caso del sector público. El Padrão Digital de Governo brasileño —el design system de gov.br— es un activo de escala nacional, mantenido con participación del Serpro y publicado bajo el paraguas del gobierno digital federal, con documentación abierta y componentes públicos. Su gobernanza es explícita porque tiene que serlo: un sistema que muchos órganos distintos deben usar no puede depender de la buena voluntad de cada equipo.

Y está el caso que casi nadie estudia: los sistemas cerrados. Voxel, el design system de Itaú Unibanco, figura en los catálogos de la comunidad brasileña como sistema cerrado, sin kit de diseño ni código fuente públicos. No es una crítica. Es una decisión de gobernanza con consecuencias: un sistema cerrado no recibe contribuciones externas, no genera comunidad y no compite por talento con su documentación, pero tampoco tiene que administrar el costo de mantener una superficie pública.

Los tres son coherentes. Cada uno contestó las tres preguntas. Los que fracasan no son los que eligieron mal el modelo: son los que nunca eligieron.

El costo de mantenimiento es el número que nadie pone en el business case.

Un sistema de diseño no es un proyecto con fecha de entrega. Es una obligación perpetua. Cada versión de iOS, cada actualización del framework, cada cambio de marca y cada requisito de accesibilidad genera trabajo que no produce ninguna funcionalidad nueva.

Los datos del reporte 2026 dan una pista del tamaño: 56% de los equipos cita la falta de recursos y personal como su obstáculo principal, 35% la dificultad para priorizar actualizaciones y 31% la falta de respaldo de los stakeholders. Además, apenas 44% de los equipos cuenta con un especialista en accesibilidad y apenas 44% con product manager. Y 60% no tiene ninguna automatización en su pipeline de tokens.

Un equipo sin product manager es un equipo sin priorización. Un equipo sin automatización es un equipo que hace a mano el trabajo repetitivo. Un equipo sin especialista en accesibilidad es un equipo que va a descubrir sus deudas cuando llegue una auditoría.

Sumado: la mayoría de los sistemas de diseño de la industria son mantenidos por equipos pequeños, sin gestión de producto, sin automatización y sin la disciplina que ellos mismos le exigen a los productos que sirven. Que después pierdan la discusión presupuestaria no es un misterio.

El contraargumento honesto: quizá el sistema de diseño era una moda organizacional.

Hay una lectura escéptica que merece respeto, y tiene aval de analistas: el Hype Cycle 2025 de Gartner ubica a los sistemas de diseño bajando del pico de expectativas infladas hacia el valle de la desilusión. No es una opinión de foro. Es la descripción estándar de lo que pasa cuando una práctica tiene que justificar su costo.

Dice así: los design systems se popularizaron en una década de tasas bajas, equipos de producto sobredimensionados y compañías que podían darse el lujo de tener gente que no entregaba features. Cuando el ciclo se dio vuelta, la organización descubrió que un componente reutilizable no es una ventaja competitiva y que el usuario final nunca notó la diferencia entre un botón consistente y uno casi consistente. Que el 5% que mide ROI quizá no lo mide porque el ROI, medido honestamente, sea menor al que la disciplina supone.

Además, la IA cambia el cálculo. En el mismo reporte, 46% de los equipos está experimentando con IA, 71% de ellos la usa para generar código y 60% para generar documentación. Si un modelo puede producir una implementación consistente a partir de una descripción, la ventaja marginal de una biblioteca curada baja. Y 61% de los practicantes ya declara preocupación por el diseño generado por IA, lo que sugiere que la disciplina lo intuye.

La objeción es fuerte y probablemente correcta para una parte del mercado. Compañías con un solo producto, un solo equipo y una sola plataforma casi nunca necesitaron un sistema de diseño formal: necesitaban una hoja de estilos y una convención.

Pero es incompleta por un motivo. La consistencia nunca fue el beneficio principal. El beneficio principal es que un sistema de diseño es el único lugar donde una organización grande escribe, en forma ejecutable, decisiones que de otro modo se re-discuten en cada proyecto. Accesibilidad, jerarquía, comportamiento de error, tratamiento de datos sensibles. Eso no lo reemplaza un modelo generativo: un modelo generativo necesita exactamente esa fuente para no inventar. Cuanto más código se genere, más caro sale no tener una definición canónica.

Consecuencia operativa.

Tres decisiones concretas, todas de gobernanza y ninguna de diseño.

Primera: definir por escrito quién puede decir que no. Un sistema sin autoridad de rechazo no es un sistema; es un repositorio con buenas intenciones. Esa autoridad tiene que tener nombre, no departamento.

Segunda: poner el sistema en un centro de costo con dueño y con métrica. Si nadie mide el ROI, elegí una métrica imperfecta y defendela: porcentaje de pantallas construidas con componentes del sistema, tiempo de implementación de un cambio de marca, cantidad de defectos de accesibilidad por release. Una métrica mediocre y sostenida vence a una métrica perfecta que nunca se calcula.

Tercera: hacer la conformidad verificable por máquina. El caso regional con mejor adopción documentada no convenció a sus equipos con evangelización; instrumentó la verificación y el control de acceso. La cultura ayuda. El pipeline decide.

El sistema de diseño no se muere el día que alguien lo cancela. Se muere el día que su mantenedor se va a otro equipo y nadie nota el hueco durante un trimestre. Esa fecha no la fija el diseño. La fija la gobernanza.