Die besten Design-System-Werkzeuge für kleine Teams
Ihr Produkt wirkt uneinheitlich. Buttons passen von Bildschirm zu Bildschirm nicht zusammen, Abstände driften von Seite zu Seite, und jede neue Funktion sieht aus, als käme sie aus einer anderen App. Also suchen Sie ein Design-System-Werkzeug und landen bei einer Liste von fünfzehn, ohne erkennen zu können, welches Ihren Fall löst.
Kurzfassung
Hat Ihr Team weniger als fünf Personen, haben Sie mit ziemlicher Sicherheit kein Werkzeugproblem. Sie haben ein Ursprungsproblem: die Bildschirme entstehen auf verschiedenen Wegen. Dann ist das richtige Werkzeug jenes, das Sie nicht pflegen müssen.
Die sechs unten lösen Verschiedenes, und der größte Teil des Frusts mit Design-Systemen entsteht daraus, eines zu wählen, das ein Problem löst, das man nicht hat.
Was ein Design-System-Werkzeug leisten muss
Ein Design-System hat vier Teile, und fast kein Werkzeug deckt alle vier ab:
- die Tokens, also die Entscheidungen: Farbe, Typo-Skala, Abstände, Eckenradius;
- die Komponenten, also diese Tokens angewandt auf ein wiederverwendbares Stück;
- die Dokumentation, die sagt, wann welches Stück zu verwenden ist und, wichtiger, wann nicht;
- den Abgleich, der dafür sorgt, dass Design und Code nach der dritten Woche noch dasselbe sagen.
Am vierten sterben Design-Systeme. Die ersten drei schafft man in einem Sprint. Der vierte ist für immer.
Die Kategorien, und für wen sie jeweils sind
Komponentenwerkstatt
Storybook. Sie entwickeln die Komponente losgelöst von der App, sehen alle Zustände nebeneinander, und die Dokumentation steht neben der laufenden Komponente. Es ist die einzige Kategorie, in der Dokumentation nicht von allein altert, weil sie der Code selbst ist.
Für wen: ein Team mit fester Front-end-Entwicklung. Schreibt niemand im Team React oder Vergleichbares, ist das nichts für Sie.
Design-Werkzeug
Figma. Hier entsteht das Design-System in den meisten Teams: die Komponenten, die Varianten, die Farb- und Abstandsvariablen. Es ist kein Design-System-Werkzeug, sondern ein Design-Werkzeug, das genug Funktionen bekommen hat, um eines zu werden.
Für wen: alle, die einen Designer haben. Die Frage ist nie, ob Sie Figma nutzen, sondern was Sie zusätzlich nutzen.
Dokumentationsseite
zeroheight und Supernova. Sie nehmen, was in Figma und im Code liegt, und veröffentlichen es als durchsuchbare Dokumentationsseite, mit Governance, Versionen und Freigabe.
Für wen: eine Organisation mit mehr als einem Produktteam, in der die Nutzer des Design-Systems dessen Autoren nicht kennen. Unterhalb dieser Größe ist es Infrastruktur für ein Problem, das Sie noch nicht haben.
Übergabe von Design an Code
Zeplin. Ordnet die Übergabe vom Design an die Entwicklung: Spezifikation, Maße, Assets, was sich seit der letzten Version geändert hat.
Für wen: Teams, in denen Design und Entwicklung verschiedene Personen mit verschiedenen Ritualen sind. Macht dasselbe Paar beides, fügt diese Schicht nur einen Schritt hinzu.
Seitenbaukasten mit eingebautem System
Framer. Sie bauen die Seite aus geteilten Komponenten und Stilen, und das veröffentlichte Ergebnis ist die Seite. Konsistenz entsteht konstruktionsbedingt, weil es keine zweite Umsetzung gibt, die von der ersten abweichen könnte. Merken Sie sich diesen Mechanismus: er ist das Interessanteste auf dieser ganzen Seite und kommt am Ende wieder, angewandt auf eine andere Art von Produkt.
Für wen: Marketing-Seiten, Portfolios, Landingpages. Nicht für eine Anwendung mit Daten und Anmeldung, und genau dort bleibt der Mechanismus ohne Eigentümer.
Vergleich
| Werkzeug | Wofür es zuständig ist | Passt zu |
|---|---|---|
| Storybook | Komponenten isoliert entwickeln und dokumentieren | Team mit fester Front-end-Entwicklung |
| Figma | Komponenten und Tokens erstellen | jedes Team mit Designer |
| zeroheight | Dokumentation für viele veröffentlichen | Organisation mit mehreren Teams |
| Supernova | Dokumentation plus Automatisierung von Tokens zu Code | Organisation mit Design-Governance |
| Zeplin | geordnete Übergabe von Design an Code | Teams mit getrenntem Design und Entwicklung |
| Framer | veröffentlichte Seite mit eingebauter Konsistenz | Marketing-Seiten und Landingpages |
Gesamtkosten: die Lizenz ist der billige Teil
Alle sechs haben einen kostenlosen oder günstigen Tarif für kleine Teams, und deshalb fühlt sich die Entscheidung leicht an, während man sie trifft. Die Preise ändern sich häufig und stehen hinter den Links am Ende dieser Seite.
Die Kosten, die niemand in die Tabelle schreibt, sind die anderen:
Jemand muss es pflegen. Ein Design-System ohne Eigentümer verrottet in einem Quartal. Jemand prüft die Komponenten, entscheidet die Ausnahmen, aktualisiert die Dokumentation, streitet mit dem Team, das gerade den zehnten Button gebaut hat. Das ist ein realer Bruchteil einer Person, jede Woche.
Zwei Wahrheiten driften auseinander. Die Komponente in Figma und die Komponente im Code sind zwei Umsetzungen derselben Idee, und sie driften. Immer. Ein Abgleichwerkzeug hilft und löst es nicht, denn was auseinandergeht, ist nicht der Farbwert, sondern eine Entscheidung über einen Zustand, den es nur im Code gibt.
Die Einführung geschieht nicht von selbst. Ein Design-System, das existiert und nicht genutzt wird, ist schlimmer als keines, denn nun gibt es zwei Wege für dieselbe Sache und ein Dokument, das behauptet, nur einer gelte.
Für ein Team aus zwei oder drei Personen sind diese Kosten mit dem Bau der Bildschirme vergleichbar. Deshalb stellen so viele Teams ein Design-System auf, nutzen es zwei Monate und lassen es liegen.
Wann Sie ein Design-System brauchen und wann nur Konsistenz
Das ist die Unterscheidung, die die meisten Listen auslassen, und sie entscheidet, ob Sie gut oder schlecht ausgeben.
Ein echtes Design-System brauchen Sie, wenn mehrere Menschen parallel Oberfläche bauen, in verschiedenen Codebasen oder Produkten, und einen gemeinsamen Vertrag brauchen. Das Design-System ist dieser Vertrag. Ohne ihn erfindet jedes Team seinen eigenen.
Nur Konsistenz brauchen Sie, wenn das Problem ist, dass Ihre Bildschirme einander nicht ähneln. Dann ist die Ursache kein fehlender Vertrag, sondern ein Übermaß an Ursprüngen: jeder Bildschirm entstand zu einem Zeitpunkt, auf eine Weise, aus einer spontanen Entscheidung.
Und Konsistenz hat eine billigere Lösung als einen Vertrag: einen einzigen Ursprung.
Konsistenz durch Konstruktion, ohne die Pflege
Hier kommen wir ins Spiel, und es sei gleich gesagt, dass wir Partei sind. Das Argument ist überprüfbar, urteilen Sie danach.
Es ist der Mechanismus von Framer, angewandt auf die Art von Produkt, die Framer nicht bedient. Wenn die ganze App aus einer Bibliothek erzeugt wird, kommt visuelle Drift gar nicht erst in Gang. Nicht weil jemand aufpasst, sondern weil es keinen zweiten Weg gibt, einen Button zu bauen.
Bei Fabapp nutzt die erzeugte App 57 fertige Komponenten, von der paginierten Tabelle über Datumsauswahl, Telefonfeld mit Maske je Land, Bild-Upload und Diagramm bis zum Bestätigungsdialog. Es sind dieselben Stücke auf allen Bildschirmen der App, mit denselben Theme-Tokens. Die vollständige Liste dessen, was die Plattform liefert, steht auf Funktionen.
Zwei Folgen, die alle interessieren, die schon einmal unter einem Design-System gelitten haben:
Das System weist zurück, was aus der Bibliothek fällt. Bevor die App kompiliert, lehnt eine statische Prüfung eine nicht existierende Komponente und eine erfundene Eigenschaft ab. Ein Design-System im Dokument hängt davon ab, dass jemand es liest; dieses hängt davon ab, dass der Code durchkommt.
Das Theme ist eine einzige Entscheidung. Farbe, Typografie und Radius kommen aus einem Token-Satz, der für die ganze App gilt. Die Primärfarbe zu ändern ist eine Änderung, kein Durchlauf.
Und für alle, die sich um den Ausstieg sorgen: die Komponenten liegen im Code Ihrer App, bearbeitbar, und der Code geht als ZIP oder Push nach GitHub ab dem Tarif Builder heraus. Sie tauschen nicht Design-System-Pflege gegen Plattformabhängigkeit.
Wo das nicht hilft. Ist Ihr Problem, vier Produktteams über bereits bestehende Codebasen zu koordinieren, hilft nichts davon: Sie brauchen den gemeinsamen Vertrag, und die Liste oben ist der Ort dafür. Ein einziger Ursprung behebt Drift, nicht Governance.
Wechseln, und was übrig bleibt
Wenn schon etwas steht, zwei Hinweise vor der Migration.
Tokens wandern, Komponenten nicht. Farbe, Abstand und Typografie sind Daten und reisen gut zwischen Werkzeugen. Komponenten tragen Umsetzungsentscheidungen und werden neu geschrieben, nicht verschoben. Planen Sie mit der zweiten Hälfte.
Verloren geht die Dokumentation. Der Text, der erklärt, warum es den tertiären Button gibt, liegt in keinem exportierbaren Format vor. Wenn er zählt, kopieren Sie ihn vor der Kündigung.
Bauen Sie die konsistente Oberfläche, die Ihr Produkt braucht
Wenn Sie ein Produkt hergeführt hat, das aussieht, als hätten es fünf verschiedene Leute gebaut, lohnt sich der billige Weg vor dem vollständigen: beschreiben Sie die App, die Sie wollen, und sehen Sie, wie viel Konsistenz umsonst herauskommt, wenn alle Bildschirme denselben Ursprung haben.
Bei Fabapp fragt der Free-Tarif nicht nach einer Karte.