Design System

Bereits Jahrzehnte bevor wir responsive Webseiten gestalteten setzten sich Grafiker*innen mit Raster, Muster und Beziehung der Elemente auseinander. Visuelle Gestaltung ist ein Rhythmus, den es in die entsprechende Form und zum passenden Kontext gebracht werden muss.

Besonders im Corporate Design (Branding) versteht man die Relevanz von konsistenter Design-Logik, die sich für unterschiedliche Anwendungen erschliessen muss.

Design-Systeme erfordern heutzutage aber zusätzlich ein Umgang mit der Responsiveness und den Interaktiven Prozesse innerhalb einer einzelnen Gestaltung. Sowie die Abhängigkeiten in ein Ökosystem von Programmen, Webseiten, Apps und Screens, welche stetig ändern.

Im digitalen Zeitalter funktionieren diese CD-Manuals nicht mehr. Dies aus verschiedenen Gründen.

Neuer Arbeitsprozess

CD-Manuals werden am Ende eines CD-Prozesses erstellt. Sie manifestieren das Endresultat, statt eine integrale und skalierbare Anwendungshilfe für die Entwicklung zu bleiben. Digitale Projekte wachsen über die Jahre, das Design muss sich organisch, diesen Veränderungen anpassen.

Teamwork

Das Design wurde ein Teil eines vielschichtigen in sich fliessenden Arbeitsprozesses. Wo endet Design und beginnt die Frontend-Programmierung und wie spielt das Backend mit? Ein ganzes Projekt-Team oder gar mehrere Projekt-Teams müssen zusammenarbeiten.

Skalierbarkeit

Um adäquat auf die responsiven Inhalte, Komponenten, Weiterentwicklungen sowie Viewports zu reagieren wird ein Designsystem Modular aufgebaut.

Spielregeln statt Positionen

CD-Manuals weisen vor allem zwei Dinge aus. Erstens, Millimeter genaue Positionierungen und zweitens die Abbildung möglicher Falschanwendungen.

Was jedoch meist nicht vorkommt, sind die Spielregeln der einzelnen Design-Atome, ihre Beziehung zueinander und die Abhängigkeiten zu den Bedürfnissen.

Diese Spielregeln gelten sowohl für die Elemente einer Gestaltung sowie für das Spielregelfindung innerhalb eines Teams.

Terminologie und Taxonomie

Es ist essentiell, das Teams lernen die gleiche Sprache wie auch die gleiche Prioritäten zu haben.

Argumente statt Vorlieben

Die beste Gestaltung entsteht im Diskurs. Die besten Argumente sollten den Stichentscheid erhalten. Dabei soll möglichst wissenschaftlich debatiert werden. So dass konsistente Design-Logiken entstehen.

Spielregeln für Gestaltungselemente

Ein jedes Element innerhalb einer Gestaltung (Atome, Molekül oder Organ) sollte seine Spielregeln erhalten, so dass seine Abhängigkeiten und sein Einsatzgebiet erklärt werden.

Building Blocks (Atome)

Die Einzelnen Bestandteile aus Design und Technik werden definiert. Typografie, Farbpalette, Icons, Bilder, Buttons, etc.

Pattern Library (Module, Moleküle, Komponenten)

Aus den Atomen werden Module, Komponenten oder Templates erstellt. Daraus können ganze Webseiten zusammengebaut oder Ableitungen für Neuentwicklungen gefunden werden.

Rules (Principles)

Die Regeln aus Design, Animation, der technischen Implementation wie auch Regeln für die Editoren (Autoren) werden definiert.

Style Guide

Der Style Guide ist die Beschreibung, wie das Design System gebraucht und weitergebaut werden soll. Es fokussiert auf den Workflow für den Unterhalt und nicht das finale Produkt. Für einmal ist der Inhalt die Gestaltung selbst.

Single Source of Truth

Damit ein Design System funktioniert, muss es Online sein und als einzige Quelle von Richtlinien dienen. Editierbarkeit muss passend zum Unternehmen geregelt werden.

Element Snippets

Nebst den visuellen Abbildungen und der Beschreibung von Elementen, sollte der dazugehörige Code wie auch allfällige Designfiles verfügbar sein, um direkt damit zu arbeiten. Sind Animationen, Effekte oder Abfolgen vorhanden sind diese ebenso zu zeigen.

Overview & Guidelines

Die Struktur von Atomen, Elementen, Modulen, Komponenten und Templates sollte sich logisch abgebildet finden. Terminologie wie Abhängigkeiten sollten klar geregelt sein. Wer, wann und wie Anpassungen und Ergänzungen macht, sollte verständlich und sauber beschrieben sein.

Agnostic

Ein Design System sollte unwissend über die Anwendung bleiben. Also es sollte keine Rolle spielen mit welchem Design-Tool, welcher JS-Library oder Framework gearbeitet wird. Der Fokus steht auf den Spielregeln der Gestaltung und des Brands selbst. Dies ermöglicht es nachhaltig und teamübergreifend zu bleiben.

Design Systeme müssen bei Projektbeginn in den Arbeitsprozess einfliessen. Dies bedeutet einen grösseren Initial-Aufwand. Dafür erhält man:

Skalierbarkeit

Die Modularität ermöglicht es vom MVP (minimal viable product) zur multifunktionaler Webseite zu wachsen.

Konsistenz

Ein Design System ermöglicht durch seine Struktur eine bessere Konsistenz von Design und Code über alle Anwendungen hinweg. Die Konsistenz liegt auch in der Sprache innerhalb der Teams über Namen, Module etc.

Gleichzeitigkeit

Design Systeme erlauben parallel von allen Arbeitsbereichen her zu arbeiten. Alle Füttern gemeinsam das System und wenden es an.

Geschwindigkeit

Ein funktionierendes Design System kann wie Bootstrap als Design-Library für Entwickler eingesetzt werden und ermöglicht ein deutlich schneller Umsetzung von Projekten.

Orchestrieren

Wir müssen lernen, als Dirigent*in das Gestaltungsorchester zu leiten. Wir erstellen vor allem die visuellen Prinzipien und Spielregeln nicht nur das eigentliche finale Design.

Anatomie

Webseiten sind auf einer klaren Anatomie aufgebaut. Design Systeme bauen auf der gleichen Logik weiter. Alle Elemente müssen individuell wie auch miteinander stimmig bleiben.

Responsiveness

Wir können nicht alle Viewport-Grössen und Seitentypen gestalten. Wir sind gezwungen Schemen zu erarbeiten, welche modular und responsive sind. So werden nur die wichtigsten Seiten und Module gestaltet und danach als Templates und Komponenten in der Pattern Library abgelegt.

Teamwork

Webarbeit ist Teamarbeit. Jedes Projektteam hat ihren eignen Workflow. Die Anwendung innerhalb des Projektteams bleibt aber individuell. Ein Design System geht auf diesen Workflow ein.

Mir persönlich gefallen die Design-System-Webseiten, welche einem auf einer Metaebene abholen und nicht direkt mit den Building Blocks oder Pattern Library anfangen.