Design System
NOVA —
Core Design System für Wien Energie
Ein Konzern, fünf Produkte, drei Frontend-Stacks. Und ein Design System, das alles zusammenhalten muss. Seit 2019 baue ich in Zusammenarbeit mit Digitalberatung | MAI Group an diesem Fundament für Wien Energie.
Kunde
Wien Energie
In Zusammenarbeit mit
Digitalberatung | MAI Group
Zeitraum
2019 — heute
Der Kontext
Wien Energie ist kein einzelnes Produkt. Kundenportal, Unternehmenswebsite und mehrere interne Anwendungen — fünf Produkte, sechs Teams, jedes mit eigenem Product Owner und eigenen Anforderungen. Dazu unterschiedliche Tech-Stacks: Das Kundenportal läuft auf Angular, die Website auf React. Gleiche Marke, komplett unterschiedliche Technik dahinter.
Die Produkte sind über Jahre unabhängig voneinander gewachsen, jedes Team in seinem eigenen Tempo. Das Ergebnis: doppelte Komponenten, kein gemeinsames Token-System, und Produkte derselben Marke, die an manchen Stellen einfach unterschiedlich aussehen.
Das eigentliche Problem war dabei nicht die Optik. Ohne gemeinsames Fundament wird jede Design-Entscheidung in jedem Team neu getroffen — Konsistenz hängt dann von Disziplin und Zufall ab statt von der Struktur.
Leistungen
Design Systems
Token Architecture
Component Libraries
Strategie & Governance
UI Design
Design Leadership
Vorher: drei Versionen einer Produkt-/Icon-Card in den Ökosystemen. Nachher: eine Komponente, die für alle Teilbereiche funktioniert.
Der Prozess
Als Figma die Variablen bekam und Design Systeme in der Branche wirklich ankamen, war der Moment da. Statt weiter zu flicken, haben wir das System in Zusammenarbeit mit Digitalberatung | MAI Group neu aufgesetzt.
Audit & Abstimmung
Bestandsaufnahme aller Komponenten über sämtliche Produkte hinweg: Was existiert doppelt, was lässt sich zusammenführen, was ist wirklich produktspezifisch? Parallel dazu Gespräche mit jedem Produktteam einzeln, um Anforderungen und Sonderfälle zu kennen, bevor die Architektur stand.
Architektur-Entscheidung
Ein einziges System für alle wäre an den unterschiedlichen Anforderungen gescheitert. Komplett getrennte Systeme hätten die Drift festgeschrieben. Also: ein Core-System als gemeinsame Basis, plus ein eigenes Sub-System pro Produkt, wo es gebraucht wird.
Governance
Ein System, das sechs Teams nutzen, braucht Spielregeln. Die haben wir gemeinsam im Team erarbeitet: ein DS Council für Grundsatzentscheidungen, einen definierten Component-Request-Flow, über den Teams neue Bedarfe einbringen statt lokal eigene Varianten zu bauen, und klare Grenzen, was im Core liegt und was produktspezifisch bleiben darf.
Klingt nach Verwaltung, ist aber der Teil, der trägt. Ohne diese Regeln wäre das System nach einem Jahr wieder da, wo wir angefangen haben.
Craft Deep-Dive
Drei Beispiele, wo die Systemarbeit konkret wird:
Migrations-Zustände im Blick behalten
Der Rollout läuft bei laufendem Betrieb — neue und alte Komponenten koexistieren teilweise auf denselben Seiten. Ich bin momentan die Einzige, die den Überblick hat, welche Komponente aus welchem System gerade konsumiert werden kann, und gebe auf dieser Basis Feedback an die zuständigen Designer:innen. Diese Rolle braucht jede Migration: jemanden, der beide Systeme gleichzeitig im Kopf hat.
Token-Hierarchie in der Praxis
Die Trennung von Primitive, Semantic und Component Tokens klingt erstmal theoretisch. Der Effekt ist sehr praktisch: Ein Rebrand oder Theme-Wechsel ist damit eine Token-Änderung, kein Redesign.
Komponenten fürs Development denken
Das Design ändert sich pro Framework nicht. Die Herausforderung ist, Grundkomponenten so aufzubauen, dass sie über verschiedene Stacks hinweg gleich funktionieren. Beispiel: Filter- und Dismissable Chip haben wir auf der Button-Komponente aufgebaut — so konnte der Developer auf Bestehendem aufsetzen, statt alles neu zu bauen. Komponentenstruktur ist eben auch eine Effizienzfrage fürs Development.
Rollout
NOVA ist kein Big-Bang-Launch. Wir bauen um, während alles weiterläuft. Aktuell migriere ich gemeinsam mit dem Website-Team die redaktionellen CMS-Komponenten ins neue System — der Button ist schon neu, der Großteil noch alt. Erschwerend wechselt die Website gerade das Framework, von React auf Next.js. Design-System-Migration und Technik-Umbau gleichzeitig, zwei bewegliche Ziele.
Wo NOVA heute steht
Das Kundenportal ist vollständig auf das neue System migriert und live — für mich der Beweis, dass das Core-Modell in der Praxis trägt. Der Core deckt inzwischen das komplette Komponenten-Set ab, jede Komponente mit eigener Dokumentation. Ein System mit Lücken zwingt Teams zurück in Eigenbauten.
Was sich im Alltag der Teams geändert hat: Neue Bedarfe laufen über den Request-Flow, statt dass lokal eine sechste Button-Variante entsteht. Die Website ist mitten in der Migration, weitere Produkte und Funktionen kommen laufend dazu.
Team & Rolle
Angefangen habe ich als einzige UI Designerin auf dem Account und nebenher eigentlich alles gestaltet, was digital war. Heute führe ich im Rahmen der Zusammenarbeit mit Digitalberatung | MAI Group ein vierköpfiges Design-Team: Ich verantworte das Core Design System und die CMS-Komponenten-Migration, briefe die Designer:innen der Produktteams bei System-Änderungen und bin über alle Produkte hinweg die Ansprechperson für Feedback und die richtige Verwendung des Systems.
Learnings
Architektur vor Komponenten
Token-Hierarchie und Systemstruktur entscheiden über Skalierbarkeit. Komponenten kann man austauschen, die Architektur nicht.
Governance ist Teil des Systems
Ohne Contribution-Modell und klare Ownership driftet jedes System zurück in den Zustand, aus dem es kam.
Nutzbarkeit schlägt Norm
Standards sind Werkzeuge, keine Wahrheiten. Im Zweifel zählt echtes User-Feedback mehr als die Formel.
