Designsysteme am echten Ablauf beurteilen
Die Zahl der Komponenten sagt wenig über ihren Nutzen. Ein Bestellbutton zeigt, welche Zustände gemeinsam geregelt werden müssen.
Beurteilen Sie ein Designsystem daran, ob seine Bausteine wiederkehrende Aufgaben zuverlässig unterstützen. Die Zahl gezeichneter Komponenten ist dafür ein schwacher Maßstab. Ein einzelner Bestellbutton zeigt bereits, wie viel zwischen einer schönen Ansicht und brauchbarem Verhalten liegt.
Das folgende Beispiel ist erfunden. Ein Kundenportal erhält einen sorgfältig gestalteten Button „Bestellung senden“. Abstände, Farbe und Schrift stimmen. Für den Entwurf gilt die Komponente als fertig. Was nach dem Auslösen einer Anfrage geschieht, ist noch offen.
Dieselbe Ansicht deckt unterschiedliche Ergebnisse nicht ab
Situation im Beispiel | Was die Oberfläche vermitteln muss |
|---|---|
Anfrage wird verarbeitet | Der Vorgang läuft; erneutes Auslösen wird passend zum Ablauf behandelt. |
Server bestätigt die Bestellung | Bestellreferenz B-42 und bestätigter Status werden angezeigt. |
Server weist eine ungültige Menge zurück | Die Menge bleibt sichtbar; eine verständliche Korrektur ist möglich. |
Verbindung bricht nach dem Absenden ab | Ergebnis ist unklar; der Bestellstatus muss geprüft werden. |
Ein roter Button beantwortet die letzte Situation nicht. Die Bestellung könnte bereits angelegt sein. Ebenso belegt ein grüner Haken ohne bestätigte Antwort keinen Erfolg. Das ist eine Frage der richtigen Information, nicht nur der Gestaltung.
Gemeinsames Verhalten und Produktregeln zusammenführen
Die Komponente kann eine sichtbare Fokusanzeige, Platz für längere Beschriftungen und eine Darstellung der Verarbeitung bereitstellen. Der Bestellablauf muss dagegen wissen, welche Mengen zulässig sind und wie ein unklarer Serverausgang geklärt wird. Diese Regeln lassen sich nicht in einem allgemeinen Button lösen.
Das WAI-ARIA-Handbuch erklärt einen ähnlichen Zusammenhang: Eine Rolle beschreibt erwartete Bedeutung, implementiert aber keine Tastaturinteraktion. Auch gemeinsame Gestaltungswerte, etwa eine benannte Textfarbe als Design-Token, ersetzen weder Verhalten noch die Anbindung zwischen Design und Code.
Ein deaktivierter Button ist außerdem nicht für jeden Fehlerzustand die richtige Antwort. GOV.UK weist auf mögliche Verständnisprobleme hin. Wenn eine Aktion gesperrt wird, braucht die Person eine nachvollziehbare Erklärung und einen erreichbaren nächsten Schritt.
Die notwendige Tiefe hängt vom Einsatz ab
Eine statische Informationsseite braucht keinen Bestellstatus. Ein rein darstellendes Logo benötigt keine Zustandsmaschine für Serveranfragen. Es wäre unnötiger Pflegeaufwand, jedem Baustein dieselben Varianten aufzuzwingen.
Umgekehrt kann eine vorhandene, getestete Komponentenbibliothek diese Bedürfnisse bereits gut abdecken. Dann ist ihre passende Einbindung oft sinnvoller als ein eigener Nachbau. Die Bewertung würde sich ändern, wenn die tatsächlichen Abläufe mit vorhandenen Komponenten nachweislich nicht verständlich abgebildet werden können.
Nehmen Sie deshalb einen wiederkehrenden Ablauf in der implementierten Oberfläche ab, einschließlich Fehler und längerer Übersetzungen. Im Beispiel ist die Komponente erst dann brauchbar eingebunden, wenn auch die Person mit unklarem Bestellergebnis weiß, was sie als Nächstes tun kann. Das Verhindern doppelter Bestellungen erfordert zusätzlich passende Serverregeln; ein gesperrter Button allein reicht dafür nicht.
Quellen
Geschrieben von
- Julia HoffmannRedakteurin für Design und UXJulia Hoffmann ist bei ASES für die redaktionellen Inhalte zu Design und User Experience zuständig. Ihre Beiträge behandeln die Nutzung von Websites und Anwendungen, die Gestaltung von Benutzeroberflächen und digitale Barrierefreiheit.
Weiterlesen
Alle Beiträge
Ihr Vorhaben mit ASES
Beschreiben Sie uns Ihr Vorhaben. Wir melden uns mit einer ersten Einschätzung.