Single Source of Truth, Many Points of Success: So profitieren UXD- und Tech-Teams von neu gedachten Design-Systemen

Die Message ist durchgedrungen: Eine gelungene User Experience zählt zu den Erfolgsfaktoren für Unternehmen. Um eine einheitliche UX über alle Touchpoints hinweg zu erreichen, helfen Design-Systeme. Bei den meisten von ihnen liegen historisch gewachsen Code, Design und Dokumentation in drei verschiedenen Quellen. Das hemmt nicht nur den Workflow zwischen Design und Entwicklung. Auch Mängel in der UX können sich ergeben. Doch neu gedacht können Design-Systeme ihr Problem selbst lösen: Als Single Source of Truth. Sie einzusetzen lohnt sich, zeigt die Erfahrung.

Single Source of Truth: Gedacht vom Workflow aus

Design-Systeme sind eine Art Bibliothek für Styles, Code und Regeln von wiederverwendbaren UI-Komponenten, also einzelne Elemente einer Benutzeroberfläche. Sie ermöglichen Konsistenz und eine effektive Skalierung des Designs über alle Touchpoints hinweg. Dafür sollte es flexibel, pflegeleicht und auf Skalierbarkeit konzipiert sein.

Weitere wichtige Voraussetzung: Alle Stakeholder ziehen mit. Hier gibt es ein großes »Aber«. Denn in der täglichen Zusammenarbeit zwischen Design und Entwicklung kann es immer mal wieder haken. Um zu verstehen wo, lohnt sich ein Blick auf den Workflow zwischen beiden Teams.

UX-Designerinnen und -Designer entwerfen zunächst neue UI-Komponenten, geben sie danach zum Programmieren an die Entwicklerinnen und Entwickler weiter. Die fertigen Komponenten übernehmen anschließend alle Parteien in ihr jeweiliges Design-System. Das zieht auch eine Aktualisierung von mindestens drei Orten mit sich:
• die Code-Basis des Entwicklungsteams,
• die Komponenten-Bibliothek im Prototyping-Tool des Designteams
• und die Dokumentation des Design-Systems.

Single Source of Truth statt Quellenchaos

Diese Orte bilden drei »Quellen der Wahrheit« für eine einzige UI-Komponente. Doch sind Arbeitsprozesse und Technologien nicht perfekt aufeinander abgestimmt, entsteht jede Menge redundante Arbeit. Denn jede einzelne Quelle braucht Aktualisierungen: eine einzige Änderung zieht also drei Updates nach sich.

Geschieht das nicht, besteht ein hohes Risiko dafür, dass sich Design-Schulden aufhäufen. Bedeutet: Die UX wird mit der Zeit immer inkonsistenter durch viele spontane Veränderungen und die Dokumentation veraltet. Je mehr Design-Schulden entstehen, umso größer ist der Aufwand, sie zu finden und abzuarbeiten.

Single Source of Truth zeigt, was sie kann

Doch all diese Probleme lassen sich ganz leicht umgehen: Warum nicht einfach Design, Code und Dokumentation, aus einer gemeinsamen Quelle der Wahrheit beziehen? Zeit für eine Single Source of Truth, eine einzige Quelle der Wahrheit mit mehreren Vorteilen. Mit ihr
• entstehen keine Inkonsistenzen,
• werden Code und Design automatisch synchronisiert – nur eine Änderung ist erforderlich,
• ist die Dokumentation immer aktuell,
• verbessert sich die Zusammenarbeit zwischen Design und Entwicklung.

Single Source of Truth bei Airbnb

Airbnb geht den ersten Schritt: Das Unternehmen entwickelte ein Tool, das eine der drei Quellen der Wahrheit eliminiert. Mithilfe der JavaScript-Bibliothek »React« konvertiert es programmierte Komponenten in Sketch-Dateien, also Vektorgrafiken. Damit entfällt eine große potenzielle Fehlerquelle, weil die Lösung Code-Komponenten automatisiert in das genutzte Prototyping-Tool überführt.

Außerdem muss niemand mehr die Komponenten per Hand nachbauen, um Design-Schulden abzuarbeiten. Designerinnen und Designer freuen sich, dass zeitintensive Dokumentation wegfällt. Sie können sich auf wichtigere, kreative Aufgaben konzentrieren und beispielsweise neue Komponenten gestalten. Blieben noch die Verwendungsregeln und Guidelines für UI-Komponenten. Wenn es möglich ist, sie im Code festzulegen und zu dokumentieren: Ziel erreicht! Eine einzige Quelle bleibt übrig. Möglich wäre das beispielsweise mit Storybook.js, einem Open Source Tool, um UI-Komponenten zu entwickeln.

Single Source of Truth: codebasiert ist State of the Art

Obwohl Airbnbs Tool schon einen großen Schritt in die richtige Richtung macht, bleibt immer noch Potenzial für Optimierungen: Nach der Konvertierung der entwickelten Komponente in das Sketch-Format unterliegt sie den Limitationen des Prototyping-Tools. Selbst dann sind aber die Repräsentationen im Code und im Prototyping-Tool nie exakt identisch. Hauptgrund dafür: Viele Prototyping-Tools sind vektor- oder bildbasiert, sodass der Code erstmal eine Konvertierung durchlaufen muss. So bleiben die Tools aber vor allem in Sachen Interaktivität hinter den Möglichkeiten von JavaScript zurück.

Noch besser eignen sich daher code-basierte Prototyping-Tools wie UXPin, die den Quellcode ohne Konvertierung eins zu eins verarbeiten können. Denn sie rendern den tatsächlichen Quellcode wie in einem Browser. Das stellt sicher, dass die Komponenten bei der Entwicklung und im Design pixelgenau gleich aussehen und sich auch gleich verhalten.

UXPin schafft es, als Prototyping Tool auf die Single Source of Truth in Storybook zurückzugreifen, indem es Coded Components tief integriert und Designerinnen und Designern zugänglich macht. Im Ergebnis steht hier eine perfekte Synchronisation von Code, Design und Dokumentation. Mit ihr wird außerdem möglich, dass
• Designerinnen und Designer als weitere QA-Instanz fungieren und Bugs aus der Entwicklung finden,
• Design und Entwicklung enger zusammenarbeiten,
• Prototypen für User Tests – mithilfe von interaktiven »High-Fidelity-Komponenten« schneller entwickelt werden.

Das führt nicht zuletzt dazu, dass die eingangs erwähnten Herausforderungen bewältigt sind. Optimalerweise entstehen dank der Single Source of Truth auch keine neuen Design-Schulden mehr. Bedeutet: Die Konsistenz des UX-Designs ist gewährleistet – und das auf dem aktuellen Stand.

Single Source of Truth: dotSource setzt mit guten Erfahrungswerten auf UXPin

Auch die Design- und Deliveryteams von dotSource setzen seit mehreren Jahren auf das Prototyping-Tool »UXPin«. Es integriert Code-Segmente entweder von Komponenten aus React oder auf Basis anderer Frameworks wie Vue, Angular oder Svelte via Storybook.

Designerinnen und Designer können UI-Elemente außerdem innerhalb von UXPin modifizieren. Dafür stellt ihnen die Entwicklung definierte Eigenschaften und Einstellungen bereit, die React Props oder Storybook Args.

Die Ergebnisse können sich sehen lassen! Mit der Modernisierung des Webauftritts der Leipziger Messe verbesserte das Projektteam von dotSource nicht nur die User-Experience. Auch die Gestaltungskomponenten bleiben dank der Single Source of Truth stets auf dem aktuellen Entwicklungsstand und mit dem Livesystem synchronisiert. Kurzum: das Design-System ist immer up to date .

Single Source of Truth mit dotSource: Best Practices »User Experience Design« jetzt kostenfrei herunterladen!

Erfahrt mehr über den Einsatz und den Mehrwert einer Single Source of Truth für euer Unternehmen. Das UX-Designteam freut sich auf eure Anfrage und steht euch nicht nur für eine umfassende Beratung zur Verfügung. Es unterstützt euch auch gerne direkt bei der Entwicklung eines eigenen Design-Systems für eure Brand. Profitiert von schnelleren Weiterentwicklungen, nahtlos von der Idee zum Code, und sorgt für eine konsistente User Experience.

Design-Systeme mit einer Single Source of Truth können echt was in Sachen Zusammenarbeit zwischen Design und Entwicklung reißen. Was für Unternehmen bleibt: Das Ziel, das User-Experience-Design zu optimieren. In den Best Practices »User Experience Design« lest ihr, wie eure Customer Experience weniger Absprünge und mehr Conversions generiert.

Füllt jetzt das Formular aus und erhaltet ein kostenfreies Exemplar direkt in euer Postfach!