Design systems que los desarrolladores sí usan (y por qué la mayoría muere en Figma)

Casi todos los design systems siguen el mismo arco. Un diseñador pasa un trimestre construyendo una librería de componentes preciosa en Figma. Hay un deck de lanzamiento, una convención de nombres, un anuncio en el canal del equipo. Ocho meses después, el archivo de Figma tiene 200 componentes pulidos, producción usa unos 25, y cada feature nueva sale con valores hex escritos a mano porque el deadline era el jueves.

El sistema no falló porque el diseño fuera malo. Falló porque solo existía en Figma, y Figma no hace deploy.

Por qué los design systems mueren en Figma

Una librería de Figma y un codebase en producción son dos fuentes de verdad, y dos fuentes de verdad siempre se separan. Los diseñadores evolucionan la librería. Los desarrolladores copian el componente que ya está en el repo, lo ajustan y siguen. Dos trimestres después, "on brand" significa una cosa en design review y otra distinta en code review, y nadie puede probar cuál es la correcta.

La prueba de un design system nunca fue si los diseñadores lo usan. Ellos lo construyeron, obvio que lo usan. La prueba es si un desarrollador con el deadline encima toma el sistema porque es el camino más rápido para terminar. Cualquier otra métrica de adopción es decoración.

Esta es la postura que defendemos sin matices: si tus tokens no existen como variables CSS en producción, no tienes un design system. Tienes un moodboard con convención de nombres. En esa brecha se muere la consistencia de marca, y en B2B eso no es cosmético. La marca es un problema de revenue, porque los compradores leen la deriva visual como deriva organizacional.

Tokens primero, componentes después

El orden en que la mayoría de los equipos construye está al revés: primero los componentes, botones y cards y modales, y los tokens después, si acaso. Empieza por la capa de tokens y ponla en el único lugar que ninguna de las dos disciplinas puede ignorar: variables CSS.

Dos niveles. Los primitivos son valores crudos con nombre de escala: brand-600 es #2563eb, coral-700 es #c73c12, neutral-200 es #e2e8f0. Los tokens semánticos son roles que apuntan a primitivos: background, foreground, muted, border, accent. Los componentes referencian tokens semánticos para superficies y texto, nunca primitivos. Esa única regla es la diferencia entre que "cambiar el tema del producto" sea editar tokens o una migración de seis semanas.

Tailwind CSS 4 dejó esto casi gratis. El bloque @theme convierte las definiciones de tokens en clases de utilidad directamente, así que la capa de variables y la capa de clases no pueden divergir. Si tu tooling de diseño y tu codebase viven en universos separados, Style Dictionary o Tokens Studio sincronizan variables de Figma hacia CSS. Cuidado con la dirección del sync, eso sí. El código es la fuente de verdad de lo que se publica, porque es la única capa que tus usuarios ven.

El contrato de paridad de componentes

Los tokens mantienen honestos los colores. La paridad mantiene honestos los componentes. El contrato cabe en una frase: un componente existe cuando existe en Figma y en código con el mismo nombre y las mismas variantes, o no existe.

"Button / Secondary / Small" en Figma es <Button variant="secondary" size="sm" /> en código. Mismos nombres, mismas opciones. Cuando los nombres coinciden, design review y code review por fin hablan el mismo idioma, y el handoff pasa de ser una reunión a ser un link.

La paridad también impone un tope sano. No necesitas 200 componentes. La mayoría de los productos B2B necesita entre 25 y 40 que sean reales en ambos mundos. Todo lo demás es un huérfano, un frame de Figma que nadie construyó o un componente de código que nadie diseñó, y ambos tipos de huérfano son deriva con fecha. Mantén el inventario público. Un Storybook o una página de style guide en vivo es el registro público del contrato. Si un componente no está en el inventario, es una propuesta.

Dark mode es una restricción, no un tema

Muchos equipos tratan el dark mode como un feature para después, y después es exactamente cuando se vuelve caro: una auditoría de cada color hardcodeado en el codebase. En un sistema token-first, el dark mode es un segundo set de valores para los mismos tokens semánticos. light-dark() de CSS más un override con data-theme resuelve el cambio. Nosotros lo publicamos en nuestro propio sitio en un branch, no en un trimestre.

El dark mode también mantiene honestos tus nombres. "Blanco" no es un token, porque en dark mode no es blanco. "Background" sí es un token. Si no puedes nombrar un color por su rol, todavía no entiendes el rol.

Y obliga a que las decisiones de contraste vivan en los tokens, que es donde pertenecen. Nuestro coral-500 mide 2.84:1 contra texto blanco, muy por debajo del piso de 4.5:1 de WCAG AA, así que los botones usan coral-700 y coral-500 queda decorativo. Un sistema token-first codifica esa decisión una sola vez. Un sistema que vive solo en Figma la vuelve a discutir en cada pantalla, y pierde las veces suficientes como para que un escaneo de accesibilidad se convierta en un riesgo comercial.

Gobernanza que sobrevive al deadline del jueves

Gobernanza de design system suele significar un documento de 40 páginas que nadie lee y un comité que nadie logra agendar. Esa versión muere la primera vez que una fecha de lanzamiento se cruza con un caso borde. La gobernanza que sobrevive a la presión del deadline es pequeña y mecánica:

• Una regla de lint que marca valores hex crudos en archivos de componentes. El build dice que no para que no tenga que decirlo una persona.
• Un dueño, no un comité. Un token o variante nuevo se aprueba o se rechaza por una persona en menos de un día.
• Una salida de emergencia escrita. A veces la excepción se justifica. Regístrala, publícala y revísala cada mes. La alternativa no es cero excepciones; es excepciones sin registro por todas partes.
• El sistema tiene que ser el camino más rápido. Si usar el token es más lento que escribir un hex, el hex gana todos los jueves de aquí en adelante.

Nada de esto funciona si diseño y desarrollo reportan a mundos separados y solo se encuentran en el handoff. Por eso armamos diseño e ingeniería como un solo equipo, no como una carrera de relevos, y por eso nuestros MVPs de 16 semanas arrancan con tokens en la semana uno.

Lo que nos enseñó publicar el Octet Grid

Este año reconstruimos la identidad de DGTL alrededor de un símbolo que llamamos Octet Grid: ocho celdas en una cuadrícula de tres por tres con el centro vacío. Las ocho celdas son nuestras ocho prácticas. El centro vacío es el cliente al que rodean.

Lo interesante no fue el símbolo. Fue el rollout. Nuestro sitio tiene alrededor de 140 páginas estáticas en inglés y español, en modo claro y oscuro, más imágenes OG generadas, favicons y un manifest. Toda la identidad visual se resuelve en un solo bloque @theme en un archivo CSS: 52 variables, unas 60 líneas. Cuando llegó el Octet Grid, cambiar el estilo de todo el sitio fue editar ese bloque. El logo, los botones, los gráficos y las imágenes sociales tomaron el cambio porque no tenían otro lugar de dónde sacar sus colores.

Esa es la lección que pondríamos en cada proyecto de marca: la consistencia no es disciplina, es arquitectura. La disciplina se acaba en la semana del deadline. A la arquitectura no le importa qué semana es.

Si tu producto se ve distinto a tu sitio web, y tu sitio se ve distinto a tu deck, la solución no es más policía de marca. Es una capa de tokens, un contrato de paridad y una gobernanza que cabe en una página. Ese es el trabajo de nuestra práctica de Studio, y nuestra propia marca opera igual, en público: los tokens, las combinaciones de contraste y las reglas de uso están en nuestra página de marca para que cualquiera las revise.

Relacionado: Diseño de marca B2B y conversión → · Equipos multipráctica → · El MVP de 16 semanas →