Para qué servía realmente
El diseño atómico propuso que las interfaces se entendieran como una jerarquía: átomos (una etiqueta, un campo de entrada, un botón), moléculas (un formulario de búsqueda), organismos (el encabezado de un sitio), plantillas (diseño a nivel de página sin contenido) y páginas (una plantilla con contenido real).
Vale la pena recordar el contexto. En 2013, la mayor parte del trabajo de front-end se basaba en páginas. Los diseñadores entregaban maquetas de páginas individuales; los desarrolladores construían páginas individuales; el mismo botón existía en once formas ligeramente diferentes y nadie tenía un nombre para ese problema. El diseño atómico dio a los equipos un vocabulario compartido y, lo que es más importante, el argumento de que las interfaces deberían componerse a partir de un sistema en lugar de dibujarse página por página.
Ese argumento ganó por completo. Cada framework basado en componentes, cada sistema de diseño y cada capa de tokens en uso actual lo asume. Cuando la gente dice que el diseño atómico ha muerto, lo que suelen querer decir es que su conclusión se convirtió en el estándar y su terminología pasó a ser opcional, que es exactamente lo que significa ganar para una metodología.
La conclusión del diseño atómico se convirtió en el estándar y su terminología pasó a ser opcional. Así es como gana una metodología.
Qué niveles justifican su existencia
Los cinco niveles no son igualmente útiles, y fingir que lo son es donde los equipos pierden tiempo. Clasificados según la cantidad de discusiones que genera cada uno por unidad de valor:
| Valor | Coste | |
|---|---|---|
| Átomos | Alto. Un botón, un campo de entrada, una etiqueta: todo el mundo está de acuerdo | Bajo. El límite es obvio |
| Moléculas | Bajo. La categoría existe principalmente para situarse entre otras dos | Alto. Todos los equipos discuten sobre ello, permanentemente |
| Organismos | Alto. Un encabezado, una tarjeta, una tabla de datos: unidades significativas | Medio. El límite de la molécula también es difuso desde este lado |
| Plantillas | Alto. El diseño sin contenido es una abstracción genuinamente útil | Bajo, y actualmente absorbido en su mayoría por las primitivas de diseño de los frameworks |
| Páginas | Alta. El contenido real revela los errores de la plantilla | Baja |
La fila de las moléculas no es un detalle insignificante. Pregunte a cinco ingenieros si una tarjeta con una imagen, un título y un botón es una molécula o un organismo y obtendrá una conversación de cuarenta minutos sin ninguna consecuencia práctica. Cualquier nivel de taxonomía cuyo límite no pueda decidirse rápidamente y que no cambie lo que se construye es una carga innecesaria.
Una simplificación práctica en la que la mayoría de los equipos convergen de forma independiente: primitivas (bloques de construcción sin estilo o con estilo mínimo), componentes (lo que los ingenieros de producto importan realmente) y layouts. Tres niveles, límites que se pueden decidir en cinco segundos y la misma disciplina de composición.
El compromiso de la composición
Existe una crítica más contundente que "las etiquetas son quisquillosas", y proviene de un equipo que tuvo los recursos para implementar el diseño atómico correctamente y decidió no hacerlo.
El equipo de diseño de Airbnb publicó que, en lugar de depender de átomos individuales, trataron los componentes como elementos de un organismo vivo: cada uno con una función y personalidad, definidos por un conjunto de propiedades, capaces de coexistir y de evolucionar o morir independientemente. El beneficio declarado fue evitar una red complicada de partes interconectadas.
Se trata de un intercambio real, no de una preferencia:
| Composición atómica | Componente autónomo | |
|---|---|---|
| Duplicación | Mínima; ese es el objetivo | Alguna, aceptada deliberadamente |
| Cambiar un átomo compartido | Se propaga a todas partes, incluso en lugares que nadie revisó | Cambia una sola cosa |
| Multiplataforma | Difícil: el árbol de átomos debe existir idénticamente en todas partes | Más fácil: solo el contrato debe coincidir |
| Modo de fallo | Un cambio rompe silenciosamente cuatro superficies | Dos componentes divergen sin que nadie lo note |
Ninguna de las dos columnas es correcta en general. Un producto web de plataforma única con una sola base de código obtiene un valor real de la reutilización máxima y puede absorber el riesgo de propagación. Un sistema que abarca cuatro plataformas no puede, porque el árbol de átomos tendría que reproducirse idénticamente en cada una y no será así. Airbnb tenía cuatro plataformas.
Component specimen · Button
Folio Index
Live renderThe button primitive in Folio Index, across 4 states.
Default
Hover
Focus
Disabled
Qué cambia cuando un agente ensambla la interfaz
Aquí está la parte que es genuinamente nueva, y corta en una dirección inesperada.
La contribución principal del diseño atómico fue un vocabulario compartido. Permitió que un diseñador, un ingeniero y un gestor de producto señalaran lo mismo y se refirieran a lo mismo. Un agente de código no necesita eso. Ya sabe qué son un botón, una tarjeta, una barra de navegación y una tabla de datos, con un detalle enorme, en todos los frameworks que se puedan utilizar. El problema de nomenclatura que resolvió el diseño atómico no es un problema que tenga un agente.
Lo que le falta a un agente está en otro lugar totalmente distinto:
| El diseño atómico le ofrece | Lo que el agente necesita realmente | |
|---|---|---|
| Vocabulario | Nombres para los niveles de composición | Ya los tiene. En todos los frameworks |
| Estructura | Una jerarquía de partes | Útil, y de todos modos infiere la mayor parte |
| Restricciones | Nada | Aquí está la brecha. ¿Qué está prohibido? |
| Intención | Nada | ¿Para qué sirve este diseño? ¿Quién lo lee? |
| Valores | Nada; los átomos son una categoría, no una especificación | La escala real, los roles reales, los números reales |
Las tres filas inferiores están vacías a la izquierda, y eso no es una crítica a la metodología: nunca intentó llenarlas. Es una razón para no esperar que ayude con el problema actual.
Analizamos 299 archivos DESIGN.md escritos para dar pautas de diseño a los agentes, y ese vacío también aparece allí. El 76 % no contiene prohibiciones de ningún tipo. El 86 % especifica los colores como hex raw sin un rol semántico. El 57 % no define motivos distintivos. El 44 % no contiene ningún valor de tamaño concreto en ninguna parte, y el 54 % depende de al menos un adjetivo vago: "limpio" en el 39 %, "moderno" en el 36 %.
Un archivo organizado impecablemente por átomos, moléculas y organismos, pero que no contenga nada de esto, producirá una interfaz genérica bien estructurada. La taxonomía nunca fue la restricción determinante.
La trampa específica: los equipos consideran que "tener una jerarquía de componentes" es prueba de que el sistema de diseño está listo para agentes. Es prueba de una buena estructura de código. Pregunte, en cambio, si un agente que lea su sistema podría saber qué está prohibido; normalmente descubrirá que no hay nada prohibido.
Qué lo sustituye
No una nueva taxonomía. El movimiento útil es mantener la disciplina compositiva —que todo el mundo ya tiene— y añadir las capas que el diseño atómico nunca cubrió.
- 1
Mantenga la jerarquía, elimine la discusión
Primitivos, componentes, layouts. Tres niveles, decidibles al instante. Si su equipo ya está de acuerdo con átomos/moléculas/organismos y no supone un coste, manténgalo; las etiquetas no son el problema, lo es la discusión.
- 2
Defina los componentes por contrato, no por composición
Escriba los elementos obligatorios, los opcionales y las propiedades. "Una tarjeta requiere un título y un texto de apoyo; opcionalmente, una imagen, una etiqueta y una acción en el pie de página". Esa declaración sobrevive a cualquier implementación, incluida una escrita por un agente en un framework que usted no haya previsto.
- 3
Añada la capa de restricciones
La lista de cosas que nunca se hacen. Sin degradados, sin elevación de sombras, sin un peso de fuente superior a 600, sin colores fuera del conjunto de design tokens. Esta es la capa que más cambia el resultado generado y la capa que la mayoría de los sistemas no tienen.
- 4
Añada la capa de intención
Para qué sirve el diseño y quién lo lee. Una herramienta densa para personas que pasan todo el día en ella y una página de marketing que alguien escanea durante cuarenta segundos requieren decisiones opuestas, y ninguna jerarquía de componentes codifica cuál de las dos es la suya.
Vale la pena ampliar el segundo paso, porque es la parte que mejor se traslada al código escrito por agentes. Un contrato puede satisfacerse mediante cualquier implementación; un árbol de composición solo puede satisfacerse reproduciendo el árbol. Cuando el implementador es un modelo que puede recurrir a una estructura diferente a la suya, el contrato se mantiene y el árbol no.
## Card
Required: title, supporting text
Optional: image, badge, footer action
Contains its own bottom divider; hidden when last in a list.
Padding 16px. Radius 12px. Border 1px --border-subtle.
Never uses a drop shadow — elevation is a surface step.
Never uses the accent colour for its border or background.Nueve líneas, y cada una de ellas es verificable. Note cuánta parte es prohibición. Esa proporción es la diferencia entre una especificación y una descripción.
Los kits de diseño de Identity Forge están construidos como este tipo de contrato —roles de color semánticos para modo claro y oscuro, escalas de tipografía y espaciado, motivos y directrices explícitas de lo que se debe y no se debe hacer— serializados en un DESIGN.md que el agente lee antes de escribir nada. Explore los kits o comience por qué es un archivo DESIGN.md.
Entonces, ¿ha muerto el diseño atómico?
No, y ese planteamiento no es útil. El diseño atómico sostuvo que las interfaces son sistemas compuestos. Ese argumento está ahora tan plenamente aceptado que es invisible: está integrado en React, en cada herramienta de diseño, en cada sistema de diseño publicado desde entonces. No puede descartarlo, porque ya está dentro de él.
Lo que ha caducado es la idea de que la taxonomía es el entregable. Un sistema organizado en cinco niveles con nombre que no contiene restricciones, ni roles, ni una declaración de intención, es un esquema de archivo. Producirá interfaces coherentes, bien estructuradas y totalmente intercambiables, lo cual nunca fue el objetivo.
El trabajo que queda es el que el diseño atómico dejó fuera deliberadamente: decidir para qué sirve su diseño, qué se niega a hacer y escribir ambas cosas en un lugar donde la herramienta que construye su interfaz realmente lo lea.
¿Sigue siendo relevante el diseño atómico?
Su idea central es ahora la premisa por defecto en cualquier framework de componentes y sistema de diseño, así que sí, en el sentido de que ya lo está utilizando. Su taxonomía de cinco niveles es opcional, y muchos equipos obtienen más valor de una división más sencilla de primitivos/componentes/layouts que elimina las discusiones sobre los límites.
¿Cuál es la diferencia entre una molécula y un organismo?
Convencionalmente, una molécula es un grupo pequeño de átomos que funcionan como una unidad (una etiqueta más un input más un botón) y un organismo es una sección más grande y autosuficiente (un encabezado de sitio, una cuadrícula de tarjetas de producto). En la práctica, el límite no es decidible de una manera que cambie lo que alguien construye, razón por la cual los equipos discuten al respecto y muchos eliminan la distinción.
¿Debería utilizar el diseño atómico con agentes de código de IA?
No ayuda ni perjudica significativamente. Un agente ya sabe qué es un botón y qué es un encabezado, por lo que el beneficio de tener un vocabulario compartido no es aplicable. Lo que realmente modifica el resultado de un agente es la capa que el diseño atómico nunca cubrió: los roles de color semánticos, valores numéricos reales para las escalas y una lista explícita de lo que está prohibido.
¿Por qué Airbnb rechazó el diseño atómico?
El razonamiento publicado fue que componer componentes a partir de átomos compartidos crea una red complicada de partes interconectadas. Tratar cada componente como una unidad autónoma con elementos obligatorios y opcionales definidos permite que los componentes evolucionen de forma independiente, algo mucho más relevante dado que el sistema debía coexistir simultáneamente en Swift, Kotlin y código web.
¿Qué debería contener un sistema de diseño si no una taxonomía?
Contratos de componentes (elementos obligatorios, elementos opcionales, propiedades), roles de color semánticos en lugar de valores brutos, escalas de tipografía y espaciado con números reales, un modo oscuro definido, motivos que describan la función del diseño y una lista de prohibiciones explícitas. No hay problema en mantener la jerarquía; simplemente no es la parte que aporta el valor real.