Design Systems als Betriebssystem für Web‑Ökosysteme: Erkenntnisse aus „Building Web Development Ecosystems“ von Fabian Hippmann (Moonshiner GmbH)

Warum Design Systems in komplexen Weblandschaften unverzichtbar sind

In „Building Web Development Ecosystems“ zeigt Fabian Hippmann (CTO, Moonshiner GmbH) anhand konkreter Erfahrungen aus Kundenprojekten, warum Design Systems zum Fundament moderner Web‑Ökosysteme werden. Der Ausgangspunkt ist vertraut: Ohne Design System beginnt jedes Projekt bei Null. Eine Agentur liefert ein Figma‑ oder XD‑Layout, und Entwicklungsteams bauen Buttons, Selects, Steppers und Formulare abermals von Grund auf. Das kostet Zeit und führt zu Inkonsistenzen.

Hippmann schildert nüchtern die Realität vor Einführung eines Systems: Bereits das Aufsetzen der Basiskomponenten verschlingt „mehr als, ich würde sagen, 20 bis 30 %“ der Projektzeit. Noch schlimmer: Mit jeder neuen Anwendung vervielfachen sich Varianten, Sonderfälle und Abweichungen – eine „n‑fache“ Implementierung desselben Musters, nur weil Teams, Stacks oder Agenturen differieren. Für Benutzerinnen und Benutzer bedeutet das ein Bruch in der Experience; für Unternehmen bedeutet es Mehrkosten, Wartungsaufwand und ein bröckelndes Markenbild.

Die These des Vortrags: Ein Design System ist mehr als ein Komponenten‑Katalog. Es ist eine gemeinsame Sprache, ein wiederverwendbarer Werkzeugkasten und ein Governance‑Rahmen, der Design, Entwicklung sowie Brand‑ und Marketing‑Teams verbindet. „Wir wollen uns auf die Features konzentrieren und nicht auf die Pixel“, fasst Hippmann zusammen – und leitet daraus technische und organisatorische Konsequenzen ab.

Der Problemraum: Inkonsistenz, Doppelarbeit, fehlende Sprache

• Jedes Projekt beginnt bei Null: Buttons, Dropdowns, Steppers, Formulare – jedes Mal neu gedacht und gebaut.
• Hoher Overhead: 20–30 % der Zeit fließen in die Basisausstattung, bevor Features entstehen.
• Inkonsistentes Marken‑ und Nutzungserlebnis: Zehn bis fünfzehn Teams liefern zehn bis fünfzehn Interpretationen desselben UI‑Bausteins.
• Fragmentiertes Arbeiten: Designer, Entwickler, Marketing und Brand sprechen nicht dieselbe Sprache; „Pixel‑Diskussionen“ dominieren die Übergabe.
• Schlechte Skalierung: Ein Feature in App A lässt sich nicht sauber in App B übernehmen; Kopieren bedeutet doppelte Wartung.

Besonders eindrücklich ist Hippmanns Beispiel des „Stepper“-Musters: „Es gibt Fälle, wo Sie einen Stepper haben ‚1 von 5‘ – aber jede Anwendung sieht anders aus und ist unabhängig implementiert.“ Aus Nutzersicht entsteht der Eindruck, ständig umzudenken – „wie wenn man von Google zu Bing wechselt“. Aus Unternehmenssicht ist es ein „No‑Go“, wenn energie‑ oder finanznahe Services nicht konsistent und sicher erlebbar sind.

Der Ansatz: Ein Ökosystem statt isolierter Projekte

Moonshiner beginnt bei neuen Kunden mit einer Bestandsaufnahme: Technologie‑Stacks, Schlüsselpersonen, Kollaborationsmodelle, Anpassungsbedarf, Governance‑Grad. Daraus leiten sie die Struktur des Design Systems und die Integrationspfade ab. Zentral ist eine Quelle der Wahrheit:

• Ein zentrales Repository mit UI‑Komponenten, Token‑Styleguide und einem CLI, konsumierbar über NPM.
• Ein begleitender Styleguide, in dem Komponenten neben Code sichtbar sind – die „linke Seite/rechte Seite“-Ansicht des Systems erleichtert Review und Abstimmung.
• Ein Setup, das mehrere Projekte (Landingpage, PWA, Dealer‑Space, interne Tools) aus derselben Basis bedienen kann – ohne Duplizierung.

Hippmann betont, dass „einfach React einführen“ selten reicht. In großen Organisationen gibt es gewachsene Systeme, Tech‑Präferenzen und legitime Gründe für unterschiedliche Stacks. Also trennt Moonshiner bewusst die Ebenen: von Tokens über CSS bis hin zu Framework‑Komponenten und kompletten Page‑Bausteinen.

Die mehrschichtige Architektur des Systems

1) Design Tokens als kleinste Bausteine

Farben, Abstände, Größen – all das extrahiert Moonshiner in eigenständige Pakete. Diese „Design Tokens“ sind technologieagnostisch. Sie können in React‑Apps, Angular‑Frontends, nativen oder Desktop‑Anwendungen konsumiert werden. Wer „nur die Farben und Spacings“ braucht, implementiert ausschließlich die Tokens – ohne das restliche System zu ziehen.

2) Kompiliertes CSS und HTML‑Blueprints

Für sehr leichte Integrationsfälle – etwa eine Landingpage, die eine Marketingagentur baut – stellt das Team kompiliertes CSS und HTML‑Blueprints bereit. Man importiert das CSS, übernimmt die HTML‑Struktur aus dem Styleguide, und „es sieht immer noch so aus, als wäre es eine voll ausgebaute React‑, Angular‑ oder sonstige Anwendung“. So bleiben Seiten konsistent, auch wenn sie nicht in einem großen App‑Framework leben.

3) UI‑Komponenten vs. CMS‑Komponenten

Moonshiner unterscheidet zwei Konsumebenen:

• UI‑Komponenten: „Das einfache Zeug, das einfach funktionieren muss“ – Buttons, Dropdowns, Form‑Controls. Diese sind der Baukasten für Applikationen und werden in einheitlicher Qualität, Semantik und Interaktion bereitgestellt.
• CMS‑Komponenten: Technologieagnostische Seitenbausteine für Inhalte – z. B. Datenschutzseiten oder Marketing‑Content. Der Clou: Dieselben Komponenten können in WordPress, in Gatsby, in Next.js/Nuxt.js oder in einer schema‑orientierten Headless‑Umgebung genutzt werden – ohne sich an die Syntax eines bestimmten CMS (Sitecore, Adobe Experience Manager usw.) zu binden.

Diese Trennung beschleunigt sowohl Content‑Teams als auch Applikationsentwickler. Wer lediglich Seiten ausspielt, arbeitet mit CMS‑Komponenten. Wer Interaktionslogik implementiert, greift auf UI‑Komponenten zurück – und beide profitieren von Tokens und CSS als gemeinsame Basis.

4) Technologie‑Flexibilität und Web Components, wo nötig

Im Idealfall kann ein Unternehmen eine einheitliche Technologie wählen – „ein Luxus“, der langfristig vieles vereinfacht. Doch dort, wo heterogene Stacks gesetzt sind, nutzt Moonshiner Entkopplung: Für manche Kunden (z. B. in einem Fall „Signalituna“) realisierten sie Frontend‑Rendering bewusst mit Web Components, behielten aber dieselben CSS‑ und Token‑Pipelines als Unterbau bei. Das macht das System im Konsum flexibel, ohne die Designidentität aufzugeben.

Zusammenarbeit statt Silos: eine ubiquitäre Sprache

„Designer müssen nicht entwickeln und Entwickler nicht designen“ – aber beide müssen dasselbe meinen, wenn sie „Button“ sagen. Hippmann schildert, wie fehlende Begrifflichkeit Konflikte, Reibungsverluste und Frust erzeugt: mehr Iterationen, Pixel‑Diskussionen, unklare Varianten. Die Lösung ist eine ubiquitäre Sprache über Tools und Disziplinen hinweg.

Figma als Brücke

Hippmann hebt Figma hervor – nicht als reines Designwerkzeug, sondern als verbindendes Medium. Figma bietet Varianten und Komponenten, sodass Designer „denken wie in der Entwicklung“. Die Oberfläche im „Stratum UI Design Kit“-Beispiel zeigt Dropdowns für Typen, Varianten und Formen; Entwickler und Designer teilen dasselbe Vokabular und dieselbe Parametrisierung. Das Ergebnis: „Seiten wurden an einem Tag aufgebaut; das Design‑Review dauerte eine halbe Stunde – dann war es fertig.“

Automatisierte Token‑Synchronisation

Der zweite Baustein ist Automatisierung. Figma stellt „eine wirklich world‑class, würde ich sagen, REST API“ bereit. Moonshiner nutzt diese, um Basis‑Tokens direkt aus Figma in den Code zu synchronisieren – versioniert und überprüfbar. Dadurch entfällt das mühsame manuelle Übertragen: „Designer verbessern das Design, sagen ‚Bitte schau nach, welche Werte zu ändern sind‘ – und jede Woche wiederholt sich der Prozess.“ Die Automatisierung „nimmt Arbeit von den Entwicklern“ und „motiviert Designer, ihre Struktur sauber zu denken“, weil Änderungen direkt Auswirkungen im Code haben.

Governance: Monorepo, Workspaces, CLI, Styleguide

Ein Design System ist nur so gut, wie es konsumierbar ist. Hippmann beschreibt die Praxis:

• NPM‑konsumierbare Pakete und ein CLI, um Projekte schnell zu starten.
• Ein zentrales Monorepo und Workspaces, damit zusammengehörige Teile (Tokens, CSS, UI‑Komponenten, CMS‑Bausteine) gemeinsam versioniert und veröffentlicht werden.
• Ein Styleguide, der Komponenten und Code nebeneinander zeigt, als Testbett und Kommunikationsfläche für Design und Entwicklung.

Das Ziel: Einfache Onboarding‑Pfade, einheitliche Versionierung und nachvollziehbare Änderungen – quer über Anwendungen hinweg.

Betrieb im Maßstab: Projektschema und Developer‑Portal

Wer 10, 30 oder 40 Anwendungen betreibt, braucht mehr als einen Komponenten‑Katalog. Moonshiner ergänzt jedes Projekt um ein „Project Schema“: Welche APIs sind angebunden? Wie ist das Frontend gebaut? Wer ist verantwortlich? Diese Metadaten landen in einem zentralen Developer‑Dashboard – dem „Developer Portal“.

Hippmann empfiehlt hier „Backstage powered by Spotify“, eine Open‑Source‑Plattform für interne Developer‑Experience. Backstage bietet einheitliche Sicht auf Frontends und Backends (statt jeweils isolierter Monitoring‑Inseln), Plugins für Logs, Dokumentation, Onboarding und ein lebendiges Ökosystem. Schon beim Aufbau der „Lutz“-Plattform (Moonshiner startete „2007“ in diesem Kontext) war klar: Teams brauchen eine zentrale Übersicht über Verantwortlichkeiten, Systeme und Zustände. Backstage deckt genau das ab – und hat sich in den Kundenorganisationen rasch bewährt.

Projektbeispiele: Vom Greenfield zur skalierten Plattform

Wien Energie

Zum Beginn des Lockdowns startete das Team die neue Wien‑Energie‑Website. Der Unterbau: ein selbst entwickeltes Design System. Binnen eines halben Jahres entstanden darauf vier bis fünf weitere Anwendungen – teils von externen Teams – und das System passte sich an unterschiedliche Umgebungen an: WordPress, ein schema‑orientiertes CMS‑Backend, Gatsby, React sowie Create React App. Feedback der Nutzer war positiv, und Anwendungen „konnten in unter einem Tag“ entstehen – vorher waren es mehrere Iterationen.

X66LOOTS Group

Mit der internen Mannschaft der X66LOOTS Group baute Moonshiner die digitale Architektur des E‑Commerce‑Shops. Die Herausforderung: mehrere Marken (u. a. „Möbelix, Mömark, Poco“) unter einem Dach, aber „Luxus“ einer gemeinsamen Tech‑Basis. Ergebnis: ein React‑basierter Stack, betreut vom selben Team für alle Marken. Ein System, viele Brands, eine Wartung.

Signalituna

Hier lag der Fokus auf heterogenen Tech‑Stacks und vielen beteiligten Teams. Die Lösung: ein Web‑Components‑basiertes Design System für das Frontend‑Rendering, ergänzt um CSS‑Design‑Tokens aus der bekannten Pipeline. Die Priorität lag auf der langfristigen Zusammenarbeit: Wie kommunizieren Teams effektiv? Wie bauen sie Anwendungen, die „Jahre“ halten? Wie skaliert man die Organisation, nicht nur die Komponenten?

Alle drei Fälle zeigen denselben roten Faden: Mit einem durchdachten System lassen sich Greenfield‑Projekte starten, auf mehrere Marken und Anwendungen ausrollen und anschließend mit wachsenden Entwicklerteams weiterentwickeln – ohne dass Konsistenz oder Geschwindigkeit leiden.

Werkzeugkette: Bewährtes statt Hipness

Moonshiner nutzt vieles – Vue.js, Web Components, verschiedene Frameworks –, aber einige Konstanten kristallisieren sich heraus:

• React und Preact als „super mächtige“ View‑Layer, notfalls in Angular integrierbar „mit ein bisschen Drehen“. Die Community, das Denken in Komposition und die Langfristigkeit geben Vertrauen.
• „ReactKit“ als Accessibility‑Bibliothek, auf der das System (z. B. bei Wien Energie) aufbaut. Vor allem Formulare und Zustandsmanagement profitieren; Accessibility ist „eine solide Basis“ statt späterer Nacharbeit.
• Yarn als Package‑Manager. Im Vergleich zu Learna und NPM ist die Geschwindigkeit „crazy, crazy gut“. Workspaces und Monorepo‑Ansatz sind Standard, „weil die wichtigsten Teile zusammengehören“.
• Backstage als internes Developer‑Portal, um Frontend und Backend gemeinsam sichtbar zu machen, Logs und Dokumentation zentral zu halten und Onboarding zu standardisieren.

Hippmann betont, dass sie diese Tools „immer wieder infrage gestellt“ haben – und dennoch dabeibleiben: Sie bewähren sich in Projekten und in den Communities und geben langfristige Sicherheit.

Praktische Lehren für Engineering‑Teams

Was lässt sich aus „Building Web Development Ecosystems“ konkret mitnehmen? Aus der Sicht der DevJobs.at‑Redaktion stechen folgende Punkte hervor – alle aus dem, was Hippmann explizit adressiert:

1) Investieren Sie in eine ubiquitäre Sprache.

• Benennen Sie in Design und Code dieselben Varianten („Type“, „Outline“, „Rounded“ usw.).
• Nutzen Sie Tools wie Figma‑Varianten und ‑Komponenten, um dieselbe Parametrisierung zu teilen.
• Dokumentieren Sie im Styleguide so, dass Designer und Entwickler dieselbe Oberfläche sehen.

2) Trennen Sie bewusst die Ebenen des Systems.

• Tokens als kleinstes, technologieagnostisches Paket.
• Kompiliertes CSS und HTML‑Blueprints für Lightweight‑Nutzung.
• UI‑Komponenten für Interaktion und Logik.
• CMS‑Komponenten für Inhalte, unabhängig von WordPress, Gatsby, Next.js/Nuxt.js oder schema‑basierten Backends.

3) Automatisieren Sie die Token‑Synchronisation.

• Nutzen Sie die Figma‑REST‑API, um Änderungen versioniert in den Code zu bringen.
• Entfernen Sie manuelle Übertragungsarbeit; reduzieren Sie Reibung und Review‑Aufwände.

4) Organisieren Sie Ihr System im Monorepo mit Workspaces.

• Halten Sie zusammengehörige Teile in einem Repository; veröffentlichen Sie klar geschnittene Pakete über NPM.
• Ergänzen Sie ein CLI für wiederholbare Projekt‑Setups und Upgrades.

5) Bauen Sie Governance neben Technologie.

• Führen Sie für jedes Projekt ein Schema: APIs, Frontend‑Stack, Ownership.
• Führen Sie ein Developer‑Portal (z. B. Backstage) für Logs, Dokumentation, Onboarding und den holistischen Überblick.

6) Wählen Sie Technologien, die lange tragen.

• Rechnen Sie mit Team‑Wachstum, Wechseln und Externen.
• Bevorzugen Sie Bausteine mit starker Community und bewährter Stabilität.

7) Messen Sie Erfolg an der Umsetzungsgeschwindigkeit und Konsistenz.

• „Seiten an einem Tag, Review eine halbe Stunde“ – solche Erfolge werden möglich, wenn Sprache, Tokens, Komponenten und Governance greifen.

Fazit: Fokus auf Features, nicht auf Pixel

„Wir wollen uns auf die Features konzentrieren und nicht auf die Pixel.“ Dieser Satz durchzieht den Talk von Fabian Hippmann. Ein Design System ist das Mittel, genau das zu erreichen – technisch (Tokens, CSS, UI‑ und CMS‑Komponenten, Web Components, Monorepo), organisatorisch (ubiquitäre Sprache, Styleguide) und betrieblich (Project Schema, Developer‑Portal, Backstage).

Die Beispiele – Wien Energie, X66LOOTS Group, Signalituna – zeigen, wie sich aus einer gemeinsamen Basis unterschiedliche Anwendungen, Marken und Teams bedienen lassen. Mal mit React/Preact, mal mit Web Components, mal eingebettet in WordPress oder Gatsby – aber stets mit derselben Designidentität und demselben Entwicklungsfluss.

Für Teams, die heute vor einem gewachsenen Portfolio stehen oder ein neues Ökosystem aufbauen wollen, liegt die Richtung klar: Komponenten entkoppeln, Tokens zentralisieren, Konsumwege staffeln, Automatisierung etablieren, Ownership sichtbar machen. So entsteht ein Web‑Ökosystem, das nicht nur die nächste App, sondern die nächsten Jahre trägt – genau der Anspruch, den „Building Web Development Ecosystems“ formuliert.