Wie wir Design-Systematiken und Bibliotheken (XD, Sketch, Figma etc.) in Website-Projekten einsetzen

Von Jonas

Wir dokumentieren in XD-Bibliotheken die übergreifenden Systematiken eines Layouts. Auf Grundlage detaillierter Design Tokens und Komponenten arbeiten wir weniger detaillierte Screens und Prototypen aus, die im Frontend »gerade gezogen« werden.

Aktualisiert am 5. Dezember 2023 7 Kommentare

Die Organisation von UI-Bibliotheken ist seit geraumer Zeit fester Bestandteil des digitalen Design-Workflows. Wir arbeiten insgesamt sehr Frontend-orientiert – was bedeutet, dass wir immer schnellstmöglich mit Code im Browser gestalten – dennoch nutzen auch wir statische Grafik-Tools. Im Folgenden möchten wir anhand von Adobe XD ein paar Einblicke geben, welche Herangehensweise sich für uns als sinnvoll erwiesen hat. Die Ansätze sind grundsätzlich auf Sketch und Figma übertragbar. Wir nutzen XD als Beispiel, da sich herausgestellt hat, dass XD für unsere Kunden momentan die höchste Relevanz hat.

Design-Systematiken früh erkennen und in einer Bibliothek organisieren

Benutzeroberflächen für Websites oder Applikationen sind modular aufgebaut. Es muss nicht zwingend ein sehr kleinteiliger Ansatz wie z.B. Atomic Design verfolgt werden, aber irgendeine Form von Systematik ist immer vorhanden. Kleine Komponenten werden zu größeren Komponenten verbunden. Daraus ergeben sich Seitentypen für verschiedene Displaygrößen, ggf. mit Varianten usw.

Es ist extrem wichtig, diese Systematik frühzeitig zu erkennen und mit den technischen Anforderungen – z.B. dem CMS – abzugleichen. Einerseits, damit man weiß, welche Komponenten im Design-Tool bzw. im Code gebaut werden sollen, aber auch um das Projekt sinnvoll im Projekt Management führen zu können. Wir arbeiten als Agentur regelmäßig an neuen Projekten mit neuen Kunden. Es hat sich als hilfreich herausgestellt, dass Stakeholder auf Kundenseite die Systematiken und die sich daraus ergebenen Vorteile und Abhängigkeiten verstehen. Wir können dann besser kommunizieren und einzelne Komponenten besprechen, freigeben lassen und optimieren.

In der Regel starten wir mit Workshops in ein Projekt. In diesen Workshops erarbeiten wir – häufig live im Termin mit XD – sehr grobe Protoypen. Wir besprechen die Anforderungen und skizzieren parallel in XD die dafür notwendigen Komponenten und Seitentypen. Wichtig ist an dieser Stelle, dass wir wiederkehrende Elemente von Beginn an in XD als Komponenten anlegen. Dadurch wird allen Projektbeteiligten vor Augen geführt, dass Websites sich aus Einzelteilen zusammensetzen und dass Änderungen an einer Komponente überall Auswirkungen haben, wo diese Komponente im Einsatz ist. Klar ist auch: Je mehr Komponenten und Zustände, desto abwechslungsreicher desto teurer.

In der ersten Phase des Projekts ist es für uns wichtig, das Projekt »aus der Vogelperspektive« mit all seinen Komponenten und Seitentypen betrachten zu können. Wir erkennen dann Inkonsistenzen, können ähnliche Komponenten zusammenfassen und die Aufwände schätzen.

Design Tokens erstellen und im Bibliotheks-Dokument ablegen

Als Design Tokens werden die übergreifenden gestalterischen Charakteristika bezeichnet, die für das Erstellen und Pflegen eines Design-Systems benötigt werden. Es sind beispielsweise die Basiswerte für Abstände, Abrundungen, Farben, Animationen etc., die an zentraler Stelle definiert und unabhängig von einzelnen Komponenten gepflegt werden.

In modernen Grafik-Tools lassen sich Design Tokens leider nicht adäquat pflegen. Zwar können Systematiken für Farben und Schriften mit entsprechenden Stilen zentral abgelegt werden, aber Kriterien wie Linienstärken, Schatten-Hierarchien, Abrundungen, Abstände etc. müssen i. d. R. händisch dokumentiert werden.

Wir erstellen daher an zentraler Stelle im XD-Dokument entsprechende Zeichenflächen und dokumentieren die Tokens. Im Team ist kommuniziert, dass dort die exakten Werte zu finden sind. Bei der Gestaltung einzelner Komponenten und Screens steht die Pixel Perfektion weniger im Vordergrund. Natürlich gestalten wir nicht absichtlich mit Inkonsistenzen. Aber wir wollen effizient arbeiten. Wir haben uns also darauf verständigt, dass in der Entwicklung die Screens und Komponenten als gute Skizze zu verstehen sind. In der Umsetzung werden Inkonsistenzen daher »gerade gezogen«. Als Orientierung dienen die Tokens, die i. d. R. in Form von Variablen im Code definiert werden.

Adobe XD exportiert Farben und Schriften einer Bibliothek beim Developer-Export in Form von CSS-Variablen. Auch DSPs (Design-System-Packages) von XD erzeugen u. a. CSS-Variablen. Damit diese Variablen einen Mehrwert bieten, müssen alle abgelegten Systematiken sinnvoll benannt werden. Eine Benennung nach Hierarchie oder Einsatzzweck hat sich als sinnvoll herausgestellt – z.B. --introtext oder --copytext. Namen, die auf visuelle Eigenschaften oder auf HTML-Sematik eingehen, sind nicht sinnvoll (z.B. --h1 oder --green-button).

Layouts auf Basis des 8 Point-Grids erstellen

Ähnlich wie bei den Tokens haben wir uns auch beim Gestaltungsraster auf einen Standard geeinigt – das 8 Punkt/Pixel Raster. Wir arbeiten weniger mit spaltenbasierten Layouts als vielmehr auf Grundlage eines Kästchenrasters. Alle Abstände zwischen Elementen und Schriften werden in Werten definiert, die durch acht teilbar sind.

Das hat in der technischen Umsetzung mit CSS den Vorteil, dass sehr gut mit em bzw. rem-Einheiten gearbeitet werden kann (Browserstandard = 1em = 16 Pixel). Auch hier werden in der Umsetzung mögliche Inkonsistenzen behoben. Wenn beispielsweise irgendwo der Abstand zwischen zwei Elementen 22 Pixel beträgt, ist klar: Das werden 24 Pixel (3×8) usw. Um die Details kümmern wir uns dann im Browser.

Komponenten »Mobile First« gestalten

Bei der Gestaltung von Komponenten gehen wir immer vom »Worst Case« aus. Wir gestalten daher alle Komponenten so, dass die »Primär-Komponente« auf kleinster möglicher Fläche bei gleichzeitig maximaler inhaltlicher Befüllung erstellt wird.

Nehmen wir als Beispiel die Darstellung einer Veranstaltung auf Übersichtsseiten. Wir beginnen mit der Gestaltung der Komponente auf kleinster möglicher Fläche. Das ist häufig nicht die Smartphone-Breite, denn hier stehen uns ca. 300 Pixel Breite für die Komponente zur Verfügung. Auf geringfügig größeren Displays ist die Darstellung allerdings häufig schon zweispaltig. Ein Display mit beispielsweise 580 Pixeln Breite und zweispaltigem Layout bietet weniger als 300 Pixel Platz für eine Komponente. Wir gehen daher lieber davon aus, dass uns nur 250 Pixel Breite zur Verfügung stehen.

Inhaltlich bestücken wir die Komponente nun so, dass alle Eventualitäten abgebildet sind: Der Titel ist zu lang, das Event geht über mehrere Monate und mehrere Tage,  usw …

Mit den Resizing-Funktionen von XD wird die Primär-Komponente so konfiguriert, dass Instanzen dieser Komponente horizontal und vertikal größer gezogen werden können. Dadurch entstehen niemals Darstellungsfehler. Inhaltlich gehen wir ähnlich vor. Da die Primärkomponente alle theoretisch vorkommenden Inhalte in maximaler Länge beinhaltet, ist es leicht, in den Instanzen der Komponente die Texte zu kürzen bzw. Bestandteile zu löschen. Auch dadurch können niemals Darstellungsprobleme eintreten.

Bei der Organisation der Bibliothek gehen wir wie folgt vor: Jede Komponente bekommt eine eigene Zeichenfläche. Oben links auf dieser Zeichenfläche liegt immer die Primärkomponente. Darunter bzw. daneben platzieren wir dann alle Varianten, die diese Komponente einnehmen kann. Das können Varianten in Breite und Höhe sein, wenn es um Responsive Design geht, das können Zustände sein, wenn es sich um interaktive Elemente wie Buttons handelt. Wichtig ist, dass wir an zentraler Stelle den vollständigen Umfang der Komponente auf einen Blick sehen können.

In den verschieden Screens des Projekts arbeiten wir dann ausschließlich mit Instanzen, die an die jeweiligen Gegebenheiten angepasst werden. I. d. R. wird die Komponente in der Breite angepasst und die Inhalte verändert.

Breakpoints und Viewport-Größen »Mobile First« organisieren

Ähnlich wie bei den Komponenten gehen wir auch bei verschiedenen Viewport-Größen immer »Mobile First« vor. Je nachdem, wie viele verschiedene  Ansichten (Breakpoints) ein Layout erhalten soll, erstellen wir entsprechend viele Zeichenflächen dafür. Jede dieser Zeichenflächen markiert die schmalste Ausprägung der jeweiligen Layoutvariante. Bis zur nächst größeren Zeichenfläche müssen sich alle Elemente ausdehnen können. Durch die oben beschriebene Organisation von Komponenten sollte dies allerdings ohnehin gewährleistet sein.

Wir gestalten normalerweise nur exemplarische Ansichten und nicht alle Seitentypen in allen Breakpoints. Oft reicht uns in der technischen Umsetzung schon eine grobe Skizze, da alle Komponenten ja an zentraler Stelle dokumentiert sind. Es ist für uns also nicht notwendig, auch noch zusätzlich alle Screens zu sehen. Diese Vorstellungskraft besitzen wir im Team. Bei der Arbeit mit externen Auftraggebern mag das anders sein.

Visuelles Prototyping mit vielen kurzen Flows

Wir nutzen die Prototyping-Funktionen meist, um relativ kurze »Flows« zu zeigen. So zeigt ein Flow beispielsweise, wie die Hauptnavigation funktioniert. Ein anderer Flow zeigt z.B. das Verhalten eines Filters und wieder ein anderer Flow visualisiert ein Scrolling-Verhalten. Die detaillierten Gestaltungs- und Animationsmöglichkeiten in den Design-Tools nutzen wir also eher für einzelne Details, die konkret visuell ausgearbeitet werden.

Wir haben kein Interesse daran, einen funktional sehr umfangreichen und gleichzeitig detailliert gestalteten Prototyp zu entwickeln, in dem alle Eventualitäten visualisiert werden können. Diese Herangehensweise ist uns zu ineffizient vor dem Hintergrund, dass es sich »nur« um Grafiken und Videos, jedoch nicht um ein funktionierendes Produkt handelt.

Das hängt auch damit zusammen, dass wir immer parallel zur visuellen Arbeit im Grafik-Tool bereits eine grobe funktionale Version der Website im Browser erstellt haben. Anhand von Anwendungsszenarien (User Stories) definieren wir, welche Flows dort getestet werden müssen. Dieses Testing findet dann bereits im Browser statt – was für uns effizienter und sinnvoller ist.

XD ist für uns also eher ein Tool für visuelles Prototyping. Es findet selten ein User Testing umfangreicher Szenarien anhand von XD Screens statt. Auch laufen bei uns technisches Prototyping im CMS und visuelles Prototyping im Grafik-Tool immer parallel ab. 

Zentrale Kommunikation im Team

Wir nutzen Jira als Projektmanagementsoftware und erstellen Tickets/Stories für einzelne Komponenten oder Flows. Aus XD werden diese einzelnen Flows dann in die Adobe Cloud exportiert und mit dem Jira-Ticket verknüpft.

Wir nutzen darüber hinaus auch sehr stark die Video-Funktion von XD. Prototypen oder Effekte einzelner Komponenten und Screens werden als Video abgefilmt und im Jira-Ticket zur Diskussion gestellt.

Zusammenfassung

Wie beschrieben, nutzen wir ein Grafik-Tool wie z. B. XD nicht, um exakte Vorgaben für die Entwicklung zu erstellen. Daher sind auch die Developer-Exporte von XD (ebenso wie die von Figma und Sketch) für uns nicht mehr als ein nette Unterstützung. Damit im Developer-Export exakte Werte abgelesen werden könnten, müsste zuvor sehr akkurat gestaltet werden. Das ist uns zu zeitaufwändig – vor allem da die verschiedenen Browser ohnehin leichte Abweichungen in der Interpretation des Codes haben und es daher nicht »das eine« Endergebnis gibt.

In XD erstellen wir eine sehr gute Planungsskizze für das Projekt. Diese ist Grundlage für unsere Kommunikation. Alles ist sichtbar. Alle Farben, Stile, Komponenten, Zustände, Templates etc. Aber nicht zwingend in Form konkreter Screens, sondern als Design Systematik. Wir dokumentieren, wie sich Komponenten im Responsive Design verhalten sollen und wie Zustände aussehen. Je weiter das Projekt fortgeschritten ist, desto detaillierter und umfangreicher wird die Bibliothek. Die höchste Form der Ausarbeitung ist die Erstellung einer XD-Bibliothek, mit der ein Kunde selbstständig neue Screens erstellen kann, bzw. ein Frontend-Styleguide.

Detaillierte Beschreibungen einiger Projekte haben wir anhand von Case Studies aufbereitet. Unsere Herangehensweise sollte dort gut erkennbar sein.

Geschrieben von Jonas

Jonas ist Gründer der Agentur kulturbanause und des kulturbanause Blogs. Er arbeitet an der Schnittstelle zwischen UX/UI Design, Frontend und Redaktion und hat zahlreiche Fachbücher und Video-Trainings veröffentlicht. Jonas Hellwig ist regelmäßig als Sprecher auf Fachveranstaltungen anzutreffen und unterstützt mit Seminaren und Workshops Agenturen und Unternehmen bei der Planung, der Gestaltung und der technischen Umsetzung von Web-Projekten.

Jonas Hellwig bei Xing