Sternengeist
Ein Designsystem für Konsistenz, Geschwindigkeit und Zusammenarbeit
Team
Vanessa Trantes – UX-Designerin
Moon Löffler – UX-Designerin
Zeitrahmen – 5 Monate
Stellen Sie sich Folgendes vor…
Das Produkt wächst, die Funktionen werden eingeführt – und ein unstrukturiertes Designsystem wird zunehmend zur Belastung.
Ein Designer überschreibt unwissentlich die Arbeit eines anderen.
Der Entwickler ist sich nicht sicher, welcher Knopf der „richtige“ ist.
Das Marketingteam öffnet eine Datei und findet ein völlig anderes Set an Stilen vor.
Bei Starmind, einem in Zürich ansässigen SaaS-Unternehmen, das KI-gestützte Wissensnetzwerke für große Organisationen entwickelt, hatten wir gerade den Wechsel von Sketch zu Figma vollzogen – in der Hoffnung auf eine bessere Zusammenarbeit und reibungslosere Übergabe zwischen den Teams. Doch der Übergang legte tieferliegende Probleme offen: inkonsistente Muster, unterschiedliche Stile, doppelte Komponenten und zunehmende Verwirrung zwischen Design, Entwicklung und Marketing.
Es wurde deutlich: Wir brauchten nicht nur ein besseres Werkzeug.
Wir brauchten eine gemeinsame Sprache.
Wir brauchten ein Designsystem.
Ziele
-
Verbessern Sie die Zusammenarbeit zwischen den Teams durch die Einführung eines gemeinsamen Systems für Designer und Entwickler.
-
Steigern Sie die Konsistenz und Effizienz im Designprozess, indem Sie redundante Elemente reduzieren und wiederverwendbare Komponenten erstellen.
-
Erleichtern Sie neuen Teammitgliedern den Einstieg durch klare Dokumentation und visuelle Richtlinien.
-
Unterstützen Sie einen reibungslosen Übergang von Sketch zu Figma und machen Sie Ihren Design-Workflow zukunftssicher.
Bevor wir mit dem Aufbau des Systems begannen, recherchierten wir eingehend die besten Tools und Programme, die unseren Workflow unterstützen würden. Da wir von Sketch umstiegen, untersuchten wir Plattformen wie Figma und Adobe XD sowie einige weitere.
Unsere Hauptkriterien waren Zusammenarbeit, Versionskontrolle, reibungslose Entwicklerübergabe und Skalierbarkeit. Nach dem Vergleich von Funktionen und dem Testen einiger Lösungen in realen Szenarien entschieden wir uns für Figma, da es unseren Anforderungen am besten entspricht.
Wir haben eine Kopie der Dokumentation in Confluence gespeichert, um einen einfachen Zugriff für Marketing, Produktmanager und andere Mitarbeiter im Unternehmen zu ermöglichen, die möglicherweise nicht mit Figma vertraut sind.
Designprüfung
Wir begannen mit einem umfassenden Design-Audit, um den aktuellen Stand unseres Produkts zu ermitteln. Dies beinhaltete die Erfassung aller vorhandenen Elemente – Benutzerabläufe, UI-Elemente, Typografie, Farben, Illustrationen, Icons, Schaltflächen, Dropdown-Menüs und Interaktionsmuster – sowohl für Mobilgeräte als auch für Desktop-Computer.
Anschließend sortierten und kategorisierten wir jedes Element und identifizierten Redundanzen sowie Konsolidierungsmöglichkeiten. Wir bewerteten außerdem die Barrierefreiheit umfassend: Wir prüften Kontrast, Lesbarkeit, Alternativtexte und mehr.
Um eine einheitliche Darstellung zu gewährleisten, haben wir uns mit den Entwicklern getroffen, um ihre Komponentenbibliothek zu überprüfen und Unstimmigkeiten aufzudecken, und wir haben uns mit dem Marketingteam in Verbindung gesetzt, um eine visuelle Kohärenz über alle Markenkontaktpunkte hinweg sicherzustellen.
Aufbau des Systems
Vanessa und ich haben uns wöchentlich Zeit genommen, um gemeinsam das System aufzubauen, während wir gleichzeitig Figma-Tutorials absolvierten und weitere Designaufgaben wahrnahmen. Unser Vorgehen:
-
Die bestehende visuelle Identität wurde als Grundlage verwendet und im Hinblick auf Klarheit und Skalierbarkeit optimiert.
-
Übernommene, bewährte Strukturen aus bestehenden Entwurfssystemen
-
Fokus auf praktische Anwendung – Entwicklung von Komponenten, die wir tatsächlich in verschiedenen Abläufen wiederverwenden können.
-
Eng mit Entwicklern zusammengearbeitet, um Namen, Stile und Verhalten aufeinander abzustimmen.
Wir haben einen lebendigen Leitfaden für ein Designsystem entwickelt – zugänglich für alle bei Starmind. Unsere Prioritäten:
Klare, einfache Sprache (kein Fachjargon)
Visuelle Beispiele für jedes Element
Anleitung zur Verwendung der einzelnen Komponenten
Häufig gestellte Fragen und Tipps basierend auf echten internen Fragen
Wir haben unsere Dokumentation regelmäßig getestet, indem wir sie mit Kollegen außerhalb des Designbereichs geteilt und deren Feedback eingearbeitet haben.
Die Implementierung erfolgte schrittweise und erforderte eine enge Abstimmung mit den Entwicklern. Da deren Terminkalender mit anderen Prioritäten voll ausgelastet war, teilten wir die Arbeit in kleine, überschaubare Aufgaben auf und bearbeiteten diese Schritt für Schritt.
Dieser schrittweise Ansatz half uns, Änderungen nach und nach einzuführen, ohne das Team zu überfordern. Er erleichterte es uns außerdem, den Fortschritt zu überwachen, etwaige Inkonsistenzen frühzeitig zu erkennen und sicherzustellen, dass Design und Entwicklung einheitlich aufeinander abgestimmt sind.
Erfolg messen
Wir haben uns nicht auf automatisiertes Tracking verlassen, sondern die Akzeptanz und Effizienz durch eine Kombination aus Audits, Team-Feedback, Onboarding-Performance und internen QA-Kanälen überwacht.
Folgendes haben wir beobachtet:
→ Redundante Elemente von über 100 auf ein optimiertes, dokumentiertes Set reduziert
→ Dies führte zu einheitlicheren Komponenten im gesamten Produkt.
→ Designer und Entwickler arbeiteten dank übersichtlicherer Dateien, weniger Verzögerungen und reibungsloserer Übergaben schneller.
→ Weniger Slack-Nachrichten und Klärungsbedarf bei der Übergabe
→ Deutlicher Rückgang der QA-Flags im Zusammenhang mit Designinkonsistenzen
→ Neuer Designer nutzt das System innerhalb von 2 Wochen vollständig.
→ Keine 1:1-Komplettlösungen erforderlich
→ Keine Fragen mehr zu fehlenden Komponenten oder unklarer Dokumentation
→ Eine sichere Basis für zukünftiges Wachstum :)
Was ich gelernt habe
Was ich aus diesem Projekt wirklich mitgenommen habe, ist, dass der Aufbau eines Designsystems kein geradliniger Weg ist – er ist geprägt von Iterationen, unerwarteten Umwegen und viel Kommunikation. Die enge Zusammenarbeit mit den Entwicklern war unerlässlich; wir mussten gemeinsam entscheiden, was beibehalten, was geändert und wie wir sicherstellen konnten, dass das System in der Praxis auch funktioniert.
Das Schreiben von Dokumentationen hat mir ebenfalls viel beigebracht – insbesondere, wie wichtig es ist, Dinge einfach und verständlich zu gestalten, nicht nur für Designer, sondern für alle, die sie nutzen könnten. Mir wurde auch bewusst, wie viel Zeit und Verwirrung ein paar kleine Unstimmigkeiten verursachen können und wie befriedigend es ist, diese zu beseitigen. Vor allem aber habe ich gelernt, dass die Berücksichtigung von Feedback und das Setzen klarer Prioritäten den gesamten Prozess reibungsloser und wirkungsvoller gestalten.