Design systems escalables: lecciones de 10 años de producto.

Por qué los design systems fallan (y por qué a veces fallan cuando triunfan).

Hay una escena que he visto repetirse en casi todas las empresas donde he trabajado. Un equipo de producto tiene una fecha de entrega, el componente del sistema no encaja del todo con lo que necesita, y alguien dice: “lo hacemos a medida esta vez, ya lo alinearemos después”. Ese “después” no llega nunca. Seis meses más tarde hay catorce variantes de botón en producción, el sistema tiene el 60% de cobertura sobre el papel y el equipo que lo mantiene descubre que, en realidad, los usuarios ven otra cosa.

La mayoría de los design systems no fracasa por falta de componentes, sino por falta de gobernanza, propósito y alineación con el negocio. A lo largo de más de una década construyendo productos digitales, he visto sistemas nacer con entusiasmo, bien documentados, visualmente consistentes, y perder relevancia en dieciocho meses.

Un design system no es una librería. Es una infraestructura viva.

Pero hay un segundo tipo de fracaso del que se habla menos: el sistema que sí se adopta, pero lo hace tan bien que uniformiza productos que necesitaban voz propia. Cuando todo se parece, el sistema ha dejado de servir al producto y ha empezado a servirse a sí mismo. La homogeneidad no es el objetivo; la coherencia intencional sí.

El problema de la adopción.

Un design system solo tiene valor si se usa. Y para que se use, debe integrarse de forma natural en el flujo de trabajo de diseñadores y desarrolladores. No puede ser una capa adicional de fricción, ni una fuente de reglas rígidas que dificulten avanzar.

Los equipos adoptan sistemas que les ahorran tiempo real, reducen ambigüedad en decisiones, facilitan la colaboración entre diseño y desarrollo, y se integran con sus herramientas existentes (código, repositorios, pipelines). Cuando esto no ocurre, el sistema se percibe como una imposición, no como una ayuda. Y aquí aparece el primer test honesto: si mañana el sistema dejara de existir, ¿los equipos lo echarían de menos o respirarían aliviados?

Empezar por el problema, no por la solución.

Uno de los errores más comunes es comenzar construyendo componentes antes de entender el problema. Lo he hecho yo mismo en sistemas que acabaron redibujándose por completo a los dos años.

Un design system efectivo nace de observar inconsistencias en la UI que generan fricción, problemas de escalabilidad en el código, retrabajo constante entre equipos y falta de claridad en patrones de interacción. Sin este diagnóstico, el sistema será estético, pero no funcional. Y un sistema estético que nadie usa es más caro de mantener que no tener sistema en absoluto.

Más allá del diseño: sistemas como producto.

Un design system debe gestionarse como un producto en sí mismo. Esto implica tener objetivos claros (adopción, eficiencia, consistencia), medir impacto, priorizar evolución en función del uso real y escuchar activamente a sus usuarios internos. No es un entregable. Es un servicio continuo.

Métricas que realmente importan.

Las métricas clásicas que se suelen recomendar son útiles pero engañosas. “Porcentaje de componentes utilizados vs. existentes” premia podar el sistema, no ampliarlo: se mejora el número eliminando componentes legítimos que sirven a casos reales. Estos son los indicadores que, en mi experiencia, reflejan mejor la salud del sistema:

Cobertura ponderada por tráfico. No es lo mismo que el 80% de los componentes se usen que el 80% del tráfico pase por componentes del sistema. Lo segundo mide impacto real en usuarios; lo primero mide esfuerzo del equipo. En productos con Pareto extremos (donde el 5% de las pantallas recibe el 90% del tráfico), estas dos métricas pueden diferir en más de treinta puntos.

Time-to-first-component. Cuánto tarda una persona que entra al equipo (diseñador o desarrollador) en usar el sistema de forma productiva. Es un indicador directo de documentación, descubribilidad y fricción de onboarding. Si pasa de una semana, el sistema tiene un problema.

Tasa de divergencia. Cuántos componentes custom se están creando fuera del sistema, por trimestre. No es una métrica para castigar a los equipos; es una señal temprana de que algo no cubre necesidades reales y de que el roadmap del sistema está desactualizado. Un sistema saludable tiene divergencia baja pero no nula: si es cero, probablemente los equipos se están autocensurando.

Deuda de diseño acumulada. Número de pantallas en producción construidas con versiones obsoletas del sistema, o que nunca se migraron. Es la métrica menos visible y la más peligrosa: crece en silencio y explota en la siguiente refundación.

Contribuciones entrantes. No solo cuántas, sino de cuántos equipos distintos. Un sistema con diez contribuciones al trimestre del mismo equipo está muerto; uno con diez contribuciones de ocho equipos distintos está vivo.

Incidencias de accesibilidad. Con el marco regulatorio europeo actual, esta métrica pasa de ser una “nice to have” a un indicador de riesgo legal. Volveremos a ello.

Sin métricas como estas, el sistema evoluciona por intuición, no por evidencia. Y sin evidencia, las decisiones se toman según quién grite más fuerte en la reunión.

Gobernanza: el factor crítico.

La gobernanza es el elemento que separa un sistema sostenible de uno que colapsa. No se trata de control centralizado, sino de equilibrio entre autonomía y coherencia.

Modelos de gobernanza.

Existen varios enfoques conocidos: el centralizado (un equipo core controla todo: más consistencia, menos escalabilidad), el federado (equipos contribuyen bajo reglas claras: más flexible, requiere disciplina) y el híbrido (núcleo estable más extensiones por dominio, el más común en productos complejos).

La clave no es el modelo, sino la claridad en quién decide, cómo se contribuye, cómo se valida y cómo se comunica el cambio.

Lo que nadie cuenta: el modelo de financiación.

En mi experiencia, el factor que más determina la sostenibilidad de un design system no es su modelo de gobernanza, sino su modelo de financiación. Es la conversación más incómoda y la más decisiva.

Un sistema financiado por un solo producto siempre acabará sirviendo a ese producto y descuidando al resto. Cuando el producto financiador entre en crisis de roadmap, el sistema se paralizará con él. Un sistema financiado por “tiempo libre voluntario de todos los equipos” no tiene dueño: cada quien contribuye cuando puede, nadie rinde cuentas, la calidad baja y los compromisos se rompen en silencio.

Los sistemas que sobreviven tienen presupuesto propio, equipo dedicado con OKRs propios y rendición de cuentas a múltiples stakeholders. Tratar al sistema como producto implica también tratarlo como centro de coste (o de valor) explícito en la organización. Si nadie firma el cheque, nadie firma el resultado.

Procesos mínimos necesarios.

Un sistema maduro define un flujo de contribución claro (propuesta, validación, implementación), versionado explícito (breaking changes, releases), documentación viva y canales de feedback. Sin esto, el sistema se fragmenta rápidamente.

Un mecanismo que ha demostrado funcionar particularmente bien en sistemas federados es el RFC (Request for Comments): propuestas escritas cortas, revisión pública asincrónica, decisión documentada. Es un proceso ligero que hace tres cosas a la vez:

Obliga a quien propone a pensar antes de construir.
Da voz a equipos que no están en la reunión pero se verán afectados.
Deja rastro histórico del porqué de cada decisión, algo invaluable cuando alguien se pregunta dos años después “¿por qué hicimos esto así?”.

El RFC no es burocracia. Es memoria institucional.

Principios que funcionan.

Después de múltiples iteraciones, estos principios han demostrado ser efectivos.

1. Documentación junto al código.

Separar diseño y desarrollo genera inconsistencias. La documentación debe vivir donde vive el código: Storybook o equivalente, ejemplos reales de uso, casos edge documentados. Esto reduce la ambigüedad y acelera la adopción. Y, cada vez más, es la fuente de verdad que alimenta a los agentes de IA que generan UI: si tu documentación está desincronizada del código, tu IA genera pantallas obsoletas.

2. Tokens semánticos desde el inicio, en tres niveles.

El error clásico es diseñar con valores absolutos (#FF5733, 16px). El siguiente nivel es diseñar con semántica (color-primary, spacing-md). Pero en 2026 el estándar maduro es una arquitectura de tres capas:

Tokens primitivos. El vocabulario bruto: blue-500, size-16, font-weight-600. No tienen significado de producto; son la paleta cruda.

Tokens semánticos. El significado en contexto: color-action-primary, spacing-stack-md, font-weight-emphasis. Aquí es donde el diseño empieza a tomar decisiones.

Tokens de componente. La aplicación específica: button-primary-background-hover, input-error-border. Permiten afinar sin tocar semánticos.

Esta separación es la que permite que el sistema sobreviva a la tercera marca, al primer cliente enterprise que pide white-label, al dark mode, al high-contrast mode exigido por accesibilidad y a la siguiente ronda de rebranding. Sin ella, cualquier cambio sistémico obliga a tocar cada componente, y eso no escala.

3. Evolución continua, no grandes lanzamientos.

Los sistemas que esperan “la versión perfecta” nunca se adoptan. Es mejor iterar rápido, publicar versiones pequeñas y aprender del uso real. Un design system debe evolucionar al ritmo del producto, no al ritmo de un roadmap aislado.

4. Diseñar para ser desmontado.

Este principio suena contraintuitivo, pero es el que separa un sistema vivo de un museo de decisiones pasadas. Los mejores sistemas tienen estrategia de deprecación desde el día uno.

Eso significa definir desde el principio:

Cómo se marca un componente como obsoleto (visualmente en la documentación, con warnings en consola, con linters en CI).
Cuánto tiempo coexiste la versión antigua con la nueva (mínimo un ciclo mayor, idealmente dos).
Cómo se comunica el cambio (changelogs, canales dedicados, sesiones de migración).
Cómo se migra (scripts de codemod donde sea posible, no pedir al equipo que haga a mano lo que puede automatizarse).

Un sistema que no sabe jubilar componentes acumula peso hasta volverse imposible de mantener. Irónicamente, la capacidad de decir “esto ya no” es lo que permite seguir creciendo.

El design system como capa de cumplimiento.

Durante años, accesibilidad y transparencia en IA eran buenas prácticas. En Europa, desde 2025 y con hitos críticos en 2026, ya no lo son: son obligaciones legales. Este cambio reconfigura lo que es un design system.

La Ley Europea de Accesibilidad (EAA).

Desde el 28 de junio de 2025, los servicios digitales que operan en la Unión Europea bajo el alcance de la EAA deben cumplir con el estándar técnico EN 301 549, que incorpora WCAG 2.2 nivel AA. El alcance es amplio: e-commerce, banca electrónica, transporte, servicios de medios audiovisuales, libros electrónicos, y en general cualquier servicio digital ofrecido a consumidores en la UE. La ley aplica también a empresas no europeas que operen o vendan en el mercado europeo.

Para un design system, esto significa que cada componente base debe cumplir con criterios concretos de WCAG 2.2: tamaño mínimo de objetivos interactivos, indicadores de foco claramente visibles, alternativas a gestos de arrastre, contrastes suficientes, navegación completa por teclado, compatibilidad con tecnologías asistivas. Un sistema que no incluya estos requisitos por defecto no está protegiendo al producto; lo está exponiendo legalmente.

El Reglamento de IA de la UE.

El Reglamento de IA de la UE entró en vigor el 1 de agosto de 2024 y será plenamente aplicable el 2 de agosto de 2026. Esa fecha, a pocos meses de hoy, activa las obligaciones más consecuentes: documentación técnica, supervisión humana, trazabilidad, evaluación de riesgos para sistemas clasificados como de alto riesgo, y obligaciones de transparencia para sistemas de riesgo limitado.

Para los sistemas de riesgo limitado (chatbots, generadores de contenido, deepfakes), la obligación principal es la transparencia: los usuarios deben saber cuándo están interactuando con una IA. Esto es, directamente, una responsabilidad del design system: el patrón visual y semántico que indica “esto fue generado por IA” o “estás hablando con un asistente automático” tiene que existir, ser consistente y no ser opcional.

El sistema como infraestructura de cumplimiento.

El cambio conceptual es importante. Durante años tratamos el design system como capa de consistencia y eficiencia. Ahora es también la capa donde el cumplimiento se materializa o se pierde.

Un componente <Button> sin focus-indicator accesible multiplica el incumplimiento por todas las pantallas donde aparezca. Un componente <AIResponse> sin indicador claro de que el contenido es generado replica la opacidad en todo el producto. Un componente <FormField> que no asocia correctamente etiqueta con input convierte cada formulario del producto en una barrera para personas con lectores de pantalla.

La conclusión práctica es que las reglas de accesibilidad y transparencia no pueden vivir en una guideline separada que los equipos pueden olvidar. Tienen que estar codificadas en el sistema: como defaults del componente, como props obligatorias (<Image> sin alt que falle el build), como linters en CI, como tests automatizados que bloqueen el merge si bajan de un umbral.

El design system es donde la ética deja de ser declaración y se convierte en código ejecutable.

Design systems en la era de la IA: de librería a infraestructura generativa.

La incorporación de IA está transformando lo que significa diseñar y construir interfaces. Pero hay una tesis contraintuitiva que creo que merece la pena explicitar: la IA no va a reemplazar a los design systems, los va a volver imprescindibles.

El caos plausible.

Cuando un sistema de IA genera una interfaz sin un design system sólido debajo, el resultado es lo que llamo caos plausible: pantallas que parecen bien a primera vista pero que, al mirar dos veces, tienen contrastes irregulares, espaciados inventados, jerarquías inconsistentes entre vistas equivalentes y comportamientos impredecibles. La IA amplifica lo que encuentra debajo. Si el fondo es inconsistente, la salida lo será exponencialmente.

Dicho al revés: un design system maduro es lo que permite que la UI generativa deje de ser una demo impresionante y se convierta en producto confiable. La IA no inventa componentes desde cero; los compone desde una librería existente siguiendo restricciones. El sistema define el espacio de lo posible.

De componentes rígidos a patrones flexibles.

Los design systems tradicionales definen componentes estáticos. Con IA, necesitamos sistemas que contemplen interfaces ensambladas dinámicamente según contexto, contenido personalizado en tiempo real y variaciones adaptativas según usuario, intención o comportamiento.

Un ejemplo concreto: una app de viajes con UI generativa detecta que el usuario está en la puerta de embarque y reordena la pantalla. El botón “Reservar vuelo” desaparece; el código QR del embarque pasa a ocupar el área principal; aparece un mapa al café más cercano. Todo construido con los mismos componentes del sistema, recombinados según contexto. No es un rediseño; es un reensamblaje guiado por reglas.

Esto exige pasar de componentes rígidos a patrones flexibles, y eso requiere formalismos nuevos en el sistema.

Contratos de componente.

Cada componente del sistema deja de exponer solo props visuales (variant, size, color) para exponer también intención semántica: purpose="confirm-destructive-action", role="primary-navigation", urgency="critical". La IA no decide cómo se ve un botón de “eliminar cuenta”; consulta al sistema qué componente está autorizado para representar una acción destructiva irreversible, y obtiene una respuesta con las restricciones visuales, de confirmación y de accesibilidad ya integradas.

Este concepto de contrato es lo que permite que la IA sea determinista en lo importante aunque sea flexible en lo superficial.

Guardrails sistémicos.

El sistema define reglas que la IA no puede violar, pase lo que pase. Contrastes mínimos. Jerarquía de foco por teclado. Idioma y tono de marca. Presencia obligatoria de etiquetas de “generado por IA” en cualquier contenido no curado. Límites de cuántos elementos interactivos pueden aparecer en una misma vista. No son sugerencias: son invariantes del sistema, validadas en tiempo de render.

Estos guardrails son, en la práctica, la forma en que el design system protege al producto del comportamiento impredecible de los modelos generativos. Sin ellos, cada llamada al modelo es una ruleta.

Máquinas de estado conversacional.

Para productos con agentes o interfaces conversacionales, el design system gana una nueva responsabilidad: definir los estados válidos de la conversación. Pensando, respondiendo, esperando confirmación del usuario, error por alucinación detectada, escalado a humano, límite de tokens alcanzado, fuente citada, fuente no verificable. Cada estado necesita su representación visual, su microcopy, su comportamiento de teclado, su accesibilidad.

Así como el sistema antes definía los estados de un botón (default, hover, active, disabled, loading), ahora define los estados de una conversación con una IA. La complejidad es mayor, pero la naturaleza del problema es la misma: componentes con estados claros y transiciones válidas.

Nuevos artefactos del sistema.

Además de componentes visuales y tokens, empiezan a formar parte del sistema un conjunto de artefactos que antes no existían:

Prompts estructurados con variables tipadas, versionados y testeados igual que el código.
Guidelines de tono y lenguaje operacionalizadas como reglas que la IA consulta, no como PDF que nadie lee.
Reglas de generación de contenido: qué puede generar la IA, qué necesita revisión humana, qué no debe generarse nunca.
Indicadores de confianza y provenance: componentes que muestran de dónde viene cada pieza de información generada, si fue verificada, cuándo se generó.

El sistema deja de ser solo visual y se convierte en cognitivo. No significa que se escriba solo; significa que ahora también gobierna cómo piensa el producto.

Dimensiones que el sistema no puede ignorar.

Más allá de componentes y tokens, hay cinco dimensiones que, si no viven en el sistema desde el inicio, acaban pagándose caro.

Contenido como parte del sistema.

Tono de voz, microcopy, mensajes de error, confirmaciones. Son tan parte del sistema como los colores. Un sistema que resuelve la parte visual pero deja que cada equipo escriba sus propios mensajes de error produce productos visualmente consistentes y lingüísticamente caóticos. En productos con IA esto es aún más crítico: el modelo necesita guidelines de voz tan explícitas como el componente necesita tokens.

Internacionalización desde el diseño, no como capa añadida.

Pluralización, direccionalidad (RTL para árabe o hebreo), longitudes variables (el alemán expande un 30% sobre el inglés), tipografías por script, formatos de fecha, número y moneda. Un sistema que no pensó en esto desde el inicio se rompe en el primer mercado que lo exija, y la reescritura cuesta varias veces lo que habría costado hacerlo bien de entrada.

Rendimiento como restricción de diseño.

Presupuesto de bundle, tree-shaking de componentes, lazy loading de variantes poco usadas, estrategias de SSR/CSR. En 2026, con Core Web Vitals consolidado como factor competitivo y la experiencia en dispositivos medios siendo la norma global, el sistema es también responsable del rendimiento que hereda el producto. Un componente “bonito” de 80KB es peor que uno “feo” de 8KB en un móvil de gama media en conexión 3G, que es el día a día de cientos de millones de usuarios.

Testing automatizado como condición de existencia.

Pruebas de regresión visual (Chromatic, Percy o equivalentes), pruebas de accesibilidad automatizadas (axe-core integrado en CI), contratos de componente verificables. Sin automatización, la “documentación viva” es un deseo y la “accesibilidad por defecto” una buena intención. Un cambio que baje el contraste de un token primario debería fallar el build, no pasar a producción y descubrirse tres meses después cuando un usuario se queja.

Multi-marca y multi-producto.

El desafío más interesante a largo plazo es arquitectar un sistema que sirva a varios productos o marcas sin convertirse en el mínimo común denominador estético. La solución no es “un sistema por marca”, que multiplica esfuerzo. Es un núcleo compartido (primitivos, comportamientos, accesibilidad, lógica) con capas de marca intercambiables (semánticos y de componente). Bien diseñado, añadir una nueva marca significa cambiar una capa de tokens, no reescribir componentes.

Ética y responsabilidad: de declaración a requisito de componente.

Cuando los sistemas escalan, también lo hacen sus impactos. Un design system puede amplificar buenas prácticas o malas decisiones. La diferencia entre un sistema ético y uno que no lo es no está en la guideline que publica, sino en lo que permite o impide que sus componentes hagan.

Cuatro riesgos concretos, no abstractos.

Dark patterns sistematizados. El caso más común hoy son los banners de consentimiento donde “Aceptar todo” es un botón primario prominente y “Rechazar todo” está escondido como enlace terciario. Si el sistema define button-primary y button-tertiary con esa asimetría visual, y deja que cada equipo decida cuál usar, el sistema es cómplice del dark pattern que se reproduce miles de veces al día. Lo mismo ocurre con la asimetría de fricción: registrarse en un clic, cancelar la suscripción en siete.

Sesgos en contenido generado por IA. Si el sistema permite que un componente de autocompletado o de generación de contenido se use sin mecanismos de revisión ni etiquetado, los sesgos del modelo se propagan silenciosamente por todo el producto. El sistema debe ofrecer, por defecto, un envoltorio que haga visible el origen del contenido y facilite la corrección por parte del usuario.

Falta de accesibilidad en componentes base. Un componente <Modal> que atrapa el foco pero no lo libera al cerrar, un <Dropdown> que no se puede operar con teclado, un <DataTable> que no anuncia cambios a lectores de pantalla. Cada uno de estos defectos, multiplicado por el número de pantallas donde aparece el componente, es una barrera a escala y, desde 2025 en Europa, también una exposición legal.

Decisiones automatizadas opacas. Componentes que muestran “No cualificas para este servicio” o “Tu solicitud ha sido denegada” sin explicación, sin vía de revisión humana ni contacto. Bajo el AI Act, en sistemas de alto riesgo, los deployers están obligados a permitir supervisión humana y ofrecer niveles apropiados de precisión, robustez y trazabilidad. Un componente del sistema que representa una decisión automatizada sin slots obligatorios para explicación y apelación está, literalmente, codificando incumplimiento.

La ética como requisito estructural.

La propuesta operativa es clara: la ética no es una capa adicional, es un conjunto de requisitos de componente verificables. En la práctica, esto se traduce en cosas tan concretas como:

Un linter del sistema que falle si un flujo de cancelación usa button-tertiary para “cancelar” y button-primary para “mantener”.
Props obligatorias en componentes sensibles: <AutomatedDecision> no puede renderizarse sin reason, reviewChannel y humanContact.
Tests de accesibilidad que fallen el build por debajo de un umbral de severidad.
Defaults que protegen: <AIGenerated> incluye por defecto el indicador visible, y quitarlo requiere un flag explícito (revisable en code review).
Auditorías periódicas de dark patterns sobre los flujos más usados del producto.

Convertir la ética en lint rules es más efectivo que escribir una guideline que nadie lee. Y en el contexto regulatorio europeo, ya no es una opción: es la única forma realista de escalar el cumplimiento.

Conclusión: la pregunta que queda abierta.

Un design system no es una colección de componentes. Es una herramienta estratégica que conecta diseño, tecnología, negocio y experiencia de usuario. Pero en 2026, con el EAA en vigor, el AI Act activándose, y la UI generativa dejando de ser demo para ser producto, el rol del sistema es más crítico que nunca.

El sistema ya no es solo la capa que hace a los productos consistentes y eficientes. Es:

La infraestructura donde se codifica el cumplimiento regulatorio.
La base que permite (o imposibilita) la UI generativa confiable.
El lugar donde la ética deja de ser intención y se convierte en invariante técnico.
La memoria institucional de decisiones que, de otro modo, se repetirían cada dos años.

Su éxito ya no depende de lo completo que esté, sino de qué problemas resuelve, qué tan fácil es usarlo, cómo evoluciona con el producto y, cada vez más, qué tan responsable es en su impacto sistémico.

La pregunta que te dejo, si lideras o trabajas en un producto digital hoy, no es si tu sistema está bien documentado o bien tokenizado. Es esta: ¿tu design system está listo para ser la capa donde se cumplen tus obligaciones legales, donde se apoya tu próxima generación de IA y donde tus principios éticos se vuelven inviolables por defecto?

Si la respuesta honesta es no, el problema no es estético. Es estructural. Y el coste de arreglarlo crece cada mes que pasa.

Construir un design system escalable implica diseñar no solo interfaces, sino sistemas de decisión. Y eso, en esencia, es diseño de producto hecho con responsabilidad.