Eine Benutzerschnittstelle aus Nutzeraufgaben verbessern

Ein Formular, das seine Aufgabe versteckt

Die Nordlicht Service GmbH verleiht Notebooks an Beschäftigte. Wenn ein Gerät defekt ist, melden Mitarbeitende den Schaden über ein internes Portal. Der vorhandene Bildschirm enthält eine lange Überschrift, sechs gleich auffällige Kacheln, ein Formular und drei Schaltflächen mit den Beschriftungen “Weiter”, “Abschicken” und “Abbrechen”.

Im Arbeitsalltag treten dabei immer dieselben Fragen auf:

• Muss zuerst ein Gerät gewählt oder der Schaden beschrieben werden?
• Welche Angaben sind Pflichtfelder?
• Wurde die Meldung nach dem Absenden wirklich gespeichert?
• Was ist zu tun, wenn die Inventarnummer nicht erkannt wird?
• Kann eine begonnene Meldung später fortgesetzt werden?

Das Problem ist nicht zuerst die Farbe der Schaltflächen. Die Oberfläche bildet die Nutzeraufgabe nicht verständlich ab. Eine Nutzeraufgabe ist das Ziel, das eine Person in ihrer Situation erreichen will. Hier lautet es: “Ein defektes Leihgerät so melden, dass der IT-Service den Austausch vorbereiten kann.”

Diese Formulierung gibt dem Entwurf eine Richtung. Alles, was die Aufgabe unterstützt, bekommt einen erkennbaren Platz. Alles andere wird nachgeordnet, ausgelagert oder entfernt.

Für die Lektion brauchst du kein Designwerkzeug. Du solltest grundlegende Formularelemente wie Eingabefeld, Auswahlfeld und Schaltfläche kennen. Wir entwerfen den Ablauf und prüfen seine Wirkung, nicht seine technische Implementierung.

Beginne mit Handlung, Person und Ergebnis

Eine Oberfläche wird verständlicher, wenn du vor dem Zeichnen drei Fragen beantwortest:

1. Wer handelt? Eine beschäftigte Person mit einem defekten Leihgerät. Sie kann unter Zeitdruck stehen und kennt interne Gerätenamen möglicherweise nicht.
2. Was will die Person erreichen? Eine vollständige Schadensmeldung absenden und wissen, wie es weitergeht.
3. Was braucht der Betrieb als Ergebnis? Eine Meldung mit eindeutigem Gerät, Fehlerbeschreibung, Erreichbarkeit und gewünschtem Übergabeort.

Damit kannst du den Ablauf auf die nötigen Entscheidungen reduzieren:

1. Gerät identifizieren.
2. Problem beschreiben.
3. Rückgabe oder Austausch organisieren.
4. Angaben prüfen und absenden.
5. Bestätigung mit Vorgangsnummer und nächstem Schritt erhalten.

Das ist noch kein Bildschirm. Es ist ein Nutzerfluss, also eine sinnvolle Folge von Schritten vom Einstieg bis zum Ergebnis. Erst danach entscheidest du, ob alle Schritte auf einer Seite stehen oder auf mehrere Ansichten verteilt werden.

Informationshierarchie lenkt die Aufmerksamkeit

Informationshierarchie bedeutet, dass Bedeutung und Reihenfolge erkennbar werden. Die wichtigste Frage ist nicht, welches Element am größten aussehen soll. Entscheidend ist, was eine Person zuerst verstehen und als Nächstes tun muss.

Für die Schadensmeldung ergibt sich diese Hierarchie:

1. Zweck der Seite: “Defektes Leihgerät melden”.
2. aktueller Schritt und Fortschritt: “1 von 4: Gerät auswählen”.
3. nötige Eingaben und kurze Hilfen.
4. primäre Aktion für den nächsten Schritt.
5. sekundäre Optionen wie “Entwurf speichern” oder “Zur Übersicht”.
6. ergänzende Hilfe und Kontaktdaten.

Wenn Überschrift, Hilfe, Navigation und Aktionen gleich auffällig sind, muss die Person die Hierarchie selbst rekonstruieren. Ein ruhiger Entwurf ordnet verwandte Inhalte räumlich zusammen und trennt verschiedene Aufgaben. Überschriften und sichtbare Beschriftungen benennen ihren Zweck. Abstände, Schriftstufen und Kontrast unterstützen diese Ordnung, ersetzen sie aber nicht.

Ein primärer Button steht für die zentrale nächste Aktion, etwa “Weiter zur Problembeschreibung”. Ein sekundärer Button bietet eine Alternative wie “Entwurf speichern”. Die Bezeichnung beschreibt das Ergebnis der Aktion. “Weiter” allein ist schwächer, weil die Person erst aus dem Umfeld ableiten muss, wohin es weitergeht.

Eine Oberfläche besteht aus Zuständen, nicht nur aus dem Normalfall

Ein statischer Entwurf zeigt oft nur den idealen Moment: Daten sind vorhanden, die Verbindung ist schnell und jede Eingabe ist gültig. Eine reale Oberfläche muss jedoch auf unterschiedliche Situationen reagieren. Für jedes wichtige Element solltest du mindestens diese Zustände prüfen:

Ein Zustand braucht mehr als eine andere Farbe. Text und Semantik müssen erklären, was passiert ist. Ein Ladesymbol ohne Beschriftung kann offenlassen, welcher Bereich lädt. Ein roter Rahmen ohne Fehlermeldung benennt weder das Feld noch den nächsten Schritt.

Der Ablauf lässt sich als kleine Zustandsfolge darstellen:

Der Fehlerpfad gehört zum Entwurf. Wenn eingegebener Text nach einem Verbindungsfehler verschwindet, ist die Aufgabe unnötig schwer. Wenn derselbe Button während des Sendens mehrfach ausgelöst werden kann, entstehen möglicherweise doppelte Meldungen. Der Ladezustand sollte daher Rückmeldung geben und eine doppelte Ausführung verhindern, ohne die Person in einem unklaren Zustand festzuhalten.

Formulare erklären Eingabe, Fehler und Korrektur

Ein Formular ist kein Stapel freier Felder. Jede Eingabe braucht eine verständliche Beschriftung. Zusätzliche Hinweise erklären Format oder Zweck, wenn die Beschriftung allein nicht reicht.

Für die Inventarnummer ist diese Kombination tragfähig:

• sichtbare Beschriftung: “Inventarnummer”,
• Formathinweis: “Du findest sie auf dem Aufkleber unter dem Gerät, zum Beispiel NB-2048.”,
• konkrete Fehlermeldung: “Gib die Inventarnummer im Format NB-1234 ein.”,
• Korrekturmöglichkeit: Das Feld bleibt ausgefüllt und erhält den Fokus nicht überraschend während der Eingabe.

Ein Platzhalter wie “NB-1234” ersetzt keine Beschriftung. Er verschwindet beim Tippen und kann seinen Zweck verlieren. Auch “Ungültige Eingabe” ist zu allgemein. Die Person müsste selbst erraten, welcher Teil falsch ist.

Die WCAG 2.2 formuliert dafür überprüfbare Anforderungen. Wenn ein Eingabefehler automatisch erkannt wird, muss das betroffene Element identifiziert und der Fehler in Text beschrieben werden. Wo Eingaben verlangt werden, müssen Beschriftungen oder Anweisungen vorhanden sein. Wenn eine Korrekturmöglichkeit bekannt ist, soll sie auf Konformitätsstufe AA angeboten werden, sofern dadurch Sicherheit oder Zweck nicht gefährdet werden.

Rückmeldung muss ankommen, ohne den Kontext zu zerstören

Nach dem Absenden reicht ein grüner Haken nicht. Farbe darf laut WCAG 2.2 nicht das einzige Mittel sein, um Information oder Zustand zu vermitteln. Eine Textmeldung wie “Meldung NS-2048 wurde gespeichert” trägt die Aussage auch ohne Farbe.

Statusmeldungen sollen außerdem programmatisch bestimmbar sein, damit assistive Technologien sie ausgeben können, ohne dass der Fokus dafür verschoben werden muss. Für den Entwurf bedeutet das: Plane eine erkennbare Statusregion ein und beschreibe ihre Nachricht. Die konkrete technische Umsetzung folgt später, zum Beispiel mit passenden Rollen oder Eigenschaften im Markup.

Eine gute Fehlerrückmeldung beantwortet drei Fragen:

1. Was ist passiert?
2. Wo liegt das Problem?
3. Was kann die Person jetzt tun?

“Die Inventarnummer wurde nicht gefunden. Prüfe die Nummer oder gib das Gerät als unbekannt an” erfüllt alle drei Punkte. “Fehler 4187” hilft nur dem Support, wenn der Code zusätzlich dokumentiert wird. Er ersetzt nicht die verständliche Meldung.

Accessibility wird in den Entwurf eingebaut

Accessibility bezeichnet hier die Zugänglichkeit der Weboberfläche für Menschen mit unterschiedlichen Fähigkeiten und unterstützenden Technologien. Sie ist keine nachträgliche Sonderansicht. Viele Entscheidungen entstehen bereits im Ablauf und Wireframe.

Für die Schadensmeldung sind besonders diese Prüfungen relevant:

• Struktur: Überschriften, Gruppen, Beschriftungen und Beziehungen müssen nicht nur optisch, sondern auch programmatisch bestimmbar oder als Text verfügbar sein.
• Tastatur: Alle Funktionen müssen ohne Maus bedienbar sein, sofern die Aufgabe nicht wesentlich von einem Bewegungspfad abhängt. Die Fokusreihenfolge soll Bedeutung und Bedienbarkeit erhalten.
• Sichtbarer Fokus: Eine Person muss erkennen können, welches bedienbare Element gerade den Tastaturfokus besitzt.
• Nicht nur Farbe: Pflichtfelder, Fehler und Auswahlzustände brauchen zusätzlich Text, Form, Symbol oder programmatische Information.
• Kontrast: Normal großer Text braucht auf Stufe AA grundsätzlich mindestens 4,5:1 Kontrast. Für großen Text gilt grundsätzlich mindestens 3:1. Ausnahmen stehen im Erfolgskriterium 1.4.3.
• Reflow: Bei vertikal scrollendem Inhalt muss die Darstellung grundsätzlich bei einer Breite von 320 CSS-Pixeln ohne Informations- oder Funktionsverlust und ohne zweidimensionales Scrollen funktionieren. Ausgenommen sind Inhalte, deren Nutzung oder Bedeutung ein zweidimensionales Layout verlangt.
• Zielgröße: WCAG 2.2 fordert auf Stufe AA für Zeigerziele grundsätzlich mindestens 24 mal 24 CSS-Pixel oder ausreichenden Abstand beziehungsweise eine der genannten Ausnahmen.

Diese Kriterien sind überprüfbar. “Sieht modern aus” oder “nutzt den aktuellen Designtrend” ist dagegen kein belastbares Qualitätskriterium. Ein Trend kann als gestalterische Inspiration dienen, aber er beweist weder Verständlichkeit noch Zugänglichkeit.

Usability wird an einer Aufgabe beobachtet

Usability beschreibt, wie gut bestimmte Personen mit einem Produkt in einem bestimmten Nutzungskontext ihre Ziele wirksam, effizient und zufriedenstellend erreichen können. Für unseren Entwurf reicht deshalb die Frage “Gefällt dir die Seite?” nicht. Eine Testperson braucht eine konkrete Aufgabe:

“Dein Leihnotebook zeigt nach dem Start nur einen schwarzen Bildschirm. Melde das Gerät NB-2048 für einen Austausch am Standort West. Du möchtest per E-Mail erreichbar sein.”

Während der Bearbeitung beobachtest du zum Beispiel:

• Wird die Aufgabe ohne fremde Hilfe abgeschlossen?
• An welcher Stelle stockt die Person oder wählt einen falschen Weg?
• Werden Pflichtangaben und die primäre Aktion verstanden?
• Kann die Person einen Eingabefehler selbst korrigieren?
• Erkennt sie nach dem Absenden, dass die Meldung gespeichert wurde?
• Kann sie am Ende in eigenen Worten sagen, was als Nächstes passiert?

Vor dem Test legst du Erfolgskriterien fest. Für dieses Szenario könnte das Team bestimmen: Die Meldung gilt als abgeschlossen, wenn das richtige Gerät, eine verwertbare Fehlerbeschreibung, Standort und Kontaktweg gespeichert sind und die Testperson die Vorgangsnummer findet. Dauer und Fehlerzahl werden erfasst, aber nicht ohne Vergleichswert als “gut” oder “schlecht” bewertet.

Ein kleiner Test mit wenigen Personen kann konkrete Probleme im Entwurf sichtbar machen. Er liefert jedoch keine repräsentative Aussage über alle späteren Nutzenden. Du dokumentierst deshalb Kontext, Aufgabe, Beobachtung und abgeleitete Änderung. Eine Äußerung wie “Das ist unübersichtlich” wird erst handlungsfähig, wenn du festhältst, wo die Person gesucht hat und welche Information gefehlt hat.

Verbessere nach Ursache, nicht nach Geschmack

Angenommen, drei Testpersonen suchen die Schaltfläche zum Absenden schon im ersten Schritt. Das ist kein Beleg dafür, dass “Menschen große Buttons mögen”. Wahrscheinlicher ist eine falsche Erwartung durch Beschriftung oder Hierarchie.

Eine nachvollziehbare Verbesserungskette sieht so aus:

Die Änderung folgt aus einer beobachteten Ursache. Danach wird genau dieselbe Aufgabe erneut geprüft. So kannst du beurteilen, ob die Änderung das Problem tatsächlich reduziert oder nur anders aussehen lässt.

Ein kompakter Prüfdurchgang für deinen Entwurf

Bevor ein Wireframe in die Umsetzung geht, kannst du ihn in sechs Schritten prüfen:

1. Aufgabe: Ist klar, wer welches Ergebnis erreichen will?
2. Ablauf: Baut jeder Schritt auf dem vorherigen auf und gibt es einen erkennbaren Abschluss?
3. Hierarchie: Sind aktuelle Aufgabe, Eingaben und nächste Aktion zuerst verständlich?
4. Zustände: Sind Laden, Leer, Fehler, Erfolg und deaktivierte Aktionen mitgedacht?
5. Zugänglichkeit: Sind Struktur, Tastaturweg, Fokus, Textalternativen zu Farbe, Kontrast und Reflow prüfbar?
6. Beobachtung: Gibt es eine konkrete Testaufgabe mit einem vorab festgelegten Erfolgskriterium?

Damit steht ein begründeter Entwurf. Er ist noch kein fertiges Produkt. Visuelles Design, technische Umsetzung, Sicherheitsanforderungen, automatisierte Tests und Tests mit weiteren Nutzungskontexten bleiben eigene Arbeitsschritte.

Belegmatrix

Quellenbasis und Abgrenzung

Der Rahmenlehrplan ordnet die Gestaltung und Entwicklung von Benutzerschnittstellen dem Lernfeld 10a zu. Die Ausbildungsordnung trägt die ergonomische Gestaltung und Anpassung an Kundenanforderungen über die Berufsbildposition B1. Der Prüfungskatalog nennt Softwareergonomie, Benutzeroberflächen, Usability, User Experience und Mock-ups als mögliche Themenbreite. Die ausgewerteten Beispielprüfungen wurden ausschließlich genutzt, um wiederkehrende Aufgabenformen wie Mängelanalyse und Verbesserungsskizze zu erkennen. Szenario, Daten, Aufgaben und Lösungen dieser Lektion sind neu erstellt.

Die konkreten Accessibility-Aussagen beziehen sich auf die W3C Recommendation WCAG 2.2 mit Stand 12. Dezember 2024. Die Lektion behandelt ausgewählte Erfolgskriterien, keine vollständige Konformitätsprüfung und keine Rechtsberatung. Sie macht außerdem keine Designtrends zu Regeln. Technische Qualitätssicherung und Softwaretests werden nur abgegrenzt und in einer eigenen Lektion vertieft.