Design-System für konsistente Oberflächen

Ein Design-System kann eine Website schwerer machen als gar keines. Der Mechanismus ist simpel: Ein verbreitetes CSS-Framework bringt unkomprimiert rund 190 KB mit. Eine typische Unterseite nutzt davon einen einstelligen Prozentsatz. Der Rest wird trotzdem übertragen, geparst und im Speicher gehalten, bei jedem Erstbesuch, auf jedem Gerät. Lighthouse weist das als ungenutztes CSS aus, und die Zahlen sind regelmäßig unangenehm. Das Versprechen des Design-Systems lautet Wiederverwendung, geliefert wird oft Vorratshaltung. Guideline 2.8 kennt dieses Problem und schreibt die Lösung ausdrücklich hinein.

Info

Das einzige Erfolgskriterium von Guideline 2.8

Design-System: Nutze ein Design-System bei großen Projekten oder bei solchen mit vielen Beteiligten, um Konsistenz, Performance und langfristige Nachhaltigkeit zu verbessern. Setze wiederverwendbare Komponenten ein, die auf Webstandards beruhen, lade für jede Seite und jede Funktion nur die tatsächlich benötigten Komponenten und pflege das System durch klare Zuständigkeiten, Versionierung und aktuelle Dokumentation. Folge etablierten Design-Mustern und Konventionen.

Meine Einordnung

In diesem einen Kriterium stecken vier Anforderungen, die unterschiedlich viel kosten und unterschiedlich viel bringen.

Die billigste steht am Ende: etablierten Mustern und Konventionen folgen. Das kostet null Byte. Ein Link, der aussieht wie ein Link. Eine Suche mit Lupensymbol im Kopfbereich. Ein Logo oben links, das zur Startseite führt. Diese Dinge muss niemand lernen, weil sie jeder schon kennt. Vertrautheit verlagert Verstehensarbeit vom Nutzer in eine Konvention, und ersparte Verstehensarbeit bedeutet weniger Klicks, weniger Seitenaufrufe, weniger übertragene Daten. Ich halte mich deshalb so weit wie möglich an Konventionen, auch dort, wo eine eigene Lösung schöner wäre.

Die zweite Anforderung ist die technisch entscheidende: nur laden, was gebraucht wird. Sie ist der Grund, warum ein Design-System keine Garantie für Effizienz ist. Ob es eine wird, hängt allein daran, ob die Auslieferung seitenweise erfolgt oder pauschal. Bei statisch erzeugten Seiten ist das vergleichsweise einfach, weil beim Build feststeht, welche Bausteine eine Seite tatsächlich verwendet.

Die dritte Anforderung, auf Webstandards zu setzen, ist eine Frage der Haltbarkeit. Ein System aus semantischem HTML, CSS-Variablen und wenigen eigenen Komponenten überlebt jeden Framework-Zyklus. Ein System, das an eine bestimmte Bibliotheksversion gebunden ist, altert mit ihr.

Und die vierte Anforderung, die bei Sustainable Web Design fehlt: Zuständigkeit, Versionierung, gepflegte Dokumentation. Ohne sie entsteht das, was ich in Projekten regelmäßig sehe: drei Varianten desselben Buttons, alle in Benutzung, keine offiziell.

Wo ich weiter gehe

Die Guideline knüpft das Design-System an eine Bedingung: große Projekte oder viele Beteiligte. Nach dieser Lesart bräuchte ich für datensm.art keines. Ich betreibe die Seite allein.

Ich halte die Bedingung trotzdem für zu eng gefasst, und zwar aus einem Grund, den die Guideline nicht bedenkt: Wiederverwendung endet nicht am Projektrand. Meine Template-Prinzipien sollen in andere Projekte wandern. Genau dann wird aus einer Sammlung von Dateien ein System, auch wenn nur eine Person daran arbeitet. Die vielen Beteiligten sind in diesem Fall meine eigenen künftigen Projekte.

Dafür braucht es aber keine Bibliothek.

Achtung
Sobald Dein Design-System eine Abhängigkeit ist, erbst Du deren Wartungszyklus. Jede Sicherheitsmeldung, jedes Major-Update, jeder Bruch in der Programmierschnittstelle wird zu Deiner Aufgabe, und zwar dauerhaft. Ein System aus eigenen Bausteinen auf Basis von Webstandards hat diesen Rattenschwanz nicht. Es altert langsamer, weil HTML und CSS langsamer altern als jedes Paket.

Was übertragbar sein muss, sind deshalb nicht Komponenten, sondern Entscheidungen: eine Farbe als Akzent statt einer Palette. Eine Abstandsskala statt beliebiger Pixelwerte. Eine Schriftfamilie. Eine Regel, wann ein Bild überhaupt eingebaut wird. Diese Festlegungen passen auf eine Seite Papier, sie kosten keine einzige Datei, und sie lassen sich in jedes neue Projekt übernehmen, unabhängig vom Werkzeug.

Der Nachhaltigkeitsgewinn eines Design-Systems liegt am Ende nicht in der Wiederverwendung von Code. Er liegt darin, dass eine einmal getroffene Entscheidung nicht in jedem Projekt neu diskutiert, neu gebaut und neu getestet wird.

Dein erster Schritt heute

Bevor Du ein System aufbaust, prüfe, wie viel von Deinem jetzigen tatsächlich ankommt.

Tipp
Öffne die Entwicklerwerkzeuge Deines Browsers und schau unter Coverage nach, wie viel Prozent Deines CSS und JavaScripts auf einer typischen Unterseite wirklich verwendet werden. Werte unter 20 Prozent sind verbreitet und Dein größter Hebel. Notiere Dir anschließend fünf Festlegungen, die Du in Deinem nächsten Projekt genauso wieder treffen würdest, und leg sie als kurze Textdatei neben Dein Template. Das ist der Anfang Deines Systems.

Ergänze dazu eine simple Übersichtsseite, auf der alle Bausteine einmal untereinander stehen. Sie kostet eine Stunde und ersetzt später jede Diskussion darüber, ob es diesen Baustein schon gibt.

Ein Design-System ist keine Bibliothek, die man einbindet, sondern eine Entscheidung, die man nicht jedes Mal neu trifft.

Quelle: W3C-Fassung von Guideline 2.8