Encore: Wie ein Designsystem bei 45 Plattformen aussieht

Im Jahr 2019 setzte die Spotify-Führung sich das Ziel, Audio auf jedem Gerät konsistent verfügbar zu machen. Die vom Designteam 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 ein breiteres Spektrum an 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 befinden sich die spezialisierteren Subsysteme (Content Web Platform, Advertising Web, Consumer Mobile), die sich jeweils stärker vom Kern entfernen.

Der Wert dieser Struktur liegt darin, dass Divergenz begrenzt und lokalisiert ist. Eine Komponente, die nur für Advertising benötigt wird, lebt im Advertising-Ring und kann nicht in die Consumer App einsickern. Eine Farbentscheidung lebt in der Foundation, 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 folgt ein Teil, der in veröffentlichten Texten über Designsysteme selten ist, da es ein Eingeständnis darstellt. 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, weshalb die Produktteams immer mehr verfeinerte Komponenten anforderten – und man sagte stets ja. 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 Schritt. 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: Sie fügten 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, die den Druck auf Consumer Mobile reduziert, jede Komponente selbst bereitstellen zu müssen, während gleichzeitig eine größere Plattform-Parität im restlichen System geschaffen wird.

Das definiert ein Governance-Problem als ein strukturelles Problem um. Wenn ein Subsystem Anfragen bearbeitet, die eigentlich nicht spezifisch für es sind, liegen die Anfragen nicht an sich nicht vor. Das Problem ist die fehlende gemeinsame Ebene. Ein „Nein“ hätte die Teams dazu getrieben, außerhalb des Systems zu bauen. Das Hinzufügen der Ebene hat diese Arbeit hingegen integriert.

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, noch bevor etwas 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, aber sonst nichts gemeinsam hat.

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 meiste Component Drift ist zuerst ein Vokabular-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. Es ist wichtig, klarzustellen, dass dies nicht Encore und auch kein Designsystem im üblichen Sinne ist. 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 Urheberregeln 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.

Die Unterscheidung ist wichtig, wenn man etwas baut, das Inhalte oder Marken Dritter integriert. Diese Regeln sind vertraglich bindend, und „es sah ohne das Logo 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.

Das übliche Versagen ist eine einzelne DESIGN.md, die versucht, eine Marketing-Seite, ein Application-Shell und eine datenintensive Tabelle abzudecken. Die Regeln enden in vagen Formulierungen („großzügige Abstände, wobei Tabellen dichter sein können“), und eine vage Regel ist keine Regel. Das Modell muss eine Entscheidung treffen, und es entscheidet jedes Mal anders.

Die Schichtung funktioniert nach demselben Prinzip 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 Geltungsbereichs eindeutig. Die Root-Ebene enthält nur das, was sich wirklich nicht ändern darf (Farbrollen, Schriftfamilie, Verbote), und die Leaf-Ebene enthält die Entscheidungen, die legitim voneinander abweichen. 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 analysiert, die für Agents veröffentlicht wurden. 44 % enthielten an keiner Stelle 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 vagen Formulierungen in extremer Form: Eine Datei, die sich nie auf eine Zahl festlegt, kann zwar nicht im Widerspruch zu sich selbst stehen, kann aber auch kein konsistentes Interface erzeugen.

Sie haben wahrscheinlich keine 45 Plattformen. Vielleicht haben Sie drei Oberflächen, von denen zwei stillschweigend divergiert sind, und ein Team, das ständig eine Komponente fordert, die sonst niemand will. Das ist dasselbe Problem in geringerer Amplitude, und die Antworten von Encore gelten auch in dieser Größenordnung.

Platzieren Sie alles, was unveränderlich sein muss, in einer Foundation und machen Sie diese wirklich nicht überschreibbar. Lassen Sie spezialisierte Anforderungen in spezialisierten Layern leben, anstatt sie in den Core zu zwingen oder komplett aus dem System auszuklammern. Wenn ein Layer in Anfragen ertrinkt, suchen Sie nach dem fehlenden Layer darunter, bevor Sie beginnen, Anfragen abzulehnen. Und designen Sie für jede Oberfläche gleichzeitig, denn eine Komponente, die nachträglich angepasst wird, ist eine Komponente, die divergieren wird.