Design System für mehrere Marken entwickeln lassen
Ein System, viele Marken
Das Design System von badenova trägt heute 3 Energiemarken mit 124 Komponenten. Solche Systeme entstehen nicht am Moodboard, sondern in enger Arbeit zwischen Design, Engineering und Kunde.
Wir bauen Component Libraries mit Storybook, Design Tokens für Theming und die Dokumentation, mit der Teams das System selbst weiterführen können.
Das Ergebnis: Marken-Relaunches fangen nicht mehr bei Null an, und Konsistenz ist keine Frage der Disziplin mehr, sondern der Architektur.
Typische Ausgangslage
Bei badenova hatte jede Tochter einen eigenen Auftritt, und jeder Marken-Relaunch fing technisch fast bei Null an. Bei Alps Alpine liefen interne Werkzeuge über Jahre und sollten dabei einheitlich, wartbar und erweiterbar bleiben.
Wie wir sie angehen
- Design Tokens und Theming: Jede Marke bekommt ein eigenes Theme, ohne dass Komponenten dupliziert werden.
- Component Libraries in React, dokumentiert in Storybook und visuell getestet, bei badenova mit Chromatic, bei Alps Alpine mit Storyshots.
- Auf Übergabe angelegt: Die Library von Alps Alpine führen interne Teams nach Engagement-Ende weiter.
- Klarheit vor Effekt: Bei quirion haben wir UI in einer Domäne umgesetzt, in der Vertrauen wichtiger ist als Effekte.
Die Component Library für Alps Alpine entstand in 12 Monaten, bei quirion waren wir 2 Jahre Teil des Frontend-Teams.
Ablauf
Design Systems entstehen bei uns in drei Phasen. Jede Phase endet mit einem Ergebnis, auf dessen Basis Sie entscheiden, ob und wie es weitergeht.
- Beratung und Architektur, ab einer Woche: Wir erfassen, welche Marken, Produkte und Teams das System tragen soll und wie Theming und Governance aussehen. Ergebnis ist eine Entscheidungsvorlage mit Architektur, Optionen und Aufwandsschätzung.
- Prototyping und Prestudy, typisch 2–6 Wochen: Wir prüfen Tokens und Komponenten-Schnitt an einem klickbaren Prototyp und bewerten, was die Umsetzung braucht. Ergebnis sind ein klickbarer Prototyp, eine Risikobewertung und ein belastbarer Umsetzungsplan.
- Engineering und Betrieb, Monate bis Jahre: Wir bauen die Component Library, testen sie visuell und dokumentieren sie so, dass Ihre Teams das System selbst weiterführen. Ergebnis ist Software in Produktion, dokumentiert und an Ihr Team übergabefähig.
Die Component Library für Alps Alpine entstand in 12 Monaten. Mit badenova arbeiten wir seit 2022 an einem System, das heute 124 Komponenten umfasst. Die Phasen im Überblick finden Sie unter Leistungen.
Technologien
Diese Technologien setzen wir in Design-System-Projekten ein:
- Komponenten: React und TypeScript, bei badenova mit Next.js und Emotion
- Theming: Design Tokens, ein Theme pro Marke
- Dokumentation: Storybook
- Visuelle Regression: Chromatic bei badenova, Storyshots bei Alps Alpine
- Tests und CI: Jest, Playwright und GitHub Actions
- Design: Figma
- Inhalte: Storyblok als Headless CMS
Für Alps Alpine kamen Apollo und GraphQL für die Anbindung an die bestehenden Backends dazu.
Häufige Fragen
Kann ein Design System mehrere Marken tragen?
Ja. Das Design System von badenova trägt heute drei Energiemarken mit 124 Komponenten: sparstrom, badenIT und die Stadtwerke Weil am Rhein. Zentrale Design Tokens erlauben ein eigenes Theme pro Marke, ohne dass Komponenten dupliziert werden. Markenfarben, Typografie und Tonalität bleiben erhalten. Marken-Relaunches fangen so nicht mehr bei Null an.
Können unsere Teams das System selbst weiterführen?
Darauf legen wir das Setup von Anfang an aus. Die Component Library von Alps Alpine wurde nach Engagement-Ende von internen Teams weitergeführt. Dafür sorgen Dokumentation in Storybook, visuelle Tests und zentrale Build- und Test-Standards. Bei badenova sind wir als Lead-Partner für Architektur und Frontend in die IT-Organisation eingebettet.
Wie verhindern Sie, dass Änderungen bestehende Oberflächen brechen?
Mit visueller Regression. Bei badenova testen wir die Library kontinuierlich mit Chromatic, Funktion und Visual Regression laufen in automatisierten Pipelines mit Playwright. Bei Alps Alpine sicherten Storyshots die Komponenten ab, die Test-Umgebung lief mit Jest und GitHub Actions. So bleibt Konsistenz eine Frage der Architektur, nicht der Disziplin.
- Component Libraries mit React und Storybook
- Design Tokens und Theming
- User Research und UX-Konzeption
- UI-Design in Figma
- Visuelle Regression mit Chromatic
- Dokumentation und Governance
- Mehrere Marken auf einer Codebasis
- Konsistente Oberflächen über Teams hinweg
- Schnellere Relaunches und neue Auftritte
- Weniger Wartungsaufwand
- Design und Code in einer Wahrheit