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 piezas 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 se desincronizan porque nadie se dio cuenta |
Ninguna de las dos columnas es correcta en términos generales. La respuesta correcta depende del riesgo de fallo que pueda permitirse. Un producto web de una sola plataforma con un equipo pequeño puede absorber el riesgo de propagación y obtener un valor real de la reutilización. Un sistema que abarque iOS, Android, tabletas y web no puede, porque el árbol de átomos tiene que reproducirse de forma idéntica en Swift, Kotlin y en cualquier stack web que haya en ese año, y no lo hará.
La regla del divisor
Un detalle del relato sobre el DLS explica toda la filosofía mejor de lo que lo hace la propia filosofía. En lugar de que las líneas divisorias existan como elementos propios entre componentes, se requiere que cada componente contenga su propio divisor, mostrado u oculto mediante lógica de visualización.
Considere el coste de la alternativa. Si los divisores residen entre componentes, entonces el hecho de que aparezca un divisor es una propiedad de la lista, no de la fila; por tanto, la lista tiene que saber que es la última fila en cuatro plataformas y en cuatro bases de código, incluso en el caso de que una fila se oculte condicionalmente. Cada implementación de lista vuelve a implementar esa lógica y una de ellas fallará. Mueva el divisor al interior de la fila y la regla se vuelve local: una fila sabe si debe dibujar su propio borde inferior y nada de lo que esté por encima tiene que razonar sobre la posición.
La regla generalizable: cuando una propiedad visual dependa del contexto, trasládela al componente y proporcione al componente una forma de conocer su contexto. No haga que cada contenedor vuelva a implementar 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 específica, 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 nombradas
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 distinto 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 cede ante la convención de la plataforma en todas partes produce dos productos que comparten un logotipo. El DLS marca la línea en los elementos que los usuarios han aprendido del sistema operativo en lugar de 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 de retroceso/ascenso, affordance de compartir, iconos del sistema, física de 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. Sobrescribirlo les supone un coste | Los usuarios lo aprenden de usted. Divergir le supone un coste |
| Si se equivoca | La aplicación se siente sutilmente hostil y nadie sabe por qué | La aplicación parece de dos empresas distintas |
El mismo documento señala que el sistema se construyó de modo que el código, los componentes y los diseños idénticos funcionen en diversos tamaños de dispositivo, con un pequeño conjunto de reglas de diseño para gestionar la transformación a tabletas. Ese es el mismo principio aplicado a un eje diferente: mantenga una única definición y 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 requeridos, elementos opcionales y propiedades de comportamiento. Swift, Kotlin, la versión web y la librería de Sketch son cuatro renderizados de esa declaración.
Por esto el enfoque escaló entre 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 ser satisfecho reproduciendo el árbol, y en el momento en que el framework de una plataforma lo complica, alguien busca una solución alternativa y los sistemas se bifurcan.
Un contrato puede ser satisfecho por cualquier implementación. Un árbol de composición solo puede ser satisfecho reproduciendo el árbol.
También es la razón por la que el modelo se aplica a una plataforma en la que nadie estaba pensando en 2015.
El agente es otra plataforma
Cuando un agente de código escribe su interfaz, está haciendo exactamente lo 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 usted le haya entregado. Cada pregunta que el DLS tuvo que responder vuelve sin cambios.
| DLS multiplataforma | Sistema orientado al agente | |
|---|---|---|
| ¿Qué es unificado? | Contrato de componentes, 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 ser detectada por un diseñador. 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 contenido contractual poseen realmente. El 86% especificaba colores como valores hex puros 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, frecuentemente "clean" (39%) o "modern" (36%).
Un archivo así es el fracaso del atomic design en prosa. Entrega partes sin declarar para qué sirven, y cada pantalla que el agente escribe 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. Explorar 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 tratar de replicar su salida visual sería un ejercicio erróneo 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 puede transferir 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 se permite que diverjan. Todo lo demás se unifica por defecto. Un sistema sin esa lista o fuerza una paridad falsa o 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 antes de elegir los 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 está disponible son los relatos escritos del equipo de diseño sobre cómo se construyó, además de reconstrucciones de terceros en Figma 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 es mucho más importante cuando el mismo sistema debe existir en Swift, Kotlin y código web.
¿Es erróneo, 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 del error que puedas 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 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 la salida diverge entre pantallas.