Design System
NOVA —
Core Design System für Wien Energie
Ein Konzern, fünf Produkte, drei Frontend-Frameworks. Und ein Design System das alles zusammenhalten muss. Seit 2019 baue ich bei Wien Energie an genau diesem Fundament.
Kunde
Wien Energie
Agentur
Digitalberatung / MAI Group
Zeitraum
2024 — heute
Leistungen
Design Systems
Token Architecture
Component Libraries
Strategie & Governance
UI Design
Design Leadership
Figma
Cross-Framework
Der Kontext
Wien Energie ist kein einzelnes Produkt. Es gibt ein Kundenportal, eine große Unternehmenswebsite und mehrere interne Anwendungen — jedes mit eigenem Team, eigenem Product Owner und eigenen Anforderungen. Dazu kommen unterschiedliche Tech-Stacks: Das Kundenportal läuft auf Angular, die Website lief auf React. Gleiche Marke, komplett unterschiedliche Technik dahinter.
Ich bin seit 2019 auf dem Projekt, angefangen mit den ersten Style Tiles fürs Kundenportal. Lange war ich die einzige UI Designerin und habe nebenher eigentlich alles gestaltet, was digital war. Heute leite ich das Design-Team und verantworte das Core Design System.
Das Problem
Die Produkte sind über Jahre unabhängig voneinander gewachsen. Jedes Team hatte sein eigenes Tempo, seinen eigenen PO, seinen eigenen Geschmack. Irgendwann war klar: Es gibt doppelte Komponenten, kein gemeinsames Token-System, und die Produkte derselben Marke sehen an manchen Stellen einfach unterschiedlich aus.
Das eigentliche Problem war dabei nicht die Optik. Ohne gemeinsames Fundament wird jede Design-Entscheidung in jedem Team neu getroffen — und Konsistenz hängt dann von Disziplin und Zufall ab statt von der Struktur.
Das Problem
Die Produkte sind über Jahre unabhängig voneinander gewachsen. Jedes Team hatte sein eigenes Tempo, seinen eigenen PO, seinen eigenen Geschmack. Irgendwann war klar: Es gibt doppelte Komponenten, kein gemeinsames Token-System, und die Produkte derselben Marke sehen an manchen Stellen einfach unterschiedlich aus.
Das eigentliche Problem war dabei nicht die Optik. Ohne gemeinsames Fundament wird jede Design-Entscheidung in jedem Team neu getroffen — und Konsistenz hängt dann von Disziplin und Zufall ab statt von der Struktur.
Der Prozess
Als Figma die Variablen-Funktion bekam und Design Systeme auch bei uns in der Branche wirklich ankamen, war der richtige Moment da. Statt weiter zu flicken, haben wir neu aufgesetzt. Mein Vorgehen:
Audit
Bestandsaufnahme aller Komponenten über sämtliche Produkte hinweg. Was existiert doppelt? Was lässt sich zusammenführen? Was ist wirklich produktspezifisch?
Abstimmung mit den Teams
Mit jedem Produktteam einzeln, um Anforderungen und Sonderfälle zu verstehen, 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 nur festgeschrieben. Also: ein Core-System als gemeinsame Basis, plus ein eigenes Sub-System pro Produkt, wo es gebraucht wird.
Der Prozess
Als Figma die Variablen-Funktion bekam und Design Systeme auch bei uns in der Branche wirklich ankamen, war der richtige Moment da. Statt weiter zu flicken, haben wir neu aufgesetzt. Mein Vorgehen:
Audit
Bestandsaufnahme aller Komponenten über sämtliche Produkte hinweg. Was existiert doppelt? Was lässt sich zusammenführen? Was ist wirklich produktspezifisch?
Abstimmung mit den Teams
Mit jedem Produktteam einzeln, um Anforderungen und Sonderfälle zu verstehen, 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 nur 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 überlebenswichtig: Ohne diese Regeln wäre das System nach einem Jahr wieder genau da, wo wir angefangen haben.
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 überlebenswichtig: Ohne diese Regeln wäre das System nach einem Jahr wieder genau da, wo wir angefangen haben.
Craft Deep-Dive
Vier 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. Auf der Basis gebe ich 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 aber 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 in der Umsetzung ü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 Effizienz-Frage fürs Development.
Norm-Konformität ist nicht gleich Wahrnehmung
Weiß auf unserem Markenorange (#EB6626) erreicht nur 3.25:1 und fällt damit bei WCAG AA für Fließtext (4.5:1) durch. Dunkelblau (#000460) besteht mit 5.44:1 klar. Trotzdem berichten User mit Farbkontrast-Einschränkungen, dass Weiß auf Orange für sie besser lesbar ist. Der Grund: Die WCAG-2-Formel misst Leuchtdichte, nicht menschliche Wahrnehmung — bei gesättigten Mitteltönen wie Orange kommt da manchmal Unsinn raus. (Genau deshalb gibt es mit APCA für WCAG 3 einen neuen Ansatz.) Für mich heißt das: Norm-Wissen und echtes User-Feedback gehören beide auf den Tisch.
Craft Deep-Dive
Vier 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. Auf der Basis gebe ich 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 aber 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 in der Umsetzung ü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 Effizienz-Frage fürs Development.
Norm-Konformität ist nicht gleich Wahrnehmung
Weiß auf unserem Markenorange (#EB6626) erreicht nur 3.25:1 und fällt damit bei WCAG AA für Fließtext (4.5:1) durch. Dunkelblau (#000460) besteht mit 5.44:1 klar. Trotzdem berichten User mit Farbkontrast-Einschränkungen, dass Weiß auf Orange für sie besser lesbar ist. Der Grund: Die WCAG-2-Formel misst Leuchtdichte, nicht menschliche Wahrnehmung — bei gesättigten Mitteltönen wie Orange kommt da manchmal Unsinn raus. (Genau deshalb gibt es mit APCA für WCAG 3 einen neuen Ansatz.) Für mich heißt das: Norm-Wissen und echtes User-Feedback gehören beide auf den Tisch.
Rollout / Current State
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 der CMS-Komponenten noch alt. Und nebenher kommen laufend neue Produkte und Funktionen dazu. Erschwerend wechselt die Website gerade auch noch das Framework, von React auf Next.js. Design-System-Migration und Technik-Umbau gleichzeitig — zwei bewegliche Ziele.
Das Kundenportal ist dagegen schon fertig: vollständig aufs neue System migriert und live. Für mich der Beweis, dass das Core-Modell in der Praxis trägt. Und weil ein System nur so gut ist, wie es genutzt wird, gehören Briefings, Feedback-Loops und Ansprechbarkeit für die anderen Designer:innen fix zu meiner Arbeit dazu.
Rollout / Current State
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 der CMS-Komponenten noch alt. Und nebenher kommen laufend neue Produkte und Funktionen dazu. Erschwerend wechselt die Website gerade auch noch das Framework, von React auf Next.js. Design-System-Migration und Technik-Umbau gleichzeitig — zwei bewegliche Ziele.
Das Kundenportal ist dagegen schon fertig: vollständig aufs neue System migriert und live. Für mich der Beweis, dass das Core-Modell in der Praxis trägt. Und weil ein System nur so gut ist, wie es genutzt wird, gehören Briefings, Feedback-Loops und Ansprechbarkeit für die anderen Designer:innen fix zu meiner Arbeit dazu.
Team & Rolle
2019 habe ich als einzige UI Designerin auf dem Account angefangen und das System von Grund auf mit aufgebaut. Heute führe ich 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, wenn es um Feedback und die richtige Verwendung des Systems geht.
Team & Rolle
2019 habe ich als einzige UI Designerin auf dem Account angefangen und das System von Grund auf mit aufgebaut. Heute führe ich 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, wenn es um Feedback und die richtige Verwendung des Systems geht.
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.
Übergangszustände mitdenken. Reale Systeme werden bei laufendem Betrieb migriert. Wer nur den Endzustand plant, plant am Alltag vorbei.
Nutzbarkeit schlägt Norm. Standards sind Werkzeuge, keine Wahrheiten. Im Zweifel zählt echtes User-Feedback mehr als die Formel.
Vollständigkeit und Doku zahlen sich aus. NOVA bildet heute wirklich alle Komponenten ab, jede mit detaillierter Dokumentation. Ein System mit Lücken zwingt Teams zurück in Eigenbauten.
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.
Übergangszustände mitdenken. Reale Systeme werden bei laufendem Betrieb migriert. Wer nur den Endzustand plant, plant am Alltag vorbei.
Nutzbarkeit schlägt Norm. Standards sind Werkzeuge, keine Wahrheiten. Im Zweifel zählt echtes User-Feedback mehr als die Formel.
Vollständigkeit und Doku zahlen sich aus. NOVA bildet heute wirklich alle Komponenten ab, jede mit detaillierter Dokumentation. Ein System mit Lücken zwingt Teams zurück in Eigenbauten.
