Airbnb's DLS: the system that refused atomic design

In the design team's own published account of the DLS, the founding structural choice is stated directly: instead of relying on individual atoms, they considered components as elements of a living organism — each with a function and a personality, defined by a set of properties, able to coexist with others and to evolve or die independently. The stated benefit is the absence of a complicated network of interconnected parts.

That is a rejection of atomic design, made by a team that had the resources to implement atomic design properly and chose not to. It is worth taking seriously rather than treating as a stylistic preference, because the reasoning generalises.

Neither column is correct in general. The right answer depends on which failure mode you can afford. A single-platform web product with a small team can absorb the propagation risk and gets real value from the reuse. A system spanning iOS, Android, tablet and web cannot, because the atom tree has to be reproduced identically in Swift, Kotlin, and whatever the web stack is that year — and it will not be.

One detail from the DLS account explains the whole philosophy better than the philosophy does. Rather than having divider lines exist as their own elements between components, each component is required to contain its own divider, shown or hidden by view logic.

Consider what the alternative costs. If dividers live between components, then whether a divider appears is a property of the list, not the row — so the list has to know it is the last row, on four platforms, in four codebases, including in the case where a row is conditionally hidden. Every list implementation reimplements that logic and one of them gets it wrong. Move the divider inside the row and the rule becomes local: a row knows whether it draws its own bottom edge, and nothing above it has to reason about position.

The same document notes that the elements defining each component were declared in both the Sketch file and the code. That is the other half of the contract: a component is not defined by its rendering on any one platform, but by the list of things it must contain. Sketch and Swift are two implementations of the same declaration.

The DLS is described as mostly platform-agnostic — most components look and work the same on iOS and Android — while deliberately following native conventions on a short list of things: navigation, system iconography, contextual actions, and interactions. The Android navigation bar differs from the iOS one and uses a different icon, by design.

The short list is the interesting part. A system that tries for total parity produces an app that feels foreign on both platforms; a system that defers to platform convention everywhere produces two products that share a logo. The DLS draws the line at the elements users have learned from the operating system rather than from your product. Back navigation is an OS convention. A pricing row is not.

The same document notes the system was built so identical code, components and designs work across device sizes, with a small set of layout rules handling the tablet transformation. That is the same principle applied to a different axis: keep one definition, add rules for the axis that genuinely varies.

The thread running through all of this is that the DLS's unit of truth is a declaration, not an implementation. A component is a name plus a list of required elements, optional elements, and behavioural properties. Swift, Kotlin, the web build and the Sketch library are four renderings of that declaration.

This is why the approach scaled across platforms while an atom-tree approach would not have. A contract can be satisfied by any implementation. A composition tree can only be satisfied by reproducing the tree, and the moment one platform's framework makes that awkward, someone works around it and the systems fork.

It is also why the model applies to a platform nobody was thinking about in 2015.

When a coding agent writes your interface, it is doing exactly what the iOS team did: rendering your system in an environment with its own idioms and constraints, from whatever definition you handed it. Every question the DLS had to answer comes back unchanged.

The last row is the practical difference, and it is the reason this matters more now than it did then. A cross-platform drift takes a release cycle to appear and a designer notices. Agent drift appears within one session, between two files, and nobody notices until the third screen.

We sampled 299 DESIGN.md files published for AI agents to read, to see how much of a contract they actually contain. 86% specified colours as raw hex values with no role attached — a value list, not a contract. 76% contained no prohibitions of any kind. 44% contained no concrete size value anywhere, and 54% leaned on at least one vague adjective, most often "clean" (39%) or "modern" (36%).

A file like that is the atomic-design failure in prose form. It hands over parts with no statement of what they are for, and every screen the agent writes reassembles them differently. What the DLS would have written instead is a declaration: this component requires these elements, this colour has this role, this is not allowed.

## 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.

That is thirty seconds of writing, and it is the difference between an agent that produces the same card on screen fourteen and one that invents a new one.

The DLS is not available to install, and chasing its visual output would be the wrong exercise anyway — it was designed for a travel marketplace with photography as the primary content, which is a specific problem most products do not have.

What transfers is three decisions, all of which cost nothing to adopt:

1. Define components by contract, not composition. Write down required elements, optional elements and properties. Let the implementation be whatever each target needs.
2. Push context-dependent visuals into the component. The divider rule, generalised. If a container has to know something about its children to render them correctly, you have put the logic in the wrong place.
3. Name the short list of things that are allowed to diverge. Everything else is unified by default. A system without that list either forces false parity or drifts everywhere.

None of those require a design systems team, a Sketch library, or four platforms. They require deciding what your components are, which is the work most systems skip on the way to picking colours.