As Airbnb grew from a small product into a company with web, iOS, and Android apps each maintained by different teams, a familiar drift set in: buttons that looked slightly different depending on which screen you were on, spacing that varied between features, and the same UI pattern reimplemented from scratch by different engineers who didn't know an existing version already existed elsewhere. None of this was any one person's mistake — it's the predictable outcome of many teams building UI independently without a shared, enforced vocabulary for what components should look like and how they should behave.

Design and engineering converging on shared language

Airbnb's response, most visibly its Design Language System (DLS) work introduced publicly around 2016, treated the problem as both a design and an engineering problem simultaneously, not one team's responsibility handed off to the other. Designers and engineers collaborated on a shared set of principles and primitives — typography scales, color tokens, spacing units, core components like buttons and form inputs — that were then implemented once as reusable code across platforms, rather than each platform team independently interpreting the same design spec and inevitably drifting from each other over time.

Cross-platform consistency without cross-platform code

A particularly hard part of this problem for Airbnb was that web, iOS, and Android are fundamentally different rendering environments with their own idioms and constraints, so a literal shared codebase for UI wasn't straightforward. Airbnb's approach centered the design tokens and specifications as the actual source of truth, implemented natively per platform, so a button looked and behaved consistently to a user moving between the iOS app and the website, even though the underlying code wasn't shared line for line. This meant the "single source of truth" lived in the design language and its documented specification, not necessarily in a single shared repository — a distinction that mattered because forcing literal code sharing across such different platforms would have fought each platform's native strengths.

Making the system easier to use than to bypass

A design system only works if using it is genuinely easier than not using it — if building a one-off custom component is faster than finding and correctly using the shared one, teams will keep reinventing UI regardless of how well-documented the system is. Airbnb invested in tooling and documentation that made discovering and adopting existing components the path of least resistance, and treated the system as a living product with its own roadmap and maintainers, rather than a one-time style guide published once and left to go stale as the product evolved around it.

What you can borrow

  • Visual inconsistency across a growing product is usually a symptom of missing shared vocabulary between teams, not a lack of individual skill — fixing it requires a shared system, not more design reviews.
  • A design system's tokens and specifications can be the actual source of truth even when the implementing code isn't shared across platforms with fundamentally different rendering models.
  • A shared component library only gets adopted if using it is easier than bypassing it — invest as much in discoverability and documentation as in the components themselves.
  • Treat a design system as a maintained product with an owner and a roadmap, not a static style guide, or it will drift out of sync with the product it's meant to serve.