Portfolio
Design-System-Strategie — skalieren, migrieren, weiterliefern
Marktplatz, SaaS-Produkt und Backoffice-Anwendungen brauchten eine gemeinsame gestalterische Grundlage. Ich verantwortete die Konzeption und Figma-Bibliothek des proprietären Design Systems und arbeitete eng mit der Frontend-Entwicklung zusammen. Mit dem Wachstum auf fünf Entwickler wurde die Frage nach dem Pflegeaufwand wichtiger: Welche Teile sollten wir weiterhin selbst entwickeln, und wo konnten wir auf eine bestehende Bibliothek zurückgreifen?
Prozess
Phase 01
Eine gemeinsame Grundlage aufbauen
Ich konzipierte die Komponentenarchitektur und baute die Figma-Bibliothek auf: Varianten und Zustände, Formulare, Alerts, Modals sowie Dark und Light Mode. Die Struktur machte wiederkehrende Entscheidungen explizit und gab Design und Entwicklung eine gemeinsame Referenz.
Phase 02
Das System im Produktalltag weiterentwickeln
In den ersten zwei Jahren arbeitete ich mit zwei Frontend-Entwicklern am produktiven System. Neue Anforderungen ergänzten die Komponenten und ihre Dokumentation. Der laufende Betrieb zeigte, welche Regeln über Produktgrenzen hinweg trugen und wo weitere Differenzierung nötig war.
Phase 03
Die technische Basis wechseln
Mit MUI sollte der Aufwand für die technische Komponentenbasis sinken. Ich begleitete den Übergang aus Sicht des Design Systems. Die bestehende Struktur ließ sich mit einem vergleichsweise schlank angepassten Theme übertragen, sodass der Wechsel für Nutzer und Stakeholder visuell wenig auffiel.
Phase 04
Mit zwei Systemen umgehen
MUI wurde für neue Kontexte genutzt; proprietäre Komponenten blieben dort bestehen, wo ihr Austausch geschäftlich niedriger priorisiert war. Das bedeutete zusätzlichen Parallelbetrieb, vermied aber, die Migration allein aus Gründen technischer Einheitlichkeit zum Selbstzweck zu machen.
Methoden
Komponentenmodell
Varianten, Zustände und Darstellungsmodi waren Teil einer nachvollziehbaren Struktur. Sie bildete die Grundlage für Umsetzung und spätere Übertragung.
Migrationsfähigkeit
Die Kenntnis der bestehenden Komponenten half, Entsprechungen zu MUI zu finden und nötige Anpassungen einzugrenzen.
Eigenständige Umsetzung ermöglichen
Bibliothek, Tokens und Dokumentation sollten Entwickler dabei unterstützen, wiederkehrende Entscheidungen konsistent umzusetzen.
Produktübergreifende Abwägung
Eine gemeinsame Basis muss unterschiedliche Anwendungskontexte tragen. Auch der Zeitpunkt einer Migration gehört zu diesen Abwägungen.
Visuals
Die Komponentenbibliothek als gemeinsame Referenz für mehrere Produkte.
Button-Varianten als Ausschnitt des gemeinsamen Komponentenmodells.
Dark und Light Mode innerhalb derselben gestalterischen Grundlage.
Heatmap einer Registrierung im Produktkontext; sie zeigt Nutzung, nicht den isolierten Effekt des Design Systems.
Das System wurde über mehrere Jahre produktiv genutzt. Beim Wechsel zu MUI blieb die Oberfläche in den migrierten Bereichen weitgehend vertraut; ein angepasstes Theme konnte wesentliche gestalterische Eigenschaften übernehmen. Zum beschriebenen Projektstand bestanden MUI und proprietäre Komponenten parallel, abhängig von der geschäftlichen Priorität einer Migration. Der Case zeigt, wie ich Aufbau, Weiterentwicklung und technische Anschlussfähigkeit eines gemeinsamen Systems begleitet habe. Eine gemessene Einsparung von Entwicklungszeit ist damit nicht belegt.