Block 09 · Benutzeroberfläche

A · Erklärungssatz

Aufgaben zur Benutzeroberfläche standen in 5 der 9 ausgewerteten Prüfungen, und zwar immer in Teil 1. Meist sind sie Teil einer größeren Aufgabe und bringen zusammen 7–18 Punkte. Typisch sind vier Aufgabenarten: ein Mockup skizzieren oder ergänzen (oft in einem vorgedruckten Smartphone- oder Browserrahmen), die Mängel eines Entwurfs finden und ihn verbessern, Barrierefreiheit (Anforderungen und Maßnahmen) und Usability (Begriffe, Tests). Der Belegsatz enthält zu diesem Block nichts – alles hier musst du selbst können.

In der Themenanalyse bilden die drei Unterthemen zusammen das Thema „GUI / Mockup / Barrierefreiheit“ (Oft, 5/9). Damit genug geübt wird, ist es hier aufgeteilt. Die Kategorien der Teilthemen sind nach denselben Regeln berechnet (Wahrscheinlich = 2–3 von 9, davon mindestens einmal in S24–S26).

GUI-01 · Mockup, Wireframe & GUI-Elemente Oft

Vorkommen: 4/9 · Prüfungen: W22 (T1 A3a, Gestaltungselemente), W23 (T1 A4b, Darstellungsform + Skizze), S24 (T1 A4bb, verbessertes Mockup), S26 (T1 A4c, Vorteile von Mockups + Smartphone-Mockup ergänzen)

So sieht die Aufgabe aus

• Mockup ergänzen: Ein leerer Smartphone- oder Browserrahmen ist vorgedruckt, oft schon mit Titelzeile, Zurück-Pfeil oder Menüleiste. Dazu stehen zwei bis fünf Anforderungen im Text („Auf der Seite sollen … angezeigt werden“). Du zeichnest die Elemente ein (S26: 6 P, S24: 7 P).
• Darstellungsform wählen: Zwei Darstellungsformen für bestimmte Daten nennen, sich für eine entscheiden, begründen und dann mit Beispieldatensätzen skizzieren (W23: 2 + 2 + 4 P).
• Wissensfragen: Vorteile von Mockups beschreiben (S26: 4 P), Gestaltungselemente beschreiben (W22: 3 P).

Wireframe, Mockup und Prototyp

Alle drei sind Entwürfe der Benutzeroberfläche, bevor programmiert wird. Sie unterscheiden sich im Detailgrad (englisch Fidelity: Low-Fidelity = grob, High-Fidelity = nah am Endprodukt) und darin, ob man sie bedienen kann.

Zwei Begriffe aus dem Prototyping solltest du einordnen können: Ein horizontaler Prototyp zeigt viele Masken der Oberfläche, aber ohne Logik dahinter. Ein vertikaler Prototyp setzt eine einzelne Funktion vollständig durch alle Schichten um (Oberfläche, Logik, Datenbank). Ein Wegwerf-Prototyp dient nur zur Klärung und wird danach verworfen, ein evolutionärer Prototyp wird zum Produkt weiterentwickelt.

Vorteile und Grenzen von Mockups

Grenzen: zusätzlicher Aufwand; der Kunde hält einen realistisch aussehenden Entwurf leicht für „fast fertig“ (Erwartungen klären); Mockups zeigen weder Ladezeiten noch Logik; es droht eine Diskussion über Farben statt über Funktionen.

GUI-Elemente und ihr Einsatz

Für Skizzen und für Fragen wie „Welches Element eignet sich?“ brauchst du einen festen Baukasten. Abbildung A-2 zeigt die wichtigsten Elemente so, wie du sie in der Prüfung schnell zeichnen kannst.

Darstellungsform für Daten wählen

Bevor du dich entscheidest, beantworte drei Fragen: Welche Daten (Anzahl, Text oder Zahl, Zeitbezug, Ortsbezug, Bilder)? Was will der Nutzer damit tun (Überblick, vergleichen, suchen, Lage erkennen, Entwicklung verfolgen)? Auf welchem Gerät?

Beispiel: Der Lieferdienst „Blitzkurier“ hat 40 E-Transporter. Die Disposition will wissen, wo die Fahrzeuge sind, welchen Status sie haben und wie voll ihr Akku ist. Abb. A-3 zeigt dieselben vier Fahrzeuge in vier Darstellungsformen.

Welche Form richtig ist, hängt von der Aufgabe ab: Soll die Disposition entscheiden, welches freie Fahrzeug einem Abholort am nächsten ist, ist die Karte richtig – Entfernungen sieht man sofort, Status und Akku erscheinen beim Antippen des Pins. Sollen dagegen alle Fahrzeuge mit niedrigem Akku gefunden werden, ist eine nach Akkustand sortierbare Tabelle besser. Das Diagramm eignet sich für den schnellen Vergleich weniger Werte, die Kacheln für eine App, in der der Fahrer „sein“ Fahrzeug antippt.

Responsive Design und Mobile First

Responsive Design heißt: Eine Oberfläche passt ihr Layout automatisch an Bildschirmgröße und Ausrichtung an – mit denselben Inhalten und einer Codebasis für Smartphone, Tablet und Desktop. Typische Techniken und Anpassungen:

• flexible Raster (CSS Grid/Flexbox) mit relativen Breiten statt fester Pixelmaße; Breakpoints per Media Query (z. B. unter 600 px, 600–1023 px, ab 1024 px)
• relative Schriftgrößen (rem), Bilder skalieren mit (max-width: 100%)
• mehrspaltige Layouts werden einspaltig; die Menüleiste wird zum Hamburger-Menü oder zur Tab-Bar
• Tabellen zeigen nur die wichtigsten Spalten oder werden zu einer Liste von Karten
• Filter und Zusatzinfos werden eingeklappt; Touch-Ziele werden größer; Hover-Funktionen erhalten eine Alternative

Mobile First heißt: Der Entwurf beginnt beim kleinsten Bildschirm. Weil dort nur das Wichtigste Platz hat, muss man priorisieren. Größere Bildschirme werden danach schrittweise ergänzt (Progressive Enhancement). Vorteile: Fokus auf die Kernfunktionen, gute Ladezeiten auf Mobilgeräten – und die meisten Nutzer sind mobil unterwegs. Davon abzugrenzen ist Adaptive Design: feste Layouts für einige wenige Gerätegrößen.

So skizzierst du ein Mockup in der Prüfung

1. Anforderungen markieren: Jede geforderte Information und Funktion im Aufgabentext unterstreichen und nummerieren. Für jede gibt es Punkte – also muss jede als sichtbares Element in der Skizze vorkommen.
2. Vorgaben übernehmen: Vorgedruckte Teile (Titel, Zurück-Pfeil, Menüleiste) nicht ändern, sondern im gleichen Stil weiterzeichnen.
3. Grob aufteilen: oben Orientierung und Auswahl (Titel, Filter), in der Mitte der Inhalt (das Wichtigste zuerst und groß), unten die Aktion (Primärbutton, beim Smartphone im Daumenbereich).
4. Passende Elemente wählen (Baukasten oben) und sauber als Kästen zeichnen: Bilder als Kasten mit Kreuz, Diagramme mit beschrifteten Achsen.
5. Beispieldaten eintragen („Rückgabe bis 14.05.“ statt „Text Text“) – so sieht der Prüfer, dass du die Daten verstanden hast.
6. Am Rand beschriften: Was nicht selbsterklärend ist, mit Pfeil erläutern („Tippen öffnet Kalender“, „Liste scrollbar“).
7. Kontrolle: Alle Anforderungen abgehakt? Klare Beschriftungen, Rückmeldung, Abbrechen möglich? Status als Text statt nur als Farbe, große Schaltflächen?

GUI-02 · Barrierefreiheit Wahrscheinlich

Vorkommen: 3/9 · Prüfungen: W21 (T1 A3ab, Begriff erläutern), W22 (T1 A3b, inklusives Design: Schrift und Farbe), S26 (T1 A4b, zwei Anforderungen + Maßnahmen in einer Tabelle)

Begriff

Software ist barrierefrei, wenn Menschen mit Behinderungen sie in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe finden, wahrnehmen, verstehen und bedienen können (angelehnt an § 4 Behindertengleichstellungsgesetz, BGG). Dazu nutzen viele Menschen Hilfsmittel: Screenreader (liest den Bildschirm vor), Braillezeile, Bildschirmlupe, Spracheingabe, Spezialtastaturen. Die Software muss so gebaut sein, dass diese Hilfsmittel funktionieren.

Rechtlicher Rahmen (Kurzfassung)

Die WCAG (Web Content Accessibility Guidelines) sind Richtlinien des W3C. Aktuell ist Version 2.2 (2023). Sie enthalten prüfbare Erfolgskriterien in drei Stufen: A (Mindestanforderungen), AA (der übliche gesetzliche Standard) und AAA (höchste Stufe).

Die vier Prinzipien der WCAG

Anforderungen und Maßnahmen

In der Prüfung werden Anforderung (was muss erfüllt sein?) und Maßnahme (wie setze ich es um?) getrennt verlangt. Die Tabelle ist dein Vorrat.

Beispiel in HTML: Ein Screenreader kann nur vorlesen, was im Code steht.

<!-- schlecht -->
<!-- Bild-Button ohne Namen,
     per Tastatur nicht erreichbar -->
<div class="btn" onclick="senden()">
  <img src="pfeil.png">
</div>

<!-- nur Platzhalter, kein Label -->
<input type="text"
       placeholder="E-Mail">

<!-- gut -->
<label for="mail">E-Mail-Adresse *</label>
<input id="mail" type="email"
       aria-describedby="mail-fehler">
<p id="mail-fehler">Bitte vollständige
   Adresse eingeben, z. B. name@web.de</p>
<button type="submit">
  Leseausweis beantragen</button>
<img src="cover.jpg"
  alt="Buchcover: Der Schwarm von F. Schätzing">

Inklusives Design: Schrift und Farbgebung

Inklusives Design (auch Design for All) heißt: von Anfang an so gestalten, dass möglichst viele Menschen das Produkt ohne Anpassung nutzen können – statt später Sonderlösungen anzubauen. Die Prüfung fragt dazu gern nach Schrift und Farbe.

Barrierefreiheit prüfen

• Automatische Prüfwerkzeuge (z. B. axe, WAVE, Lighthouse) finden fehlende Alternativtexte, zu geringe Kontraste oder fehlende Labels. Sie erkennen aber nur einen Teil der Probleme – ob ein Alternativtext sinnvoll ist, prüfen sie nicht.
• Manuelle Prüfung durch Fachleute: nur mit der Tastatur bedienen, mit einem Screenreader testen (NVDA, JAWS, VoiceOver, TalkBack), auf 200 % vergrößern, Farbfehlsichtigkeit simulieren, Kontraste messen – systematisch entlang der WCAG-Kriterien (z. B. nach dem Prüfverfahren „BITV-Test“).
• Nutzertests mit Menschen mit Behinderungen zeigen, ob die Anwendung im Alltag wirklich nutzbar ist.
• Am besten von Anfang an: Barrierefreiheit in Anforderungen, Styleguide und Definition of Done aufnehmen, statt am Ende nachzubessern.

GUI-03 · Usability & Software-Ergonomie Wahrscheinlich

Vorkommen: 2/9 · Prüfungen: W21 (T1 A3aa Usability/UX an vier Punkten, A3ac Usability-Tests), S24 (T1 A4ba Mängel eines Mockups aus UI/UX-Sicht)

Usability und User Experience

Usability (Gebrauchstauglichkeit) ist nach DIN EN ISO 9241-11 das Ausmaß, in dem bestimmte Benutzer ein System in einem bestimmten Nutzungskontext nutzen können, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.

Wichtig ist der Nutzungskontext: wer (Zielgruppe), mit welchem Ziel, mit welchem Gerät, in welcher Umgebung. Eine App, die Profis am Schreibtisch effizient finden, kann für ältere Menschen unterwegs unbrauchbar sein.

User Experience (UX) umfasst nach DIN EN ISO 9241-210 alle Wahrnehmungen und Reaktionen einer Person, die sich aus der tatsächlichen und der erwarteten Nutzung ergeben – also auch Erwartungen vorher, Emotionen, Ästhetik, Vertrauen und die Erinnerung danach. Usability ist ein Teil der UX.

Software-Ergonomie

Software-Ergonomie bedeutet, Software an die Fähigkeiten und Bedürfnisse der Menschen anzupassen, damit sie ihre Aufgaben ohne unnötige Belastung erledigen können. Für Bildschirmarbeitsplätze verlangt das sogar der Arbeitsschutz (Arbeitsstättenverordnung, Anhang 6). Die Normenreihe DIN EN ISO 9241 „Ergonomie der Mensch-System-Interaktion“ regelt das; wichtig sind Teil 11 (Usability-Begriffe), Teil 110 (Interaktionsprinzipien), Teil 112 (Informationsdarstellung) und Teil 210 (menschzentrierte Gestaltung: Nutzungskontext verstehen → Anforderungen festlegen → Entwürfe erstellen → mit Nutzern bewerten, und das iterativ).

Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110

Seit der Neufassung 2020 heißt der Teil 110 „Interaktionsprinzipien“. In Prüfungen und Lehrbüchern ist „Grundsätze der Dialoggestaltung“ weiterhin üblich. Alte und neue Bezeichnungen werden akzeptiert – am sichersten schreibst du beide, z. B. „Robustheit gegen Benutzerfehler (Fehlertoleranz)“.

Für die Anzeige von Informationen gibt es zusätzlich Teil 112 (Entdeckbarkeit, Ablenkungsfreiheit, Unterscheidbarkeit, eindeutige Interpretierbarkeit, Kompaktheit, Konsistenz). Bei der Anordnung helfen die Gestaltgesetze: Nähe (Zusammengehöriges steht nah beieinander), Ähnlichkeit (gleich Aussehendes hat die gleiche Funktion), Geschlossenheit (ein Rahmen bildet eine Gruppe). Elemente sollten an einem gemeinsamen Raster ausgerichtet sein – „schief“ angeordnete Elemente wirken unruhig und erschweren das Erfassen.

Usability-Tests

Mängel in einem Mockup erkennen und verbessern

Gehe einen Entwurf systematisch von oben nach unten durch und stelle zu jedem Bereich die Fragen der Checkliste:

1. Orientierung: Gibt es einen Seitentitel, einen markierten Menüpunkt, eine Breadcrumb, einen Weg zurück? (Selbstbeschreibungsfähigkeit)
2. Fokus auf die Aufgabe: Sind alle geforderten Funktionen da? Gibt es Überflüssiges oder Doppeltes (Werbung, doppelte Links, Link auf die eigene Seite)? (Aufgabenangemessenheit)
3. Anordnung: Ausrichtung an einem Raster, Zusammengehöriges gruppiert, Wichtiges oben, Platz sinnvoll genutzt?
4. Steuerelemente: Passt das Element zur Eingabe (Datum → Datumsauswahl, kleine Zahl → Stepper)?
5. Beschriftung und Sprache: eindeutig, einheitlich, eine Sprache, kein Fachjargon? (Selbstbeschreibungsfähigkeit, Erwartungskonformität)
6. Aktionen: Hauptaktion hervorgehoben? Gefährliche Aktionen (Löschen, Zurücksetzen) abgesetzt und mit Rückfrage? Abbrechen möglich? (Steuerbarkeit, Robustheit)
7. Fehler und Rückmeldungen: verständliche Meldungen direkt am Feld? Bestätigung nach einer Aktion? (Robustheit, Selbstbeschreibungsfähigkeit)
8. Verhalten: Öffnen Links unerwartet neue Fenster? Wechselt etwas automatisch? (Erwartungskonformität, Steuerbarkeit)
9. Barrierefreiheit: Kontrast, Schriftgröße, Farbe als einziges Merkmal, Größe der Klickflächen, Labels (GUI-02).

Formuliere jeden Mangel nach dem Schema Mangel (was, wo?) → Auswirkung auf den Nutzer → verletzter Grundsatz → Verbesserung. Beispiel: der Dialog einer Bibliothekssoftware zum Verlängern von Ausleihen.

B · Belegsatz

Für diesen Block legt die IHK keine Notationshilfe bei. Der Belegsatz besteht deshalb nur aus den Anlagen zur Ausgangssituation, auf die sich alle Aufgaben beziehen. Keine Erklärungen.

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1 und die weiteren Anlagen des Belegsatzes. Skizzen werden mit Bleistift in die vorgedruckten Rahmen gezeichnet; Farben sind nicht erforderlich. Gesamt: 105 Punkte (ca. 95 Minuten).

GUI-01 · Mockup, Wireframe & GUI-Elemente

GUI-02 · Barrierefreiheit

GUI-03 · Usability & Software-Ergonomie