Zum Inhalt springen

15. Benutzerergonomie und UX

Zu Zen-Modus wechseln

Ihre Anwendung rechnet richtig, hält Angriffen stand und antwortet schnell. Es fehlt die Frage, an der die meisten Projekte scheitern, lange bevor jemand einen Fehler im Code findet: Kommt ein Mensch damit zurecht, der nicht dabei war, als sie gebaut wurde?

Diese Frage lässt sich beantworten, und zwar mit Verfahren statt mit Geschmack. Das ist der Punkt dieser zwei Wochen. „Ich finde das übersichtlich” ist eine Aussage über Sie und nicht über die Anwendung. Sie haben sie gebaut, Sie kennen jeden Menüpunkt, und Sie sind damit die am wenigsten geeignete Person, um über ihre Bedienbarkeit zu urteilen.

Was hier nicht vorkommt: Gestaltung im engeren Sinn. Farbklänge, Typografie und Bildsprache sind Medientechnik, Designsysteme und Komponentenbibliotheken kommen in der 5. Klasse. Hier geht es um Bedienbarkeit und Zugänglichkeit.

Gebrauchstauglichkeit ist nach ISO 9241 das Ausmaß, in dem bestimmte Benutzer bestimmte Ziele in einem bestimmten Kontext erreichen können, und zwar effektiv (das Ziel wird erreicht), effizient (mit angemessenem Aufwand) und zufriedenstellend (ohne Ärger). Die drei Wörter sind messbar: Erfolgsquote, Zeit und Anzahl der Fehlversuche, Rückmeldung der Testperson.

Benutzererfahrung ist weiter gefasst und schließt alles ein, was vor, während und nach der Benutzung passiert: die Erwartung beim ersten Aufruf, das Gefühl beim Warten, der Ärger über eine Fehlermeldung um 23 Uhr. Gebrauchstauglichkeit ist notwendig für eine gute Erfahrung und reicht nicht aus.

Vier Grundsätze aus derselben Norm tragen den Rest dieses Kapitels:

GrundsatzHeißt konkret
ErwartungskonformitätDer Knopf tut, was sein Text sagt. Eine Suche liegt oben. Ein Klick auf das Logo führt zur Startseite.
SelbstbeschreibungsfähigkeitMan sieht, wo man ist, was passiert und was als Nächstes möglich ist.
FehlertoleranzEin falscher Klick kostet keine Daten. Rückgängig geht vor Bestätigungsdialog.
SteuerbarkeitDer Benutzer bestimmt Tempo und Reihenfolge, nicht das System.

Dahinter steht das mentale Modell: die Vorstellung, die jemand von Ihrem System hat. Diese Vorstellung stammt aus allen anderen Programmen, die die Person kennt. Wenn Ihr Kalender die Woche mit Sonntag beginnt, während in Österreich jeder Kalender mit Montag beginnt, verlieren Sie bei jeder Benutzung eine halbe Sekunde und gelegentlich einen Termin.

Zehn Faustregeln von Jakob Nielsen sind seit den Neunzigerjahren der Standardwerkzeugkasten für die Bewertung einer Oberfläche. Sie ersetzen kein Testen mit Menschen, finden aber ohne Testpersonen einen großen Teil der Probleme.

HeuristikBeispiel aus dem Werkstattprojekt
Systemzustand sichtbarNach „Buchen” erscheint sofort eine Rückmeldung, nicht erst nach 800 ms
Sprache der Benutzer„Maschine ist zu dieser Zeit belegt” statt „Constraint violation”
Steuerbarkeit, NotausgangAus jedem Formular kommt man ohne Speichern wieder heraus
KonsistenzDie primäre Aktion steht überall rechts unten, nicht mal hier, mal dort
Fehler verhindernBelegte Zeiten sind gar nicht erst auswählbar
Erkennen statt erinnernDie gewählte Maschine steht im nächsten Schritt weiterhin sichtbar
FlexibilitätTastaturkürzel für die Werkstattaufsicht, die zwanzig Buchungen am Tag prüft
ReduktionDie Buchungsansicht zeigt keine Felder, die nur die Verwaltung braucht
Fehler verstehen und beheben„Ende liegt vor Beginn” mit Sprung ins betroffene Feld
HilfeErklärung dort, wo sie gebraucht wird, statt in einem Handbuch

Der Unterschied zwischen einer Bewertung und einem Meinungsaustausch liegt in der Form. Jeder Befund bekommt eine Heuristik, einen Ort, eine Beschreibung und einen Schweregrad.

Befund 07 - Buchungsformular
Heuristik: Fehler verhindern (5)
Beobachtung: Das Enddatum lässt sich vor dem Startdatum wählen.
Der Fehler erscheint erst nach dem Absenden.
Wirkung: Benutzer füllt das ganze Formular aus und bekommt es zurück.
Schweregrad: 3 (schwerwiegend, tritt bei jedem Fehlversuch auf)
Vorschlag: Enddatum-Auswahl auf Werte nach dem Startdatum begrenzen.

Der Schweregrad reicht von 0 (kein Problem) über 1 (kosmetisch), 2 (klein), 3 (schwerwiegend) bis 4 (Blockade, Benutzer kommt nicht weiter). Er ergibt sich aus drei Fragen: Wie oft tritt es auf, wie schwer kommt man daran vorbei, und häuft es sich für dieselbe Person?

Diese Zahl ist der Grund für das ganze Verfahren. Ohne sie diskutiert das Team drei Stunden über die Farbe eines Knopfes und behebt die Blockade nicht.

Fünf Personen finden den überwiegenden Teil der Probleme, drei sind für ein Schulprojekt genug. Wichtig ist die Form, nicht die Zahl.

  1. Aufgaben formulieren, keine Fragen.

    Falsch: „Findest du die Buchungsfunktion übersichtlich?” Darauf antwortet jeder höflich mit ja.

    Richtig: „Sie möchten morgen um 14 Uhr eine Stunde lang die Standbohrmaschine benutzen. Machen Sie das.” Kein Wort darüber, wo man klickt.

  2. Lautes Denken erklären. Die Testperson sagt, was sie gerade sucht, erwartet und denkt. Das ist ungewohnt und braucht eine Aufforderung zu Beginn und gelegentlich eine Erinnerung.

  3. Beobachten und nichts erklären. Die härteste Regel. Wenn jemand nicht weiterkommt, ist das das Ergebnis, nicht ein Zwischenfall. Auf die Frage „Wo muss ich da klicken?” antwortet man mit „Was würden Sie erwarten?”.

  4. Mitschreiben. Wo zögert jemand, wo klickt jemand falsch, wo kommt ein „hmm”, wo bricht jemand ab. Die Zeit pro Aufgabe notieren. Zu zweit testen ist einfacher: einer moderiert, einer schreibt.

  5. Auswerten. Beobachtungen zu Befunden zusammenfassen, Schweregrad vergeben, nach Wirkung sortieren.

Rechnen Sie damit, dass die erste Testperson wehtut. Man sieht zu, wie jemand an einer Stelle scheitert, die man selbst für offensichtlich gehalten hat, und muss den Mund halten. Genau dafür macht man es.

Wenn niemand verfügbar ist, bleiben zwei Verfahren am Schreibtisch.

Der Aufgabendurchlauf listet die Schritte einer typischen Aufgabe und zählt Klicks, Seitenwechsel und Formularfelder. Fünfzehn Klicks für eine Buchung sind ohne jeden Test ein Befund.

Der Kognitive Durchgang geht dieselben Schritte durch und stellt bei jedem drei Fragen: Weiß die Person in diesem Moment, was sie tun will? Sieht sie das nötige Bedienelement? Erkennt sie, dass dieses Element zu ihrem Ziel führt? Und nachdem sie geklickt hat, merkt sie, dass es funktioniert hat? Ein Nein an einer dieser Stellen ist ein Befund.

Beides ersetzt den Test mit Menschen nicht, weil Sie Ihr eigenes Vorwissen nicht abschalten können. Beides ist aber jederzeit machbar und billig.

Ungefähr jeder fünfte Mensch hat eine dauerhafte Beeinträchtigung, und deutlich mehr haben eine vorübergehende: ein gebrochener Arm, grelles Sonnenlicht auf dem Display, eine laute Werkstatt. Barrierefreie Bedienung nützt allen, und sie ist an vielen Stellen billiger einzubauen als nachzurüsten.

Die Web Content Accessibility Guidelines ordnen alles unter vier Prinzipien: wahrnehmbar (man kann es sehen oder hören), bedienbar (man kann es erreichen und auslösen), verständlich (man begreift es) und robust (Hilfsmittel wie Screenreader kommen damit zurecht).

Dazu drei Stufen: A ist das Minimum, AA der übliche Zielwert und die Grundlage aller einschlägigen Gesetze, AAA in Teilen kaum erreichbar. Ihr Ziel ist AA.

AnforderungPrüfung
Alles per Tastatur bedienbarNur mit Tab, Shift-Tab, Enter, Leertaste und Pfeiltasten durch die Anwendung
Fokus sichtbarWo steht der Fokus gerade? Wenn man das nicht sieht, ist der Test vorbei
Kontrast4,5:1 für Text, 3:1 für großen Text und Bedienelemente
TextalternativenJedes informative Bild hat einen Alternativtext, jedes dekorative ein leeres alt
ÜberschriftenstrukturEine h1 pro Seite, keine Ebene übersprungen
Beschriftete FelderJedes Eingabefeld hat ein verknüpftes label
Nicht nur FarbeEin roter Rahmen ohne Text sagt farbenblinden Benutzern nichts
Sprache ausgezeichnetlang="de" am html-Element, abweichende Passagen ausgezeichnet

Die meisten Barrieren entstehen nicht durch fehlende ARIA-Attribute, sondern durch HTML, das seine Bedeutung verloren hat.

<!-- not focusable, cannot be triggered with Enter,
for a screen reader just a container -->
<div class="button" onclick="book()">Book</div>
<!-- focusable, can be triggered with Enter and Space,
announced as a button, all without extra work -->
<button type="button" onclick="book()">Book</button>

Die erste Regel für ARIA lautet: Verwenden Sie kein ARIA, wenn ein passendes HTML-Element existiert. button, nav, main, label, table, fieldset und dialog bringen Fokusverhalten, Tastaturbedienung und Bedeutung mit. Ein div mit role="button" braucht tabindex, Tastaturbehandlung für Enter und Leertaste sowie einen zugänglichen Namen, und dann verhält es sich mit Glück so wie ein button.

Ein Detail, das häufig aus Versehen zerstört wird:

/* takes away the orientation for keyboard users */
:focus { outline: none; }
/* shows the ring only for keyboard use, not on a mouse click */
:focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }

Werkzeuge: die axe-Erweiterung für den Browser und der Barrierefreiheitsteil von Lighthouse. Beide melden fehlende Alternativtexte, zu schwache Kontraste, kaputte Überschriftenstrukturen und unbeschriftete Felder.

Von Hand: Legen Sie die Maus weg und gehen Sie mit Tab durch die Anwendung. Kommen Sie überall hin? Sehen Sie immer, wo Sie sind? Ist die Reihenfolge sinnvoll? Kommen Sie aus einem geöffneten Dialog wieder heraus? Danach starten Sie einen Screenreader (NVDA unter Windows, Orca unter Linux, VoiceOver auf dem Mac), schließen die Augen für dreißig Sekunden und lassen sich die Seite vorlesen.

Barrierefreiheit im Netz ist in Österreich für öffentliche Stellen seit 2019 über das Web-Zugänglichkeitsgesetz verpflichtend, das auf einer EU-Richtlinie beruht und als Maßstab WCAG auf Stufe AA heranzieht. Seit Mitte 2025 gilt zusätzlich das Barrierefreiheitsgesetz, mit dem der European Accessibility Act umgesetzt wurde: Es erfasst auch private Anbieter bestimmter Dienstleistungen, unter anderem den Online-Handel, mit Ausnahmen für Kleinstunternehmen. In Deutschland heißt das Gegenstück Barrierefreiheitsstärkungsgesetz.

Für Ihr Schulprojekt gilt das meist nicht unmittelbar. Für den Betrieb, in dem Sie danach arbeiten, sehr wohl, und dort ist es kein Bonuspunkt mehr, sondern eine Anforderung im Lastenheft.

Der Anteil mobiler Zugriffe liegt bei den meisten Anwendungen über der Hälfte. Trotzdem entsteht jede Oberfläche auf einem 27-Zoll-Bildschirm, und dort sieht sie natürlich gut aus.

Mobile zuerst heißt, mit der schmalen Ansicht zu beginnen. Das erzwingt eine Entscheidung darüber, was wirklich wichtig ist, und diese Entscheidung fällt auf dem großen Bildschirm nie, weil dort alles Platz hat.

Umbruchpunkte aus dem Inhalt: Verbreitern Sie das Fenster langsam und setzen Sie den Umbruchpunkt dort, wo die Darstellung anfängt, schlecht auszusehen. Gerätelisten veralten mit dem nächsten Modell.

Berührungsziele brauchen Fläche. Ein Finger trifft ungenauer als ein Mauszeiger, und ein Löschen-Knopf, der zwei Pixel neben dem Bearbeiten-Knopf liegt, wird verlässlich falsch getroffen.

Tabellen sind der schwierigste Fall. Eine Belegungstabelle mit sieben Spalten ist auf 375 Pixel Breite unlesbar. Die brauchbaren Wege: waagrecht scrollen mit fixierter erster Spalte, oder pro Zeile eine Karte mit Beschriftung neben dem Wert. Was nicht funktioniert, ist die Tabelle so weit zu verkleinern, bis sie hineinpasst.

Bildschirmtastaturen verdecken das halbe Fenster. Ein Formularfeld direkt über dem Absendeknopf ist dann unsichtbar. Dazu gehören die richtigen Feldangaben, weil sie die Eingabe spürbar erleichtern:

<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel"
inputmode="tel" autocomplete="tel" />

Kapitel 10 und 11 haben die technischen Zustände geliefert. Jetzt werden sie gestaltet. Jede Ansicht hat fünf davon, und vier werden regelmäßig vergessen.

ZustandWas zu sehen sein muss
LeerWarum hier nichts steht und was man als Erstes tun kann
LädtEin Skelett in der Form des kommenden Inhalts, kein Kreisel in der Mitte
FehlerWas schiefging, ob es an mir liegt, und der nächste Schritt
TeilweiseWas da ist, wird gezeigt; was fehlt, ist als fehlend erkennbar
GefülltDer Normalfall

Der Leerzustand ist die erste Erfahrung mit Ihrer Anwendung, weil am Anfang alles leer ist. „Keine Buchungen vorhanden” ist eine Sackgasse. „Sie haben noch keine Buchung. Wählen Sie eine Maschine aus, um zu beginnen” mit dem Knopf daneben ist eine Anleitung.

Bei Fehlermeldungen gilt: Sie beschreiben das Problem des Benutzers und nicht den Zustand des Systems.

StattBesser
„Fehler 500”„Das hat gerade nicht geklappt. Bitte in einer Minute noch einmal versuchen.”
„Validierung fehlgeschlagen”„Das Ende liegt vor dem Beginn.”
„Unauthorized”„Ihre Sitzung ist abgelaufen. Bitte neu anmelden.”
„Ungültige Eingabe”„Die Telefonnummer darf nur Ziffern enthalten.”

Wenn eine Meldung eine Korrelations-ID aus Kapitel 7 enthält, gehört sie klein und kopierbar daneben. Für den Benutzer ist sie Beiwerk, für Ihre Fehlersuche ist sie der Einstieg.

Beim Ladezustand zahlt sich Kapitel 13 aus: Ein Skelett in der Form des Inhalts vermeidet den Layoutsprung beim Eintreffen der Daten und wirkt schneller als ein Kreisel, obwohl die Daten gleich spät kommen. Für Aktionen, deren Ergebnis vorhersehbar ist, greift die optimistische Aktualisierung aus Kapitel 10: Die Oberfläche reagiert sofort und nimmt zurück, falls der Server widerspricht.

  1. „Sieht gut aus” als Prüfkriterium. Es ist keines, weil es nichts über die Benutzung sagt.
  2. Nur mit der Maus und nur am großen Bildschirm getestet.
  3. Farbe als einziger Bedeutungsträger. Rot allein ist für einen Teil Ihrer Benutzer kein Signal.
  4. div mit Klickereignis statt einer Schaltfläche.
  5. outline: none ohne Ersatz, und damit keine Orientierung bei Tastaturbedienung.
  6. Fehlermeldungen aus der Sicht des Systems, in der Sprache des Stacktrace.
  7. Leerzustand als leere Fläche.
  8. Testperson gerettet, sobald sie stockt. Damit ist der Befund weg und der Test wertlos.
  9. Nach Fragen statt nach Aufgaben getestet. Höfliche Antworten haben keinen Aussagewert.
  10. Befunde ohne Schweregrad, und danach wird über Kleinigkeiten diskutiert, während eine Blockade stehen bleibt.
  11. Barrierefreiheit am Ende eingeplant. Nachträglich kostet dasselbe Ergebnis ein Vielfaches.
  • Erklären: Gebrauchstauglichkeit und Benutzererfahrung unterscheiden und die Dialoggrundsätze an eigenen Beispielen erläutern.
  • Analysieren: eine Anwendung anhand der zehn Heuristiken bewerten und Befunde mit Schweregrad festhalten.
  • Anwenden: einen Bedienbarkeitstest mit Aufgaben und lautem Denken durchführen, ohne einzugreifen.
  • Analysieren: Beobachtungen zu priorisierten Befunden verdichten und daraus Änderungen ableiten.
  • Erklären: die vier WCAG-Prinzipien und die Bedeutung der Stufe AA wiedergeben.
  • Anwenden: Barrierefreiheitsmängel mit Werkzeugen und von Hand finden und beheben.
  • Anwenden: semantisches HTML statt nachgebauter Bedienelemente einsetzen und den Fokus sichtbar halten.
  • Anwenden: eine Ansicht mobil brauchbar machen, einschließlich Tabellen und Formularen.
  • Erschaffen: alle fünf Zustände einer Ansicht bewusst gestalten.

Ein Bedienbarkeitsbericht in docs/bedienbarkeit.md:

  • Heuristische Bewertung mit mindestens zehn Befunden samt Schweregrad, davon eine Bewertung durch ein anderes Team.
  • Bedienbarkeitstest mit drei Personen: Aufgabenstellungen, Beobachtungen, Erfolgsquote und Zeiten.
  • Priorisierte Befundliste mit Vermerk, was behoben wurde und was bewusst offen bleibt, mit Begründung.
  • Nachweis der Barrierefreiheit: axe- oder Lighthouse-Ergebnis vorher und nachher, Protokoll des Tastaturdurchgangs, geprüfte Kontraste.
  • Alle Hauptansichten in ihren fünf Zuständen, mit Bildschirmfotos.
  • Alle Hauptansichten auf 375 Pixel Breite benutzbar.
  • Aufgabe - Heuristische Bewertung im Tausch mit einem anderen Team
  • Aufgabe - Bedienbarkeitstest mit drei Personen
  • Aufgabe - Nur mit der Tastatur durch die eigene Anwendung
  • Aufgabe - Die fünf Zustände einer Ansicht