Encore: Wie ein Designsystem bei 45 Plattformen aussieht

Im Jahr 2019 setzte die Spotify-Leitung sich das Ziel, Audio auf jedem Gerät konsistent verfügbar zu machen. Die vom Design-Team veröffentlichten Zahlen sind beeindruckend: 45 einzigartige Plattformen und über 2.000 Gerätetypen über 200 Marken hinweg. Jemand startet eine Playlist auf einem Wohnzimmer-Fernseher, setzt sie im Auto fort und greift am nächsten Morgen per Laptop darauf zu.

Das ist nicht einfach eine größere Version des üblichen Designsystem-Problems. Es ist ein anderes Problem. Ein Fernseher wird aus drei Metern Entfernung betrachtet, eine Uhr muss alles kondensieren, ein Desktop hat reichlich Platz und ein Auto hat rechtliche Einschränkungen bei der Interaktion. Keine einzelne Komponenten-Bibliothek kann all das bedienen, und keine Menge an Dokumentation kann dies erzwingen.

Encore startete mit zwei Segmenten. Encore Consumer Mobile wurde als unglaublich flexibel beschrieben – ein riesiger Katalog stetig wachsender Komponenten für mobile Erlebnisse. Encore Web bediente eine breitere Palette von Webprodukten. Unter beiden lagen Design-Tokens, die grundlegende Entscheidungen wie Farbschemata und Typografie-Styles abdeckten.

Das veröffentlichte Modell ist konzentrisch. Das Fundament liegt im Zentrum. Web und Mobile liegen darüber als gleichberechtigte Subsysteme mit Plattform-Parität. Weiter außen liegen die spezialisierteren Subsysteme – Content Web Platform, Advertising Web, Consumer Mobile –, die jeweils stärker vom Kern abweichen.

Der Wert dieser Struktur liegt darin, dass Divergenz begrenzt und lokalisiert ist. Eine Komponente, die nur für Werbung benötigt wird, lebt im Advertising-Ring und kann nicht in die Consumer-App einsickern. Eine Farbentscheidung lebt im Fundament, wo sie nicht lokal überschrieben werden kann. Die Alternative – eine flache Bibliothek für alle – zwingt jeden spezialisierten Bedarf entweder dazu, in den Kern absorbiert zu werden (was diesen aufbläht), oder außerhalb des Systems gebaut zu werden – und genau dort sterben Designsysteme.

Hier kommt der Teil, der in veröffentlichten Texten über Designsysteme selten vorkommt, weil es ein Eingeständnis ist. Bis 2022 kam das Team zu dem Schluss, dass das Pendel zu weit in Richtung Flexibilität ausgeschlagen war und eine Neukalibrierung notwendig sei.

Was passiert war erkennbar: Consumer Mobile war bewusst flexibel gestaltet, sodass die Produktteams immer mehr verfeinerte Komponenten anforderten – und Consumer Mobile stimmte immer wieder zu. Flexibilität, die als Feature beginnt, wird zur Verpflichtung: Das spezifische Bedürfnis jedes Teams wird zu einer weiteren Komponente, die das System verwalten muss, und der Katalog wächst schneller, als man ihn konsistent halten kann.

Die Korrektur von Spotify ist der interessante Teil. Sie haben Consumer Mobile nicht eingeschränkt oder begonnen, Anfragen abzulehnen. Stattdessen stellten sie ein Team zusammen, um wiederverwendbare Komponenten für Encore Mobile zu entwickeln – und fügten so eine neue Ebene zwischen Consumer Mobile und dem Foundation-Layer ein. Die veröffentlichte Beschreibung des Zwecks ist präzise: Diese Ebene fungiert als erste Verteidigungslinie, reduziert die Anforderungen an Consumer Mobile, jede Komponente selbst bereitstellen zu müssen, und schafft gleichzeitig eine größere Plattform-Parität im restlichen System.

Das definiert ein Governance-Problem als ein strukturelles Problem um. Wenn ein Subsystem Anfragen bearbeitet, die eigentlich nicht spezifisch für es sind, dann sind nicht die Anfragen das Problem, sondern die fehlende gemeinsame Ebene. Ein „Nein“ hätte die Teams dazu getrieben, außerhalb des Systems zu entwickeln. Durch das Hinzufügen der Ebene wurde die Arbeit im System gehalten.

Die Schilderung des Arbeitsprozesses durch das Team ist konkret genug, um sie zu kopieren. Die entscheidende Änderung, die sie nennen, ist, dass plattformübergreifende Komponenten nun von Anfang an als solche konzipiert werden und nicht erst im Nachhinein.

1. 1

   Alle Plattformen an einen Tisch holen

   Vertreter von iOS, Android und Web kommen zusammen, bevor irgendetwas entworfen wird. Ihr Argument, warum dies notwendig ist, ist stichhaltig: Es ist selten, jemanden zu finden, der sowohl Experte für Web als auch für Mobile ist. Daher muss die Expertise zusammengeführt werden, anstatt sie vorauszusetzen.

2. 2

   Jede Plattform prüft und skizziert, was für ihre Oberfläche einzigartig ist

   Der Desktop bietet mehr Platz. Fernseher sind aufgrund des Betrachtungsabstands anders. Eine Uhr erfordert, dass alle Informationen kondensiert werden. Diese Punkte werden als Fakten über die Oberfläche festgehalten, bevor über die Komponente diskutiert wird.

3. 3

   Einigung über Begriffe, Zustände und Eigenschaftsinteraktionen

   Die Arbeitsgruppe definiert, wie Dinge benannt werden, welche Zustände existieren und wie Eigenschaften kombiniert werden. Dies ist der Schritt, der oft übersprungen wird – und genau deshalb landen zwei Plattformen am Ende bei einer Komponente, die zwar denselben Namen teilt, aber sonst nichts.

4. 4

   Die Komponente gegen all diese Anforderungen gleichzeitig entwerfen

   Nicht die Version einer Plattform plus Anpassungen. Sondern eine Komponente, deren Varianten bereits bekannt waren, bevor sie gezeichnet wurde.

Schritt drei ist es wert, übernommen zu werden, unabhängig davon, wie viele Plattformen man betreut. Die meisten Fälle von Component Drift beginnen als Vocabulary Drift: Das „Secondary“ des einen Teams ist das „Ghost“ des anderen, der Disabled-Zustand des einen ist das Read-only des anderen – und bis es jemand bemerkt, sind beide bereits live.

Wer nach dem Designsystem von Spotify sucht, findet als eines der ersten Ergebnisse die öffentlichen Design & Branding Guidelines auf der Entwicklerseite. Hier muss klar unterschieden werden: Das ist nicht Encore und auch kein Designsystem im herkömmlichen Sinne. Es ist ein Compliance-Dokument.

Die Struktur verrät es: Urheberkennzeichnung, Nutzung von Spotify-Inhalten, Durchsuchen von Inhalten, Verlinkung zu Spotify, Wiedergabeansichten, Anzeige von Entitäten, Nutzung des Logos, Nutzung der Farben, Logo- und Namensbeschränkungen, Schriftarten. Der angegebene Grund für die Regeln zur Urheberkennzeichnung ist, dass die über Spotify verfügbaren Inhalte vielen verschiedenen Rechteinhabern gehören. Daher muss jede Verwendung von Spotify-Metadaten – Künstler-, Album- und Titelnamen, Artwork, Audiowiedergabe – von der Spotify-Marke begleitet werden. Die Seite stellt klar, dass die Nutzung dieser Ressourcen die Annahme der Developer Terms of Service bedeutet.

Diese Unterscheidung ist wichtig, wenn man etwas baut, das Inhalte oder Marken Dritter integriert. Diese Regeln sind vertraglich bindend, und „ohne das Logo sah es besser aus“ ist keine gültige Rechtfertigung. Es ist auch als Kategorie wichtig: Wenn Ihr Produkt von Produkten anderer Personen konsumiert wird, benötigen Sie möglicherweise sowohl ein solches Dokument als auch ein Designsystem – und das sind zwei völlig unterschiedliche Schreibaufgaben.

Das konzentrische Modell lässt sich direkt auf Design-Richtlinien übertragen, die für AI Coding-Agents geschrieben werden. Es löst ein Problem, das auftritt, sobald ein Projekt mehr als eine Art von Oberfläche besitzt.

Ein typischer Fehler ist eine einzelne DESIGN.md, die versucht, eine Marketing-Website, einen Application Shell und eine dichte Datentabelle abzudecken. Ihre Regeln enden in Ausflüchten – „großzügiges Spacing, obwohl Tabellen dichter sein können“ – und eine vage Regel ist keine Regel. Das Modell muss entscheiden, und es entscheidet jedes Mal anders.

Die Schichtung funktioniert genau wie bei Encore:

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

Jede Datei ist innerhalb ihres Bereichs eindeutig definiert. Die Root-Datei enthält nur das, was sich wirklich nicht ändern darf – Farbroles, Typografie-Familien, Verbote – und die Leaf-Dateien enthalten die Entscheidungen, die legitim variieren dürfen. Ein Agent, der in app/dashboard/ arbeitet, liest zwei Dateien und erhält eine einzige, eindeutige Antwort anstatt einer Datei mit Vorbehalten.

Wir haben 299 DESIGN.md-Dateien stichprobenartig untersucht, die für das Lesen durch Agenten veröffentlicht wurden. 44 % enthielten nirgendwo einen konkreten Größenwert und 54 % stützten sich auf mindestens ein vages Adjektiv – „clean“ in 39 %, „modern“ in 36 %. Das ist das Problem der Unverbindlichkeit in Extremform: Eine Datei, die sich nie auf einen Wert festlegt, kann nicht mit sich selbst in Konflikt geraten, kann aber auch keine konsistente Schnittstelle erzeugen.

Sie haben wahrscheinlich keine 45 Plattformen. Sie haben vielleicht drei Oberflächen, von denen zwei sich stillschweigend auseinanderentwickelt haben, und ein Team, das ständig nach einer Komponente fragt, die sonst niemand braucht. Das ist dasselbe Problem mit geringerer Amplitude, und die Lösungen von Encore lassen sich auch in diesem Maßstab anwenden.

Packen Sie das, was sich nicht ändern darf, in ein Fundament und machen Sie es wirklich unumstößlich. Lassen Sie spezialisierte Anforderungen in spezialisierten Ebenen existieren, anstatt sie in den Kern oder ganz aus dem System zu drängen. Wenn eine Ebene in Anfragen versinkt, suchen Sie nach der fehlenden Ebene darunter, bevor Sie mit Ablehnungen beginnen. Und entwerfen Sie für jede Oberfläche gleichzeitig, denn eine Komponente, die nachträglich angepasst wird, ist eine Komponente, die divergieren wird.