No necesitas un sistema de diseño
La mayoría de los equipos que lanzan un sistema de diseño están haciendo LARP de madurez. El coste de mantenimiento supera el beneficio, la generación con IA destroza las cuentas, y un stack de tokens más primitivas más criterio le gana a un sistema totalmente especificado en el 95% de las organizaciones.
Probablemente no necesitas un sistema de diseño. Necesitas unos pocos design tokens, una pequeña librería de componentes y a alguien en el equipo con criterio. Eso de lo que tu cuenta de Twitter de diseño favorita no para de hablar, el archivo de Figma con 400 componentes publicados y 12 temas, es un producto a tiempo completo que tu startup de ocho personas está pagando sin cobrar nada a cambio.
Esta es la opinión que todo el mundo en la industria sabe que es cierta y nadie dice en voz alta. La factura de mantenimiento es real. El beneficio es en su mayoría imaginario. La generación con IA acaba de agrandar la brecha entre ambos.
El 95% de los equipos que lanzan un sistema de diseño están haciendo LARP de madurez. El 5% que de verdad lo necesita normalmente no es el que hace la pregunta.
Un sistema de diseño es un producto, no una misión secundaria
Un sistema de diseño real tiene su propio roadmap, su propio changelog y sus propios clientes. Esos clientes son los ingenieros y diseñadores que lanzan el producto de verdad. Si nadie tiene asignado mantener el sistema, no es un sistema. Es una foto fija.
Mira quién lanza bien sistemas de diseño. Stripe tiene un equipo de infraestructura de diseño dedicado. Shopify Polaris tiene su propia organización. GitHub Primer tiene un repositorio público con versiones publicadas.
Atlassian lleva años invirtiendo en un sistema cuyo alcance la mayoría de los equipos jamás igualará. Cada uno de ellos es un equipo de producto que construye herramientas para una base de clientes internos que se cuenta por miles.
Ahora mira la versión típica. Un diseñador senior pasó seis semanas en Figma, publicó 80 componentes, escribió una página de Notion que ningún ingeniero lee y lanzó dos temas. Seis meses después, la mitad de los componentes están desactualizados, los tokens se desvían del código y el equipo vuelve a copiar clases de Tailwind. El sistema no falló. El equipo falló al no asignar a nadie para mantenerlo.
La factura de mantenimiento que nadie pone en la presentación
El pitch del beneficio dice: constrúyelo una vez, reutilízalo para siempre. Las cuentas reales: constrúyelo una vez, luego mantenlo para siempre, y reutiliza una parte a veces.
Cada design token que existe tiene que mantenerse sincronizado entre Figma y el código. Cada variante de componente tiene que probarse cuando se actualiza el framework. Cada cambio incompatible en Radix, React o Tailwind se propaga a cada producto dependiente. La documentación se pudre en un trimestre.
La instancia de Storybook se rompe con una actualización de dependencias y nadie lo nota durante tres semanas. La librería publicada de Figma va una versión por detrás del código. Los temas divergen. Los componentes del sistema no son los componentes del producto.
La contabilidad honesta es esta. Un "sistema" de seis componentes puede ahorrar tiempo real. Un sistema de 200 componentes en una empresa de 12 personas es un impuesto. Las horas de beneficio son lineales, las de mantenimiento se acumulan, y en algún momento las líneas se cruzan. La mayoría de los equipos las cruzan sin darse cuenta porque el mantenimiento aparece como mensajes de Slack del viernes por la tarde en lugar de como una línea del P&L.
La generación con IA acaba de destrozar las cuentas
Todo el argumento a favor de un sistema de diseño descansaba en un solo número: el coste de producir un componente nuevo bien estilizado. Ese número ahora es un error de redondeo.
Un ingeniero junior puede escribir "dame una página de ajustes con una barra lateral, tres secciones y una barra de guardado que siga el patrón de estado de carga" y lanzar un componente funcional en veinte minutos. v0 genera por defecto salidas con forma de Shadcn. Cursor y Claude pueden refactorizar un flujo entero sobre primitivas existentes. El beneficio que antes daba un sistema de diseño, generación rápida de UI de aspecto consistente, ahora es un servicio gratuito incluido en todos los IDE del mercado.
El impuesto del sistema no cambió. El beneficio se desplomó. Esa es toda la historia. Los equipos que construyeron sistemas de diseño en 2022 para ir más rápido ahora son más lentos que los equipos que lanzan Shadcn más Tailwind más un prompt, porque todas las herramientas de IA se entrenaron con lo segundo e ignoran lo primero.
El 5% que de verdad necesita un sistema de diseño
Un sistema de diseño real solo se paga solo cuando se cumplen todas a la vez unas condiciones concretas. Falla una y las cuentas se caen.
- Varios productos que comparten una identidad. Atlassian tiene Jira, Confluence, Trello y una docena más. Una identidad, muchas superficies. El sistema es la capa de unificación.
- Plantilla de cientos, no de decenas. Por debajo de 50 ingenieros de producto, cada componente está a un mensaje de Slack de su arreglo. Por encima de 200, eso no escala y un sistema pasa a ser el único camino.
- Un equipo de design ops o infraestructura de diseño con personal asignado. Un sistema de diseño sin responsable es un cementerio. El responsable tiene que ser un rol real, no un proyecto al 20% del tiempo.
- Consumidores externos. Los sistemas de diseño open source como GitHub Primer o Shopify Polaris son también productos dirigidos a desarrolladores. El coste de mantenimiento se justifica por la adopción externa.
- Un dominio regulado o con fuertes exigencias de accesibilidad. Salud, finanzas, gobierno. El sistema codifica el cumplimiento normativo y la preparación para auditorías, un beneficio que ningún equipo individual puede replicar.
Si un equipo cumple los cinco, un sistema de diseño es la decisión correcta. Si cumple uno o dos y lanza un producto con 40 ingenieros, un sistema de diseño es cosplay. El artículo sobre el anti-dashboard trata un patrón relacionado: construir infraestructura para un tamaño de organización que todavía no tienes.
El sistema visual mínimo viable
Para el 95%, la respuesta es un stack de tres capas que cuesta casi nada de mantener y produce casi el mismo resultado.
| Capa | Qué es | Herramientas | Coste de mantenimiento |
|---|---|---|---|
| Tokens | Color, tipografía, espaciado, radio y sombra como variables | Config de Tailwind, variables CSS, variables de Figma | Bajo. Un archivo. Se actualiza cada trimestre. |
| Primitivas | Componentes headless o con estilo, accesibles por defecto | Shadcn, Radix, Headless UI, primitivas de Cal.com | Bajo. Se copian al proyecto, no se mantienen. Se actualizan bajo demanda. |
| Criterio | Una persona que sabe cuándo romper las reglas | Un diseñador senior o un ingeniero con cultura de diseño | Gratis si contratas bien, infinito si no. |
Ese es todo el stack. Los tokens te dan consistencia. Las primitivas te dan accesibilidad y comportamiento. El criterio te da la capa que ningún sistema puede codificar: el juicio sobre cuándo las reglas deben doblarse.
Los equipos que lanzan los productos más limpios en 2026 usan una versión de esto. Linear funciona con un set diminuto de tokens, primitivas propias y un criterio obsesivo. Vercel lanza una config de Tailwind pesada más sus propias primitivas.
Cal.com publica sus primitivas públicamente. Resend y Loops lanzan UI con forma de Shadcn con tokens propios por encima.
Notion funciona con un conjunto pequeño de tokens y un vocabulario de componentes deliberadamente ajustado. Ninguno de ellos tiene un "sistema de diseño" en el sentido de Atlassian. Todos tienen un stack de sitio de marketing que se ve más coherente que el de empresas diez veces más grandes.
Por qué Shadcn se está comiendo la categoría de sistemas de diseño
Shadcn no es una librería de componentes. Es un mecanismo de entrega del nuevo estándar. Las primitivas se copian al código, se estilizan con Tailwind y son accesibles porque Radix hace el trabajo pesado por debajo. El usuario es dueño de los componentes, puede editarlos libremente y nunca queda bloqueado por versiones upstream.
Ese es el golpe de gracia para la mayoría de los sistemas de diseño internos. La razón por la que los equipos construían el suyo era el control. Shadcn da el control gratis. La razón por la que los equipos lanzaban Storybooks era la descubribilidad.
Shadcn publica su documentación y las herramientas de IA la indexan. La razón por la que los equipos publicaban librerías de Figma era la consistencia. Las primitivas de Shadcn son lo bastante consistentes como para que cualquier prompt sobre ellas produzca una salida que el equipo ya sabe evaluar.
Shadcn más Tailwind más un set de tokens es el stack visual por defecto de 2026. Es lo que produce por defecto cada herramienta moderna de codegen con IA. Es lo que lanza primero cada equipo de producto nuevo. Es el modelo de primitivas más criterio en dos repos y un archivo de config. El sistema de diseño como artefacto separado, con su propio pipeline de publicación y su propio equipo, ahora es el caso especial.
Cuándo un sistema real por fin se paga solo
La versión honesta de la pregunta "¿necesitamos un sistema de diseño?" es "¿ya hemos cruzado el umbral de mantenimiento?"
| Señal | ¿Hace falta un sistema? |
|---|---|
| Dos ingenieros lanzan botones inconsistentes en la misma semana | No. Añade un archivo de tokens. |
| Tres productos comparten marca y divergen visualmente | Quizá. Empieza con tokens compartidos. |
| Varios equipos lanzan el mismo componente de forma distinta cada trimestre | Sí. Toca tener primitivas compartidas. |
| Un componente concreto lo reconstruyen cuatro equipos en seis meses | Sí. Asciéndelo al sistema. |
| Incorporar a un diseñador nuevo lleva dos semanas porque las convenciones son tribales | Sí. El sistema ya es un beneficio. |
| Desarrolladores externos consumen tus componentes | Sí. El sistema es un producto. |
| Auditorías de cumplimiento o accesibilidad llegan a tu roadmap | Sí. Codifícalo una vez. |
Si un equipo cumple tres o más de esas señales, un sistema real está justificado. Si cumple una, un archivo de tokens basta. La misma lógica aparece en cómo el problema de la página de precios y onboarding sin onboarding resuelven la coordinación a nivel de superficie en lugar de a nivel de sistema.
El patrón, y luego el remate
El postureo de madurez está al revés. Los equipos que lanzan los productos más coherentes en 2026 no son los que tienen los sistemas de diseño más grandes. Son los que tienen la menor deuda visual. Set de tokens ajustado, capa de primitivas fina y un diseñador con criterio que dice que no a menudo.
Los sistemas de diseño reales son infraestructura para organizaciones que han superado la alternativa. No son un hito que todo equipo deba alcanzar. No son un símbolo de estatus. No son la respuesta a "queremos parecer más profesionales".
Un equipo que construye uno antes de ganarse el presupuesto de mantenimiento lanza el mismo producto con un reloj más lento y un archivo más pesado. El que lanza tokens más Shadcn más criterio lanza el mismo producto con un reloj más rápido y usa el tiempo ahorrado para arreglar el problema de la página de ajustes.
La pregunta no es "¿tenemos un sistema de diseño?". Es "¿estamos pagando mantenimiento al nivel de abstracción correcto?"
FAQ
¿Cuál es la diferencia entre un sistema de diseño y una librería de componentes?
Una librería de componentes es un conjunto de piezas de UI reutilizables. Un sistema de diseño es una librería de componentes más tokens, más documentación, más gobernanza, más un responsable, más una cadencia de lanzamientos. La mayoría de los equipos lanzan una librería de componentes y la llaman sistema. No son lo mismo, y el segundo tiene un coste de mantenimiento que la primera no tiene.
¿Es Shadcn un sistema de diseño?
No. Shadcn es un mecanismo de entrega de primitivas. Los componentes se copian al código y pertenecen al equipo. No hay librería central, ni calendario de lanzamientos upstream, ni gobernanza.
Ese es el punto. Le da al equipo el beneficio de un sistema sin la factura de mantenimiento.
¿Cuándo debería una startup invertir en un sistema de diseño?
Cuando al menos tres de estas cosas son ciertas: varios productos que comparten identidad, cincuenta o más ingenieros lanzando UI, un rol de design ops con personal asignado, consumidores externos de los componentes o un dominio regulado. Por debajo de ese listón, lanza tokens más primitivas más criterio y dedica las horas ahorradas al producto de verdad.
CTA
¿Quieres un producto donde el sistema visual encaje con el tamaño del equipo? Brainy lanza stacks de tokens más primitivas para el 95% y sistemas de diseño completos para el 5%, calibrados al presupuesto real de mantenimiento. Contrata a Brainy. Te diremos de qué lado de la línea estás antes de que gastes un trimestre en el artefacto equivocado.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
