Design- und Entwicklungsprozesse optimieren mit Storybook
Vom Entwurf zur Realität
Entwicklung und Design erfolgreich vereinen
Brücken zwischen Entwicklern und Designern zu schlagen, ist aufgrund unterschiedlicher Perspektiven, Herangehensweisen und Prozesse oft eine Herausforderung. Häufig gehen die Vorstellungen beider Gewerke auseinander: Designer haben eine andere Vorstellung von der Funktionalität von Komponenten, während Entwickler diese oft anders umsetzen, als es das Design vorgibt. Mit Storybook haben wir bei MAXIMAGO eine Lösung gefunden, um diese beiden Bereiche besser zu synchronisieren. Storybook lässt sich als Teil eines Designsystems verstehen, das mittlerweile in der Software-Entwicklung unverzichtbar ist.
Große Unternehmen wie Google mit Material Design, IBM mit Carbon oder Adobe mit Spectrum haben umfangreiche Designsysteme entwickelt, um Design und Entwicklung zu vereinheitlichen, zu optimieren und in allen Software-Produkten bereitzustellen. In diesem Blogbeitrag beleuchten wir die Schlüsselfaktoren und Vorteile von Storybook für Entwickler und Designer und zeigen, wie es den gesamten Produktlebenszyklus verbessern kann.
Wie funktioniert Storybook?
Storybook ist ein Open-Source-Tool zur Entwicklung und kontextfreien Visualisierung von Komponenten. Innerhalb von Storybook können angefertigten Komponenten losgelöst von einer Anwendung visualisiert und interagierbar gemacht werden. In Storybook werden Komponenten in den Namensgebenden Stories umgesetzt. Eine Story besteht in den meisten Fällen hierbei aus einer Ansicht der Komponente und einer Reihe an Interaktionsmöglichkeiten (Controls), um den Zustand zu ändern. Die Komponente kann innerhalb der Story isoliert und kontextunabhängig implementiert werden. Alle Änderungen, die über die Controls eingestellt werden, können live angeschaut werden. So kann mit Storybook eine interagierbare Dokumentation einer Komponente angelegt werden.
Storybook für Entwickler
Entwickler können innerhalb der Stories über Controls die Zustände einer Komponente konfigurieren. Zustände können hier z.B. bestimmte Farben, Interaktion mit Komponenten oder Inhalte sein. Alle gewünschten Zustände werden bei der Implementierung der Story mit angelegt. So können Entwickler ohne großen Mehraufwand eine Komponente implementieren und parallel testen und erweitern. Jede Konfiguration einer implementierten Komponente kann innerhalb der Story als Code-Beispiel angezeigt werden. Dies spart nicht nur Zeit, sondern fördert auch die konsistente Wiederverwendung aller Komponenten.
Storybook für Designer
Designern wiederum hilft Storybook eine entwickelte Komponente mit dem gewünschten Design zu vergleichen oder auch Einsicht über die möglichen Zustände und Funktionen einer Komponente zu erhalten. Für den einfacheren Vergleich können auch Design-Tools wie Figma in Storybook eingebunden werden, um direkt innerhalb einer Story, Side-by-side, eine Komponente zu betrachten. Gefundene Fehler oder Änderungswünsche können dann auf Basis der Story direkt von den Designern als URL an die Entwickler weitergegeben werden.
Qualitätssicherung durch Storybook
Auch die Qualitätssicherung kommt nicht zu kurz. Ebenfalls können die Stories eingesetzt werden, um Komponenten auf mehreren Ebenen automatisiert oder manuell zu testen beispielsweise für visuelle Regressionstests, Snapshot-Tests, Zugänglichkeitstest oder Interaktionstests. Diese Tests fallen alle mehr in den Bereich von End-to-End-Testing. So kann selbst auf kleinsten Komponentenebenen eine hohe Qualität gewährleistet werden.
Storybook als zentrale Anschlaufstelle
Storybook bietet bei richtiger Anwendung eine hervorragende Dokumentation für alle Beteiligten. Während der Entwicklung lassen sich Stories mit zusätzlichen Informationen wie Beschreibungen anreichern, um die Dokumentation kontinuierlich zu erweitern. So können auch Details zugänglich gemacht werden, die normalerweise nicht angezeigt werden.
Bietet das Design unterschiedliche Themes (z. B. Dark- und Light-Mode) oder verhält sich je nach Display-Größe anders, ermöglicht Storybook das einfache Wechseln zwischen diesen Varianten, um alle Einsatzmöglichkeiten zu testen.
Abschließend dient Storybook nicht nur der Komponentendokumentation, sondern kann auch als Nachschlagewerk für das gesamte Designsystem genutzt werden. Mit Markdown können Stories um weiterführende Informationen ergänzt werden, die über die reine Implementierung hinausgehen, und so alle Aspekte des Designsystems – von Farben bis zu vollständigen Seiten – dokumentiert werden.
Wann man auf Storybook setzen sollte
- Das Designsystem besteht aus vielen Komponenten, Themen und Variationen, die dadurch einfach einsehbar und testbar werden.
- Entwicklern wird eine ‚Spielwiese‘ für das Designsystem geboten, die Live-Interaktionen und aktuelle Codebeispiele ermöglicht.
- Designern wird die Möglichkeit gegeben, das Umgesetzte im Detail zu betrachten und einen direkten Vergleich zwischen Design und Implementierung zu ziehen.
- Wenn eine interaktive und hochwertige Dokumentation gewünscht ist.
- Um die Inhalte des Designsystems verständlicher zu machen und die Wiederverwendbarkeit zu fördern.
- Die Möglichkeit, losgelöst vom Frontend einer Anwendung zu arbeiten, ist besonders in frühen Projektphasen nützlich, in denen viele grundlegende Änderungen anfallen.
Wann der Einsatz von Storybook nicht sinnvoll ist
Bei Projekten mit kleinem Umfang, d.h., wenigen Komponenten, einem Theme und geringen oder keinen Variationen.
Bei Projekten, die kein Designsystem verwenden.
Die Einarbeitung in Storybook erfordert Zeit, sodass die Komplexität der UI-Entwicklung steigen kann.
Der Nutzen von Storybook hängt stark von der Qualität der Dokumentation ab.
