Design System Guide
Zum DS GuideKontext
Ich habe in einem Zwei-Designer-Team ein Figma-first Design System ohne dedizierten Owner gepflegt — nebenbei, zwischen Research, Konzeption und allem anderen, was sonst noch anliegt. Als sich ein Design-System als still kontaminiert herausstellte, verbrachten wir zwei volle Tage damit, jede Komponente von Hand zu prüfen. Aus dieser Erfahrung entstand die Idee, das Problem und die Lösung als eigenständigen Leitfaden aufzuschreiben um Designern dieses Wissen zur Verfügung zu stellen.
Problem
Kein Audit-Tool am Markt erkennt das eigentliche Problem: Ein Token kann korrekt benannt sein und trotzdem auf eine falsche, veraltete Library-Quelle zeigen. Bestehende Plugins prüfen nur, ob überhaupt ein Token verknüpft ist — nicht, ob er noch aus der richtigen Quelle stammt. Presence statt Provenance. Für kleine Teams ohne dedizierten Design-System-Owner gab es dafür keine praktische Anleitung.
Vorgehen
Bevor ich zu schreiben begann, habe ich die These wochenlang gegen den realen Markt geprüft — bestehende Plugins selbst getestet, Aussagen direkt mit den jeweiligen Tool-Entwicklern abgeglichen, mit Design-System-Praktikern gesprochen. Parallel dazu über Monate Fachbeiträge auf LinkedIn veröffentlicht, um zu sehen, ob das Problem wirklich Resonanz erzeugt — bevor Zeit ins fertige Produkt floss. Erst danach der eigentliche Text: die Diagnose, der tatsächliche Zwei-Tage-Cleanup, und was an Governance danach nötig war, um das System sauber zu halten.
Lösung
Ein praktischer, dreiteiliger Leitfaden plus Checkliste für Figma-first-Teams ohne dedizierten Design-System-Owner — von der Selbstdiagnose bis zur laufenden Pflege.
Ergebnis
Ein praxisnaher Leitfaden, der Design-System-Wissen direkt anwendbar macht — für Teams, die nicht nur eine Komponentenbibliothek bauen, sondern ein System, das langfristig trägt.
Kunde
Eigenes Projekt
Tools & Techniken
Projektart