Encore: what a design system looks like at 45 platforms

In 2019 Spotify's leadership set out to make audio available and consistent on any device. The number the design team has published is stark: 45 unique platforms and over 2,000 types of device across 200 brands. Someone starts a playlist on a living-room television, continues it in a car, and picks it up on a laptop the next morning.

That is not a bigger version of the usual design system problem. It is a different problem. A television is viewed from three metres, a watch has to condense everything, a desktop has real estate to spend, and a car has legal constraints on interaction. No single component library can serve all of those, and no amount of documentation makes one do so.

Encore launched with two segments. Encore Consumer Mobile was described as incredibly flexible, a vast catalogue of ever-growing components for mobile-centric experiences. Encore Web served a broader range of web products. Underneath both sat design tokens covering foundational decisions like colour schemes and type styles.

The published model is concentric. The foundation is at the centre. Web and Mobile sit above it as peer subsystems with platform parity. Further out sit the more specialised subsystems — Content Web Platform, Advertising Web, Consumer Mobile — each increasingly divergent from the core.

The value of the shape is that divergence is bounded and located. A component that only advertising needs lives in the advertising ring, where it cannot leak into the consumer app. A colour decision lives in the foundation, where it cannot be locally overridden. The alternative — one flat library serving everyone — forces every specialised need either to be absorbed into the core, bloating it, or to be built outside the system, which is where design systems go to die.

Here is the part that is rare in published design-system writing, because it is an admission. By 2022, the team judged that the pendulum had swung too far toward flexibility, and that a recalibration was necessary.

What had happened is recognisable. Consumer Mobile was deliberately flexible, so product teams asked it for more and more refined components, and it kept saying yes. Flexibility that starts as a feature becomes an obligation: every team's specific need becomes another component the system owns, and the catalogue grows faster than anyone can keep coherent.

Spotify's correction is the interesting move. They did not tighten Consumer Mobile or start rejecting requests. They assembled a team to build reusable components for Encore Mobile — inserting a new layer between Consumer Mobile and the foundation. The published description of its purpose is precise: it acts as a first line of defence, reducing the demand on Consumer Mobile to provide every component itself, while creating greater platform parity across the rest of the system.

That reframes a governance problem as a structural one. When a subsystem is fielding requests that are not really specific to it, the requests are not the problem — the missing shared layer is. Saying no would have pushed those teams to build outside the system. Adding the layer captured the work.

The team's account of the working process is concrete enough to copy, and the crucial change they name is that cross-platform components are now designed as cross-platform from the outset rather than as an afterthought.

1. 1

   Get every platform in the room

   iOS, Android and Web representatives together, before anything is designed. Their point about why this is necessary is well made: it is rare to find someone expert in both web and mobile, so the expertise has to be assembled rather than assumed.

2. 2

   Each platform audits and diagrams what is unique to its surface

   Desktop has more real estate. Television is different because of viewing distance. A watch requires all the information to be condensed. These are stated as facts about the surface before anyone argues about the component.

3. 3

   Align on terms, states and property interaction

   The working group defines what things are called, which states exist, and how properties combine. This is the step that gets skipped, and skipping it is why two platforms end up with a component that shares a name and nothing else.

4. 4

   Design the component against all of it at once

   Not one platform's version plus adaptations. One component whose variants were known before it was drawn.

Step three is the one worth stealing regardless of how many platforms you have. Most component drift is vocabulary drift first: one team's "secondary" is another team's "ghost", one team's disabled state is another's read-only, and by the time anyone notices, both are shipped.

Search for Spotify's design system and one of the first things you find is Spotify's public Design & Branding Guidelines on the developer site. It is worth being clear that this is not Encore and not a design system in the usual sense. It is a compliance document.

Its structure gives it away: attribution, using Spotify content, browsing content, linking to Spotify, playing views, showing entities, using the logo, using the colours, logo and naming restrictions, fonts. The stated reason for the attribution rules is that content available through Spotify is owned by many different rights holders, so any use of Spotify metadata — artist, album and track names, artwork, audio playback — must be accompanied by the Spotify brand. The page states that using the resources means accepting the Developer Terms of Service.

The distinction matters if you are building anything that integrates a third party's content or brand. Those rules are contractual, and "it looked better without the logo" is not a defence. It also matters as a category: if your product is consumed by other people's products, you may need this document as well as a design system, and they are not the same writing job.

The concentric model transfers directly to design guidance written for AI coding agents, and it solves a problem that shows up as soon as a project has more than one kind of surface.

The usual failure is a single DESIGN.md that tries to cover a marketing site, an application shell and a dense data table. Its rules end up hedged — "generous spacing, though tables may be denser" — and a hedged rule is not a rule. The model has to decide, and it decides differently each time.

Layering it works the same way Encore does:

# DESIGN.md          <- foundation: tokens, roles, prohibitions
                        applies everywhere, never overridden

# app/marketing/DESIGN.md
   Extends the root. Spacing scale shifted up one step.
   Hero type may use the display scale (48px+).
   Cards may use shadow elevation.

# app/dashboard/DESIGN.md
   Extends the root. Compact spacing (8-12px controls).
   Elevation is surface steps + hairline, never shadow.
   Table rows: 32px, no vertical padding above 8px.

Each file is unhedged within its scope. The root holds only what genuinely must not vary — colour roles, type family, prohibitions — and the leaves hold the decisions that legitimately differ. An agent working in app/dashboard/ reads two files and gets a single unambiguous answer instead of one file with a caveat in it.

We sampled 299 DESIGN.md files published for agents to read. 44% contained no concrete size value anywhere and 54% relied on at least one vague adjective — "clean" in 39%, "modern" in 36%. That is the hedging problem at its extreme: a file that never commits to a number cannot conflict with itself, and also cannot produce a consistent interface.

You probably do not have 45 platforms. You may well have three surfaces, two of which have quietly diverged, and one team that keeps asking for a component nobody else wants. That is the same problem at a smaller amplitude, and Encore's answers hold at that size.

Put what must not vary in a foundation and make it genuinely un-overridable. Let specialised needs live in specialised layers rather than forcing them into the core or out of the system entirely. When one layer is drowning in requests, look for the missing layer beneath it before you start refusing. And design for every surface at the same time, because a component adapted afterwards is a component that will diverge.