Análisis independiente basado en relatos publicados públicamente por el equipo de diseño de Airbnb, escrito para personas que están construyendo sus propios sistemas. Identity Forge no está afiliado ni respaldado por Airbnb. Airbnb y su logotipo son marcas comerciales de su propietario.
La decisión que todo el mundo ignora
En el relato publicado por el equipo de diseño sobre el DLS, la elección estructural fundacional se expone directamente: en lugar de depender de átomos individuales, consideraron los componentes como elementos de un organismo vivo; cada uno con una función y una personalidad, definidos por un conjunto de propiedades, capaces de coexistir con otros y de evolucionar o morir independientemente. El beneficio declarado es la ausencia de una red complicada de partes interconectadas.
Se trata de un rechazo al diseño atómico realizado por un equipo que tenía los recursos para implementarlo correctamente y decidió no hacerlo. Vale la pena tomarlo en serio en lugar de tratarlo como una preferencia estilística, ya que el razonamiento es generalizable.
| Composición atómica | Organismo autónomo | |
|---|---|---|
| Un componente es | Un ensamblaje de componentes más pequeños compartidos | Una unidad con elementos obligatorios y opcionales declarados |
| Cambiar un botón compartido | Se propaga a todas partes, incluso en lugares que nadie revisó | Cambia el botón. Cada componente es dueño de su propia presentación |
| Reutilización | Máxima; ese es el objetivo | Deliberada, a nivel de componente |
| Duplicación | Mínima | Alguna, aceptada como el precio de la independencia |
| Multiplataforma | Difícil. El árbol de átomos debe existir idénticamente en cada plataforma | Más fácil. Solo el contrato debe coincidir |
| Modo de fallo | Un cambio rompe cuatro superficies silenciosamente | Dos componentes divergen porque nadie lo notó |
En general, ninguna de las dos columnas es correcta. La respuesta adecuada depende de qué modo de fallo pueda permitirse. Un producto web de plataforma única con un equipo pequeño puede absorber el riesgo de propagación y obtener un valor real de la reutilización. Un sistema que abarca iOS, Android, tablet y web no puede, porque el árbol de átomos tendría que reproducirse idénticamente en Swift, Kotlin y cualquier que sea el stack web de ese año; y no ocurrirá.
La regla del divisor
Un detalle del relato del DLS explica toda la filosofía mejor que la propia filosofía. En lugar de que las líneas divisorias existan como elementos independientes entre componentes, se requiere que cada componente contenga su propio divisor, mostrado u oculto mediante la lógica de la vista.
Considere el coste de la alternativa. Si los divisores viven entre componentes, entonces el hecho de que aparezca un divisor es una propiedad de la lista, no de la fila; por lo tanto, la lista debe saber que se trata de la última fila, en cuatro plataformas, en cuatro bases de código, incluso en el caso de que una fila esté oculta condicionalmente. Cada implementación de la lista reimplementa esa lógica y alguna de ellas comete un error. Mueva el divisor dentro de la fila y la regla pasa a ser local: una fila sabe si debe dibujar su propio borde inferior, y nada por encima de ella tiene que razonar sobre la posición.
La regla generalizable: cuando una propiedad visual depende del contexto, desplácela hacia el componente y proporcione al componente una forma de recibir información sobre su contexto. No haga que cada contenedor reimplemente la misma condicional. Esta es una de las pocas decisiones de un sistema de diseño que casi siempre es correcta.
El mismo documento señala que los elementos que definen cada componente se declararon tanto en el archivo de Sketch como en el código. Esa es la otra mitad del contrato: un componente no se define por su renderizado en una plataforma concreta, sino por la lista de elementos que debe contener. Sketch y Swift son dos implementaciones de la misma declaración.
Agnóstico a la plataforma, con excepciones nominales
El DLS se describe como mayoritariamente agnóstico a la plataforma —la mayoría de los componentes se ven y funcionan igual en iOS y Android— mientras sigue deliberadamente las convenciones nativas en una lista corta de elementos: navegación, iconografía del sistema, acciones contextuales e interacciones. La barra de navegación de Android difiere de la de iOS y utiliza un icono diferente, por diseño.
La lista corta es la parte interesante. Un sistema que busca la paridad total produce una aplicación que se siente ajena en ambas plataformas; un sistema que se remite a la convención de la plataforma en todo momento produce dos productos que solo comparten un logotipo. El DLS traza la línea en los elementos que los usuarios han aprendido del sistema operativo en lugar de su producto. La navegación hacia atrás es una convención del SO. Una fila de precios no lo es.
| Pertenece a la plataforma | Pertenece a su sistema | |
|---|---|---|
| Ejemplos | Navegación atrás/arriba, affordance de compartir, iconos del sistema, física del scroll, menús contextuales, comportamiento del teclado | Roles de color, escala tipográfica, espaciado, composición de componentes, estructura de contenido, personalidad del movimiento |
| Por qué | Los usuarios lo aprendieron del SO, no de usted. Anularlo les supone un coste | Los usuarios lo aprenden de usted. Divergir le supone un coste a usted |
| Si se equivoca | La aplicación se siente sutilmente hostil y nadie sabe decir por qué | La aplicación parece hecha por dos empresas diferentes |
El mismo documento señala que el sistema se construyó para que el código, los componentes y los diseños idénticos funcionen en diferentes tamaños de dispositivo, con un pequeño conjunto de reglas de diseño que gestionan la transformación a tablet. Es el mismo principio aplicado a un eje diferente: mantenga una definición, añada reglas para el eje que realmente varía.
Por qué un contrato sobrevive a la traducción
El hilo conductor de todo esto es que la unidad de verdad del DLS es una declaración, no una implementación. Un componente es un nombre más una lista de elementos obligatorios, elementos opcionales y propiedades de comportamiento. Swift, Kotlin, la compilación web y la librería de Sketch son cuatro renderizados de esa declaración.
Es por esto que el enfoque escaló a través de las plataformas mientras que un enfoque de árbol de átomos no lo habría hecho. Un contrato puede ser satisfecho por cualquier implementación. Un árbol de composición solo puede satisfacerse reproduciendo el árbol, y en el momento en que el framework de una plataforma hace que eso sea engorroso, alguien busca una alternativa y los sistemas se bifurcan.
Un contrato puede ser satisfecho por cualquier implementación. Un árbol de composición solo puede satisfacerse reproduciendo el árbol.
También es la razón por la cual el modelo se aplica a una plataforma en la que nadie pensaba en 2015.
El agente es otra plataforma
Cuando un agente de código escribe su interfaz, está haciendo exactamente lo mismo que hizo el equipo de iOS: renderizar su sistema en un entorno con sus propios modismos y restricciones, a partir de cualquier definición que se le haya entregado. Cada pregunta que el DLS tuvo que responder vuelve a surgir sin cambios.
| DLS multiplataforma | Sistema orientado a agentes | |
|---|---|---|
| ¿Qué está unificado? | Contrato del componente, tokens, estructura | Roles de color, escala tipográfica, espaciado, prohibiciones, motivos |
| ¿Qué es específico de la plataforma? | Navegación, iconos del sistema, acciones contextuales | Framework, librería de componentes, disposición de archivos, sintaxis de clases |
| Dónde reside la definición | Librería de Sketch más código, sincronizada por un equipo | Un archivo en el repositorio que el agente lee |
| Cómo se manifiesta la divergencia | Dos aplicaciones que parecen de empresas distintas | Dos pantallas en la misma aplicación que parecen de empresas distintas |
La última fila es la diferencia práctica, y es la razón por la que esto importa más ahora que entonces. Una deriva multiplataforma tarda un ciclo de lanzamiento en aparecer y un diseñador lo nota. La deriva de un agente aparece en una sola sesión, entre dos archivos, y nadie lo nota hasta la tercera pantalla.
Analizamos 299 archivos DESIGN.md publicados para que los agentes de IA los lean, para ver cuánto contienen realmente en términos de contrato. El 86% especificaba colores como valores hex brutos sin un rol asignado: una lista de valores, no un contrato. El 76% no contenía prohibiciones de ningún tipo. El 44% no contenía ningún valor de tamaño concreto en ninguna parte, y el 54% dependía de al menos un adjetivo vago, con mayor frecuencia "clean" (39%) o "modern" (36%).
Un archivo como ese es el fracaso del atomic design en prosa. Entrega partes sin declarar para qué sirven, y cada pantalla que escribe el agente las reensambla de forma distinta. Lo que el DLS habría escrito en su lugar es una declaración: este componente requiere estos elementos, este color tiene este rol, esto no está permitido.
## 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.Eso son treinta segundos de escritura, y es la diferencia entre un agente que produce la misma tarjeta en la pantalla catorce y uno que inventa una nueva.
Los kits de diseño de Identity Forge se construyen como este tipo de contrato —roles de color semánticos, una lista explícita de lo que se debe y no se debe hacer, motivos y reglas de diseño— y se serializan en un DESIGN.md que cualquier agente de código puede leer. Explora los kits o empieza con qué es un archivo DESIGN.md.
Qué merece la pena copiar y qué no
El DLS no está disponible para su instalación, y buscar su resultado visual sería el ejercicio equivocado de todos modos: fue diseñado para un marketplace de viajes con la fotografía como contenido principal, un problema específico que la mayoría de los productos no tienen.
Lo que se transfiere son tres decisiones, todas ellas de adopción gratuita:
- Define los componentes mediante un contrato, no mediante la composición. Escribe los elementos requeridos, los elementos opcionales y las propiedades. Deja que la implementación sea la que cada destino necesite.
- Traslada los elementos visuales dependientes del contexto al componente. La regla del divisor, generalizada. Si un contenedor tiene que saber algo sobre sus hijos para renderizarlos correctamente, has colocado la lógica en el lugar equivocado.
- Nombra la lista corta de cosas que tienen permitido divergir. Todo lo demás se unifica por defecto. Un sistema sin esa lista o bien impone una paridad falsa o bien deriva por todas partes.
Ninguna de estas requiere un equipo de sistemas de diseño, una librería de Sketch o cuatro plataformas. Requieren decidir qué son tus componentes, que es el trabajo que la mayoría de los sistemas omiten en su camino hacia la elección de colores.
¿Puedo descargar o instalar el sistema de diseño de Airbnb?
No. El DLS no se publica como un paquete instalable ni como un sitio de documentación pública. Lo que hay disponible son los relatos escritos del equipo de diseño sobre cómo se construyó, además de reconstrucciones de Figma de terceros que son la interpretación de una persona en lugar de una especificación.
¿Por qué rechazó Airbnb el atomic design?
Su razonamiento publicado fue que tratar los componentes como ensamblajes de átomos compartidos crea una red complicada de partes interconectadas. Tratar cada componente como una unidad autónoma con elementos requeridos y opcionales definidos permite que los componentes evolucionen o se retiren de forma independiente, lo cual importa mucho más cuando el mismo sistema debe existir en Swift, Kotlin y código web.
¿Es incorrecto, entonces, el atomic design?
No, es un compromiso distinto. La composición atómica minimiza la duplicación y es adecuada para un producto de una sola plataforma con una única base de código. Te cuesta riesgo de propagación y fidelidad multiplataforma. Airbnb tenía cuatro plataformas y eligió el otro lado. Elige en función de qué fallo puedes absorber.
¿Qué debe permanecer igual en todas las plataformas y qué debe diferir?
Mantén tus roles de color, escala tipográfica, espaciado, contratos de componentes y estructura de contenido idénticos en todas partes. Deja que la plataforma decida sobre las cosas que los usuarios aprenden del sistema operativo en lugar de de ti: navegación hacia atrás, iconografía del sistema, opciones de compartir, menús contextuales, comportamiento de scroll y de teclado.
¿Cómo se aplica esto a los agentes de código de IA?
Un agente es otra plataforma que renderiza tu sistema en un lenguaje desconocido. Necesita lo mismo que necesitaba un equipo nativo: un contrato que establezca qué requiere cada componente, para qué sirve cada color y qué está prohibido. La mayoría de las guías de diseño escritas para agentes son, en cambio, una lista de valores, razón por la cual el resultado diverge entre pantallas.