El sistema de diseño ya no es una librería: es la fuente que la máquina va a leer

Un 91% de los equipos dice confiar en su sistema de diseño, pero solo un 7% lo tiene realmente adoptado. Ese hueco entre confianza y uso era antes un problema de disciplina interna. Con la IA generando código a escala, se convirtió en un problema de infraestructura. Porque lo que el sistema no decide explícitamente, ahora alguien más lo decide por nosotros. Y lo replica mil veces.

El dato que incomoda

El Design Systems Report 2026 de zeroheight —quinta edición, 147 practitioners encuestados— trae una de esas cifras que uno preferiría no leer un lunes: el 91% de los equipos declara confiar en su sistema de diseño, pero no lo usa de manera consistente. Solo un 38% reporta una adopción moderada y apenas un 7% una adopción completa a lo largo de todos los equipos.

Y hay más. La satisfacción con el respaldo interno —el famoso buy-in— cayó de 42% a 32% en un año. El 61% de los equipos se declara con dotación insuficiente. Solo el 41% mide adopción y un modestísimo 5% mide ROI.

Puesto en simple: tenemos sistemas en los que la gente cree, que casi nadie usa completo, que nadie mide y que cada vez cuesta más defender ante la mesa donde se reparte el presupuesto.

Desde la experiencia, esa combinación tiene un nombre en los pasillos de producto: el componente que existe pero nadie encuentra. Es primo hermano de la documentación que está impecable en un lugar que nadie recuerda.

Lo que cambió este año (y por qué ya no da lo mismo)

Durante años esta brecha fue un dolor administrativo. Molesto, sí, pero acotado: si un equipo se salía del sistema y armaba su propio botón, el daño era un botón. Fastidioso para quien revisaba, invisible para el negocio.

Ese cálculo se rompió.

El mismo reporte muestra que el 56% de los equipos de sistemas de diseño ya experimenta con o integra IA, arriba del 46% del año anterior. Y sus tres usos principales son elocuentes: generación de código (71%), generación de documentación (60%) y prototipado (50%).

Del otro lado, el AI in Design Report 2026 —de Designer Fund y Foundation Capital, publicado en el primer trimestre— confirma la tendencia desde la vereda del diseñador individual: 91% usa IA semanalmente (contra 54% el año anterior), 75% la usa a diario, el stack promedio pasó de 3 a 7 herramientas, y la mitad de los encuestados ya ha enviado código a producción. El uso de IA específicamente para sistemas de diseño y componentes subió 24 puntos.

Dos estudios distintos, muestras distintas, misma conclusión: la producción de interfaz se aceleró y la generación de código se volvió el caso de uso estrella.

Ahora júntelo con el dato del principio. Un sistema de diseño con 7% de adopción real, en un entorno donde la mitad de los diseñadores despacha código a producción con asistencia de IA. La brecha ya no produce un botón distinto. Produce variantes a velocidad industrial.

No es casualidad que el 62% de los encuestados del reporte de IA señale la inconsistencia de resultados como su mayor desafío, ni que el 61% de los equipos de sistemas de diseño declare preocupación por el diseño generado por IA. Son la misma inquietud vista desde dos ventanas.

La anécdota de rigor

En aventuras laborales previas podría decir que casi todos hemos vivido la misma escena, con distintos actores.

Auditoría de interfaz, un viernes. Alguien decide contar cuántos estilos de botón primario conviven en el producto. La apuesta interna arranca en tres. Termina en once. Once. Uno de ellos existía únicamente porque un componente heredó un padding de una campaña de marketing de dos años atrás que nadie se atrevió a tocar. Otro tenía un nombre que solo se explicaba por una conversación que ocurrió en un pasillo y nunca en un documento.

La reacción clásica frente a eso es purgar: consolidar los once en uno, celebrar, tomarse la foto.

Y a los ocho meses hay nueve.

Porque el problema nunca fueron los once botones. Los once botones eran el síntoma. La causa era que el sistema documentaba qué usar y jamás cuándo ni por qué. Cuando alguien enfrentaba un caso que el sistema no había previsto —y siempre aparece uno— no tenía a quién preguntarle. Entonces decidía solo, con criterio propio y buena fe. Que es exactamente lo que hoy hace un modelo de lenguaje, solo que mucho más rápido y sin la culpa de saltarse una convención.

Recordando algunos proyectos, podría considerar que ahí está el verdadero cambio de época: antes las decisiones no documentadas las tomaba una persona apurada; hoy las toma una máquina incansable.

Del catálogo a la infraestructura de decisiones

Hay una frase en el reporte de zeroheight que vale más que varios capítulos: "la IA puede ayudarte a documentar más rápido, pero no puede decidir qué vale la pena documentar".

Ahí está el punto de quiebre conceptual. Si su sistema de diseño es un catálogo —una lista de piezas disponibles— entonces la IA es competencia directa y va a ganar, porque genera piezas más rápido que cualquier equipo de tres a cinco personas (el tamaño más común, según el mismo estudio: 33% de los casos).

Pero si su sistema de diseño es infraestructura de decisiones —un registro de qué se resolvió, por qué, en qué contexto y con qué frontera— entonces la IA es la mejor cosa que le pasó, porque es un ejecutor obediente y veloz de decisiones que otros ya tomaron con criterio.

La distinción se parece bastante a la diferencia entre un pedal de efectos y una canción. El pedal es un componente: existe, tiene perillas, hace algo. La canción es la decisión de cuándo pisarlo. Se pueden tener todos los pedales del mercado y no tener canción. Y créame que hay discos que lo demuestran.

Qué se ve distinto en un sistema que decide

Un catálogo responde "¿existe un componente para esto?". Una infraestructura de decisiones responde cuatro preguntas más:

1. ¿Por qué esta pieza es así? No la especificación, la razón. "El botón destructivo pide confirmación porque la investigación mostró errores irreversibles en flujos de borrado masivo." Eso es transferible a un caso nuevo. Un valor hexadecimal, no.

2. ¿Dónde termina el sistema? Los sistemas fallan menos por lo que definen y más por lo que dejan en penumbra. Declarar explícitamente los territorios no resueltos —"para tablas de datos densas todavía no hay estándar, hable con el equipo"— convierte una zona de improvisación silenciosa en una decisión consciente y rastreable.

3. ¿Cómo se resuelve una excepción? Todo sistema real tiene excepciones. La diferencia entre un sistema sano y uno decorativo es si existe una ruta legítima para pedirlas, o si la única salida es hacerlo por su cuenta y no contarle a nadie.

4. ¿Alguien está mirando? Este es el más incómodo, porque el reporte lo deja al desnudo: solo el 41% mide adopción. Y el mismo estudio encuentra que los sistemas con mayor confianza son justamente los que rastrean uso de componentes, en diseño y en código. La correlación no es misteriosa: lo que no se observa, no se puede defender; lo que no se puede defender, pierde presupuesto; lo que pierde presupuesto pierde a las tres personas que lo sostenían.

Implicaciones prácticas para equipos de producto y diseño

Sin recetas mágicas, cuatro movimientos que suelen rendir más de lo que cuestan:

• Documente el criterio, no solo el resultado. Por cada componente relevante, un párrafo de "cuándo sí y cuándo no". Es la parte del sistema que un modelo puede leer y aplicar; también la que un diseñador nuevo agradece en su primera semana.

• Empiece a medir algo, aunque sea imperfecto. Un 41% mide adopción y un 5% mide ROI: el listón está bajísimo. Un solo indicador —porcentaje de pantallas construidas con componentes del sistema— ya lo pone en la mitad buena de la tabla y le da un argumento numérico donde antes había convicción.

• Trate el sistema como contexto para la IA, no como carpeta de assets. Si sus equipos generan código asistido, la documentación de decisiones debe estar donde esa asistencia pueda alcanzarla. Un sistema hermoso e inaccesible para las herramientas que efectivamente construyen el producto es un sistema que se saltea todos los días.

• Nombre lo que no está resuelto. Un mapa honesto de zonas grises previene más deuda que un catálogo aspiracional completo. Y es infinitamente más barato de mantener.

Toda mejora puede ser potenciada desde la investigación oportuna, y esto no es la excepción: antes de rediseñar el sistema, conviene averiguar por qué los equipos se lo saltan. Casi nunca es rebeldía. Casi siempre es que no encontraron respuesta a tiempo y tenían una fecha encima.

Hay una lectura pesimista de estos números: adopción baja, respaldo cayendo, equipos cortos de gente, IA presionando desde afuera. Un buen material para un lamento de conferencia.

Durante una década los sistemas de diseño se midieron por cobertura: cuántos componentes, cuántos tokens, cuántas variantes documentadas. Era una carrera de inventario, y era una carrera que los equipos pequeños perdían por definición. Esa carrera se acabó, y perderla es la mejor noticia del año. Ganar en volumen de componentes ya no está a nuestro alcance ni tiene sentido intentarlo.

Lo que sí está a nuestro alcance —y es exactamente donde un equipo de tres personas con buen criterio puede superar a cualquier generador— es el trabajo de decidir bien, dejar constancia de por qué, y sostener esa constancia en el tiempo. Más talento que recursos, más pasión que oportunidades: el oficio siempre supo funcionar así.

La IA no vino a reemplazar el sistema de diseño. Vino a cobrarle intereses por cada decisión que nunca se escribió. Y esas decisiones, todavía, las tomamos nosotros.

Los productos digitales también necesitan humanidad. Últimamente resulta que también necesitan memoria.