09 Benutzeroberfläche

Lösungen

GUI-01 · Mockup, Wireframe & GUI-Elemente

Aufgabe GUI-01.1 · 6 Punkte

Verlangt sind sechs der acht Elemente. Hier alle acht:

Nr.	Bezeichnung (auch akzeptiert)	Zweck
①	Breadcrumb (Pfadnavigation, Brotkrümelnavigation)	zeigt, wo man sich in der Hierarchie der Anwendung befindet (Start › Kurse › Aquafitness 50+); die übergeordneten Ebenen sind anklickbar – Orientierung und schneller Rückweg
②	Tabs (Registerkarten, Reiter)	wechseln zwischen gleichrangigen Ansichten desselben Kurses (Termine, Teilnehmende, Warteliste), ohne die Seite zu verlassen; der aktive Tab ist hervorgehoben
③	Dropdown-Liste (Auswahlliste, Drop-down-Menü, Combobox)	Auswahl genau eines Werts aus einer vorgegebenen Liste, platzsparend; hier als Filter nach Kursleitung
④	Datumsauswahl (Datepicker, Zeitraumauswahl, Kalender)	Auswahl eines Zeitraums über einen Kalender, ohne Datum eintippen zu müssen; verhindert falsche Formate; filtert die Termine
⑤	Checkbox (Kontrollkästchen)	eine Option an- oder abwählen (ja/nein); hier: nur Termine mit freien Plätzen anzeigen
⑥	Fortschrittsbalken (Balkenanzeige, Füllstandsanzeige, Progress Bar)	stellt die Belegung grafisch dar (12 von 15 Plätzen) – die Auslastung der Termine ist auf einen Blick vergleichbar
⑦	Pagination (Seitennavigation, Blätterfunktion)	verteilt eine lange Liste auf mehrere Seiten und ermöglicht das Wechseln zwischen ihnen; die aktuelle Seite ist markiert
⑧	Toast (Snackbar, Statusmeldung, Benachrichtigung)	kurze Rückmeldung nach einer Aktion („Termin gespeichert“), die die Arbeit nicht blockiert und nach einigen Sekunden von selbst verschwindet

Bewertung: je Element 0,5 P für die Bezeichnung und 0,5 P für den Zweck, höchstens sechs Elemente (6 P). Gängige Synonyme und englische Begriffe werden akzeptiert. Für ⑥ wird „Balkendiagramm“ akzeptiert, für ③ „Auswahlmenü“. Nicht akzeptiert: „Toggle“ für ⑤ (das ist ein Schalter mit sofortiger Wirkung) und „Pop-up“ für ⑧, wenn der Zweck nicht stimmt (ein Pop-up blockiert).

Erklärung: Der Zweck sollte sich auf die konkrete Seite beziehen. Nicht markiert, aber ebenfalls Gestaltungselemente sind das Suchfeld, der Primärbutton „+ Termin anlegen“ und die Tabelle selbst.

Aufgabe GUI-01.2 · 11 Punkte

a) Bedienelemente für den Ticketkauf (7 P)

Anf.	GUI-Element	Begründung
C1	Radiobuttons oder Segmented Control (Umschalter mit 3 Segmenten)	genau eine Auswahl aus wenigen Optionen; alle drei Bäder sind auf einen Blick sichtbar, ein Tipp genügt
C2	Datumsauswahl (Kalender, Datepicker)	nur gültige Tage (heute bis +30) sind wählbar, Revisionstage gesperrt – keine Fehleingaben, kein Datumsformat nötig
C3	Stepper (− 0 +) je Tarif	exakte kleine Ganzzahl; die Grenzen 0 und 10 lassen sich erzwingen; große Tippflächen
C4	Checkboxen (oder Toggle-Switches)	mehrere Optionen unabhängig voneinander wählbar
C5	Toast / Snackbar	kurze Bestätigung, die nicht blockiert und von selbst verschwindet; der Nutzer muss nichts wegklicken
C6	Modaler Dialog (Bestätigungsdialog)	unterbricht den Ablauf und erzwingt eine bewusste Entscheidung; eindeutig beschriftete Buttons („Ticket stornieren“ / „Ticket behalten“) verhindern versehentliches Stornieren
C7	Tab-Bar (Bottom Navigation) mit Symbol und Text	die vier Hauptbereiche sind immer sichtbar und mit einem Tipp erreichbar, gut mit dem Daumen bedienbar

Bewertung: je Zeile 0,5 P für ein geeignetes Element und 0,5 P für eine passende Begründung. Ebenfalls akzeptiert: C1 Dropdown (mit Begründung „platzsparend“), C2 waagerechte Tagesleiste mit Chips, C3 Dropdown 0–10 oder Zahlenfeld mit Pfeilen, C7 Hamburger-Menü (mit Begründung „spart Platz“). Nicht akzeptiert: Slider oder Freitext für C3, Freitext für C2, Toast für C6 (keine Entscheidung möglich).

b) Responsive Design (4 P)

Responsive Design bedeutet, dass sich das Layout einer Oberfläche automatisch an Bildschirmgröße und Ausrichtung des Endgeräts anpasst (flexible Raster, Breakpoints über Media Queries, relative Größen). Inhalte und Funktionen bleiben gleich, es gibt nur eine Codebasis.

Anpassungen der Seite aus Anlage 5 (zwei verlangt):

Die Tabelle mit sechs Spalten wird zu einer Liste von Karten: je Termin eine Karte mit Datum, Uhrzeit, Belegung und Schaltfläche „Anwesenheit“. Weniger wichtige Spalten (Kursleitung) entfallen oder rücken in die Karte. So muss im Hochformat nicht waagerecht gescrollt werden.
Die waagerechte Menüleiste wird zum Hamburger-Menü, die Suche zum Lupensymbol – das spart Platz für den Inhalt.
Die Filterzeile (Dropdown, Datumsauswahl, Checkbox) wird untereinander angeordnet oder hinter einer Schaltfläche „Filter“ eingeklappt.
Kleine Text-Links wie „Bearbeiten“ werden zu großen Touch-Schaltflächen (mind. 44 × 44 px) mit Abstand, weil am Beckenrand mit dem Finger bedient wird; Hover-Effekte entfallen.
Breadcrumb verkürzt („‹ Kurse“), Pagination durch Weiterscrollen ersetzt.

Abb. L-1: Kursverwaltung auf dem Tablet im Hochformat (eine mögliche Umsetzung)

Bewertung: 1 P für die Erläuterung des Begriffs; je Anpassung 1,5 P (1 P konkrete Anpassung mit Bezug auf Anlage 5, 0,5 P Wirkung bzw. Begründung). Allgemeine Antworten ohne Bezug zur Seite („Bilder skalieren“) höchstens 1 P je Anpassung. „Eigene App für Tablets entwickeln“ ist kein Responsive Design (0 P).

Aufgabe GUI-01.3 · 18 Punkte

aa) Wireframe und Mockup (2 P)

Ein Wireframe ist ein grober, schematischer Entwurf (Low-Fidelity). Er zeigt Aufbau und Anordnung der Elemente mit Platzhaltern – ohne Farben, Bilder und endgültige Texte. Ein Mockup ist ein detailgetreuer, aber statischer Entwurf (High-Fidelity). Er zeigt das spätere Aussehen mit Farben, Schriften, Symbolen und Beispielinhalten, ist aber nicht bedienbar.

je Begriff 1 P; der Unterschied (Detailgrad: Struktur vs. Aussehen) muss erkennbar sein.

ab) Vorteile von Mockups (4 P)

Zwei der folgenden Vorteile, jeweils mit Begründung:

Frühes Feedback, günstige Änderungen: Die AquaVita sieht schon vor der Programmierung, wie die Seite „Auslastung“ aussehen wird, und kann fehlende oder missverständliche Inhalte (z. B. welche Becken angezeigt werden) korrigieren lassen. Änderungen am Entwurf kosten wenig, Änderungen am fertigen Code viel.
Gemeinsame Abstimmungs- und Abnahmegrundlage: Kunde, UI/UX-Team und Entwicklung sprechen über dasselbe Bild. Das abgestimmte Mockup ist eine verbindliche Vorgabe – weniger Missverständnisse und Rückfragen während der Umsetzung.
Frühe Usability-Tests: Mit dem Mockup bzw. einem daraus erstellten Klickprototyp lassen sich Personen aus den Zielgruppen (z. B. Seniorinnen und Senioren) testen, bevor Code existiert.
Bessere Planung: Umfang und benötigte Daten (z. B. stündliche Prognosewerte, Temperatursensoren) werden sichtbar – der Aufwand lässt sich genauer schätzen.
Einheitliches Design: Mockups sind die Grundlage eines Styleguides für App und Website.

je Vorteil 2 P (1 P Vorteil, 1 P Begründung bzw. Auswirkung). Reine Stichworte ohne Begründung höchstens 1 P je Vorteil.

ba) Darstellungsformen (2 P)

Zwei von: Säulendiagramm (je Stunde eine Säule) · Liniendiagramm (Verlaufskurve über den Tag) · Tabelle/Liste (Uhrzeit – erwartete Auslastung in %) · farbige Zeitleiste bzw. Heatmap (je Stunde ein Feld mit Stufe „wenig/mittel/voll“ als Text).

je Darstellungsform 1 P. Nicht akzeptiert: Kreisdiagramm (zeigt Anteile, keinen Verlauf), Karte, Tacho bzw. Ampel (zeigen nur einen einzelnen Wert).

bb) Entscheidung und Begründung (2 P)

Säulendiagramm. Jede Öffnungsstunde ist eine eigene Säule. Die Nutzerin erkennt auf einen Blick, wann wenig los ist (niedrigste Säulen), und kann ihren Besuch danach planen. Das funktioniert auch auf dem kleinen Smartphone-Bildschirm, und die aktuelle Stunde lässt sich hervorheben. Eine Tabelle müsste dagegen Zeile für Zeile gelesen werden.

1 P für eine Entscheidung, die zu ba) passt, 1 P für eine Begründung mit Bezug auf die Aufgabe der Nutzer. Ebenso richtig z. B.: „Liniendiagramm – zeigt den Verlauf über den Tag mit Spitzen und ruhigen Zeiten als durchgehende Kurve.“ „Ist übersichtlich“ allein: 0 P.

c) Entwurf der Seite „Auslastung“ (8 P)

Abb. L-2: Musterlösung Seite „Auslastung“ (Smartphone, 360 × 740)

Bewertung (8 P): je 1 P für B1 Auswahl des Bades · B2 aktuelle Auslastung mit Anzahl und Prozent · B3 Auswahl des Tages (heute bis +6) · B3 stündliche Prognose in der Darstellungsform aus bb) mit beschrifteten Achsen · B4 Wassertemperatur je Becken · B5 Schaltfläche zum Ticketkauf · B6 Stand der Daten und Aktualisieren; 1 P für die Gesamtgestaltung (sinnvolle Reihenfolge, Beschriftungen und Beispieldaten, Primäraktion hervorgehoben, Auslastung nicht nur über Farbe). Ebenfalls richtig: Bad als Tabs bzw. Segmented Control, Tag als Datumsauswahl, aktuelle Auslastung als Tacho oder Ringdiagramm mit Zahl, Prognose als Liniendiagramm, Aktualisieren per „Nach unten ziehen“ (beschriftet).

Erklärung: Wie in S26 T1 A4cb stehen die Punkte hinter den Anforderungen. Typische Punktverluste: nur Prozent statt „Anzahl und Prozent“ (B2), Diagramm ohne Tagesauswahl (B3), Zeitstempel vergessen (B6). Die Tab-Bar ist nicht verlangt, schadet aber nicht.

GUI-02 · Barrierefreiheit

Aufgabe GUI-02.1 · 6 Punkte

a) Begriff (2 P)

Barrierefreie Software kann von allen Menschen – auch von Menschen mit Behinderungen (z. B. Seh-, Hör-, motorischen oder kognitiven Einschränkungen) und von älteren Menschen – in der üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe genutzt werden. Dazu müssen Inhalte wahrnehmbar, bedienbar und verständlich sein und mit Hilfsmitteln wie Screenreader, Bildschirmlupe oder Tastatur funktionieren.

1 P für den Kern („für alle nutzbar, ohne fremde Hilfe bzw. besondere Erschwernis“), 1 P für den Bezug auf Einschränkungen oder Hilfsmittel. „Rollstuhlgerecht“ oder „ohne Treppen“ allein: 0 P.

b) WCAG-Prinzipien (2 P)

wahrnehmbar · bedienbar · verständlich · robust

je 0,5 P; die englischen Begriffe (perceivable, operable, understandable, robust) werden akzeptiert.

c) Personengruppen (2 P)

Vier von: blinde Menschen · sehbehinderte Menschen · Menschen mit Farbfehlsichtigkeit · gehörlose und schwerhörige Menschen · Menschen mit motorischen Einschränkungen (z. B. Zittern, Lähmungen) · Menschen mit kognitiven Einschränkungen oder Lernschwierigkeiten · ältere Menschen (laut D3 eine Zielgruppe) · Menschen mit geringen Deutschkenntnissen (z. B. Touristen) · vorübergehend oder situativ eingeschränkte Menschen (z. B. grelles Sonnenlicht im Freibad, nasse Hände, Arm im Gips).

je 0,5 P. Zwei Nennungen derselben Gruppe („Blinde“, „Sehbehinderte“) zählen einzeln, „Behinderte“ allein nur einmal.

Aufgabe GUI-02.2 · 12 Punkte

a) Rückmeldungen F1 bis F6 (8 P, vier verlangt)

Nr.	verletzte Anforderung	geeignete Maßnahme
F1	Texte müssen auch für sehbehinderte und ältere Menschen lesbar sein: ausreichender Kontrast und Vergrößerung ohne Informationsverlust (wahrnehmbar).	Kontrastverhältnis mind. 4,5 : 1 (dunkle Schrift statt Hellgrau); relative Schriftgrößen, Systemschriftgröße übernehmen; fließendes, responsives Layout, das bis 200 % Vergrößerung nicht überlappt.
F2	Informationen dürfen nicht allein über Farbe vermittelt werden (wahrnehmbar).	Belegung zusätzlich als Text („ausgebucht“, „3 Plätze frei“) und Symbol (✕ / ✓) oder Muster; farbfehlsichtigen-freundliche Farben (z. B. Blau/Orange).
F3	Bedienelemente und informative Bilder brauchen eine Textalternative bzw. einen zugänglichen Namen, damit Screenreader sie vorlesen können (wahrnehmbar, robust).	Schaltflächen mit sichtbarem Text oder zugänglichem Namen (z. B. `aria-label`, in Apps `contentDescription`/`accessibilityLabel`); aussagekräftige Alternativtexte („Sportbecken mit acht Bahnen“), dekorative Bilder ausblenden; Test mit TalkBack und VoiceOver.
F4	Die Anwendung muss auch bei eingeschränkter Feinmotorik und ohne Maus vollständig bedienbar sein (bedienbar).	Touch-Ziele mind. 44 × 44 pt bzw. 48 × 48 dp mit Abstand; alle Elemente per Tabulator in logischer Reihenfolge erreichbar, sichtbarer Fokus; „Bezahlen“ als echtes Button-Element.
F5	Audio- und Videoinhalte brauchen Alternativen für gehörlose Menschen (wahrnehmbar).	Untertitel für das Video, Textfassung der Baderegeln; ggf. Video in Deutscher Gebärdensprache.
F6	Inhalte müssen verständlich sein – auch für Menschen mit geringen Deutschkenntnissen oder Lernschwierigkeiten (verständlich).	Tariftexte in einfacher Sprache mit kurzen Sätzen und Beispielen („Ermäßigt zahlen: Schüler, Studierende, Menschen mit Schwerbehindertenausweis“); Fachbegriffe erklären; englische Fassung (Zielgruppe Touristen, D3); ggf. Leichte Sprache.

Bewertung: je Zeile 2 P – 1 P für die Anforderung (sinngemäß, mit Bezug zur Rückmeldung; das WCAG-Prinzip ist nicht verlangt), 1 P für eine konkrete, passende Maßnahme. Eine Maßnahme, die nur die Anforderung wiederholt („Kontrast verbessern“), gibt 0,5 P.

b) Inklusives Design (4 P)

Kriterium	Beispiele (je zwei verlangt)
Schriftart / Schriftbild	serifenlose, gut lesbare Schrift mit unterscheidbaren Zeichen · ausreichende Grundgröße (ca. 16 px) · Schriftgröße vom Nutzer einstellbar (Systemeinstellung) · Zeilenabstand ca. 1,5-fach · linksbündig, kein Blocksatz · keine langen Texte in Großbuchstaben oder kursiv · klare Hierarchie durch Größe und Fettung
Farbgebung	hoher Kontrast (mind. 4,5 : 1) · Farbe nie alleiniger Informationsträger · Rot-Grün-Kombinationen vermeiden · Dunkel- bzw. Hochkontrastmodus anbieten · einheitliche Farbbedeutungen · keine grellen, flackernden Farben

je passendem Beispiel 1 P, höchstens zwei je Kriterium.

Aufgabe GUI-02.3 · 16 Punkte

a) Gesetzliche Grundlage (2 P)

Seit dem 28.06.2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG), mit dem Deutschland den European Accessibility Act der EU umsetzt. Es verpflichtet auch private Unternehmen, bestimmte Produkte und Dienstleistungen für Verbraucher barrierefrei anzubieten. Dazu gehören Dienstleistungen im elektronischen Geschäftsverkehr, also auch der Online-Verkauf von Tickets und die Online-Buchung von Kursen über Website und App. Die Ausnahme für Kleinstunternehmen greift nicht, weil die AquaVita 140 Beschäftigte hat.

1 P für das BFSG (oder den European Accessibility Act), 1 P für die Begründung (Online-Verkauf bzw. Buchung für Verbraucher; keine Kleinstunternehmen-Ausnahme). Die BITV 2.0 gilt nur für öffentliche Stellen (0 P).

b) Barrieren im Entwurf (10 P, vier verlangt)

Abb. L-3: Entwurf aus Anlage 4 mit markierten Barrieren B1–B10

Nr.	Barriere im Entwurf	Prinzip	Maßnahme
B1	Kursinfo, „Personen“, „AGB gelesen“ und Fußzeile in kleiner hellgrauer Schrift (Kontrast ca. 2 : 1) – für sehbehinderte und ältere Menschen kaum lesbar	wahrnehmbar	Kontrast mind. 4,5 : 1, Schriftgröße ca. 16 px, über die Browsereinstellung vergrößerbar
B2	freie und ausgebuchte Uhrzeiten nur durch grünen bzw. roten Punkt unterscheidbar – Farbfehlsichtige und Screenreader-Nutzer erhalten die Information nicht	wahrnehmbar	zusätzlich Text („3 Plätze frei“, „ausgebucht“) und Symbol; ausgebuchte Termine deaktivieren und benennen
B3	Fehler nur durch roten Rahmen erkennbar; Meldung „Fehler 422 – Eingabe ungültig“ ohne Feldbezug	wahrnehmbar, verständlich	Fehlermeldung als Text mit Symbol direkt am Feld, mit Korrekturhinweis; für Screenreader mit dem Feld verknüpft und angesagt; Fokus auf das erste fehlerhafte Feld
B4	Eingabefelder nur mit Platzhaltertext statt Beschriftung – verschwindet beim Tippen, wird nicht zuverlässig vorgelesen	verständlich (auch robust)	dauerhaft sichtbare Labels, im Code mit dem Feld verknüpft; Pflichtfelder als Text kennzeichnen
B5	Bild-CAPTCHA ohne Alternative – blinde und stark sehbehinderte Menschen können nicht buchen	wahrnehmbar	auf das CAPTCHA verzichten (unsichtbarer Bot-Schutz, z. B. verstecktes Feld, Zeit- und Mengenbegrenzung) oder barrierefreie Alternative (Audio, einfache Frage)
B6	Bildkarussell wechselt automatisch alle 3 s ohne Pause – lenkt ab, Inhalte verschwinden zu schnell	bedienbar	kein automatischer Wechsel oder Pause-/Stopp-Schaltfläche; Wechsel stoppt bei Fokus; Alternativtexte für die Bilder
B7	Linktext „hier klicken“ nicht aussagekräftig (in der Linkliste des Screenreaders sinnlos); öffnet ohne Ankündigung ein neues Fenster	verständlich (auch bedienbar)	Linktext „Kursbeschreibung Aquafitness 50+ (PDF, 120 kB)“; im selben Fenster öffnen oder darauf hinweisen
B8	Schieberegler für die Personenanzahl: schwer zu treffen, per Tastatur kaum gezielt einstellbar, Wert weder sichtbar noch ansagbar	bedienbar	Stepper mit großen +/−-Schaltflächen oder Auswahlliste; Wert sichtbar und für Screenreader ausgegeben
B9	Datumsformat „TT.MM.JJJJ“ nur als Platzhalter, freie Eingabe fehleranfällig	verständlich	Formatangabe im Label, tolerante Eingabe; besser die Termine als Liste zur Auswahl anbieten
B10	Symbole „merken, teilen, drucken“ ohne Text und nur 16 × 16 px groß – schwer zu treffen, für Screenreader ohne Namen	bedienbar, wahrnehmbar	Zielgröße mind. 24 × 24 px (besser 44 × 44 px) mit Abstand; sichtbare Beschriftung bzw. zugänglicher Name

Bewertung: je Zeile 2,5 P – 1 P für die Barriere (Ort im Entwurf und Auswirkung bzw. betroffene Gruppe), 0,5 P für ein passendes Prinzip (bei mehreren möglichen Prinzipien wird jede begründete Zuordnung akzeptiert), 1 P für eine konkrete Maßnahme. Reine Usability-Mängel ohne Barrierebezug (z. B. „Werbung lenkt ab“ ohne Bezug auf den automatischen Wechsel) zählen hier nicht.

c) Prüfverfahren (4 P)

Zwei der folgenden Verfahren:

Automatisierte Prüfung mit Werkzeugen wie axe, WAVE oder Lighthouse: Die Seiten werden automatisch auf messbare Kriterien untersucht (fehlende Alternativtexte, zu geringe Kontraste, fehlende Labels, Überschriftenstruktur). Schnell und wiederholbar, z. B. bei jedem Build; findet aber nur einen Teil der Probleme.
Manuelle Prüfung durch Fachleute entlang der WCAG-Kriterien (z. B. nach dem Prüfverfahren „BITV-Test“): die Seite nur mit der Tastatur bedienen, mit einem Screenreader (NVDA, VoiceOver, TalkBack) durchgehen, auf 200 % vergrößern, Kontraste messen, Farbfehlsichtigkeit simulieren.
Nutzertest mit Menschen mit Behinderungen (z. B. blinde Screenreader-Nutzer, Seniorinnen): Sie lösen typische Aufgaben wie „Buchen Sie den Kurs am Mittwoch“; Probleme werden beobachtet und protokolliert.
Prüfung durch eine externe Prüfstelle, die einen Prüfbericht erstellt.

je Verfahren 2 P (1 P Verfahren, 1 P Beschreibung des Ablaufs). Nur „testen“ ohne Verfahren: 0 P.

GUI-03 · Usability & Software-Ergonomie

Aufgabe GUI-03.1 · 6 Punkte

a) Usability und User Experience (2 P)

Usability (Gebrauchstauglichkeit) beschreibt, wie effektiv, effizient und zufriedenstellend bestimmte Nutzer in einem bestimmten Nutzungskontext ihre Ziele mit der App erreichen – also die Qualität während der Nutzung. User Experience ist weiter gefasst: Sie umfasst alle Wahrnehmungen und Reaktionen vor, während und nach der Nutzung, z. B. Erwartungen, Gefühle, Ästhetik, Vertrauen und Erinnerung. Usability ist ein Teil der UX.

je Begriff 1 P; der Unterschied (UX umfasst mehr als die eigentliche Nutzung) muss deutlich werden.

b) Zuordnung (3 P)

Nr.	Eigenschaft (Kurzform)	Grundsatz
1	Gutscheincodes: Leerzeichen und O/0 werden abgefangen	Robustheit gegen Benutzerfehler (Fehlertoleranz)
2	„Schritt 2 von 3: Zusatzleistungen wählen“	Selbstbeschreibungsfähigkeit
3	Videos anhalten, zurückspulen, schneller abspielen	Steuerbarkeit
4	nur die für den Kurs nötigen Angaben werden abgefragt	Aufgabenangemessenheit
5	Logo oben links führt zur Startseite	Erwartungskonformität
6	Tour stellt neue Funktionen vor	Erlernbarkeit (Lernförderlichkeit)

je richtiger Zuordnung 0,5 P; die Bezeichnungen der Fassung von 2006 werden akzeptiert.

c) Fehlender Grundsatz (1 P)

Benutzerbindung (neu seit 2020): Die App ist einladend und motivierend und schafft Vertrauen, z. B. durch eine ansprechende Gestaltung, eine persönliche Begrüßung, transparente Preise oder einen Glückwunsch mit Bonus zum zehnten Besuch.

0,5 P Grundsatz, 0,5 P passendes Beispiel.

Erklärung: Nr. 1 ist keine Aufgabenangemessenheit, weil es um das Abfangen von Fehleingaben geht. Nr. 3 gehört zur Steuerbarkeit, weil der Nutzer Tempo und Ablauf bestimmt. Die frühere Individualisierbarkeit ist kein eigener Grundsatz mehr und deshalb nicht der gesuchte.

Aufgabe GUI-03.2 · 12 Punkte

a) Rückmeldungen F7 bis F12 (8 P, vier verlangt)

Nr.	verletzter Grundsatz	Verbesserung für die neue App
F7	Robustheit gegen Benutzerfehler (Fehlertoleranz)	Eingaben bleiben nach einem Fehler erhalten; das fehlerhafte Feld wird markiert und verständlich erklärt („Das Kind muss bei Kursbeginn mindestens 4 Jahre alt sein“); Geburtsdatum per Datumsauswahl, Prüfung schon bei der Eingabe.
F8	Selbstbeschreibungsfähigkeit	nach dem Bezahlen eine Bestätigungsseite („Kauf erfolgreich“, Ticketnummer, QR-Code, Hinweis auf die E-Mail) und eine Bestätigungs-E-Mail; während der Zahlung eine Ladeanzeige.
F9	Aufgabenangemessenheit	Schnellkauf häufiger Tickets direkt von der Startseite („Tageskarte Hallenbad“) in wenigen Schritten; Adresse im Kundenkonto speichern und vorbelegen; nur nötige Daten abfragen.
F10	Erwartungskonformität	einheitliche Begriffe in App und Website (überall „Warenkorb“), Schaltflächen immer an derselben Stelle („Weiter“ rechts unten); gemeinsamer Styleguide bzw. Designsystem.
F11	Steuerbarkeit	Zurückgehen ohne Datenverlust (Auswahl zwischenspeichern), sichtbare Schaltfläche „Abbrechen“ in jedem Schritt, Kauf später fortsetzen.
F12	Erlernbarkeit (Lernförderlichkeit)	kurze Einführung beim ersten Öffnen; Hilfe-Symbol bzw. Erklärung mit Beispiel direkt an der Wertkarte; FAQ.

Bewertung: je Zeile 2 P – 1 P Grundsatz, 1 P konkrete, passende Verbesserung. Begründete andere Zuordnungen werden akzeptiert, z. B. F8 Erwartungskonformität (man erwartet eine Bestätigung), F11 Robustheit gegen Benutzerfehler (Datenverlust), F9 Benutzerbindung (Stammgast wird verärgert).

b) Usability-Tests (4 P)

Zeitpunkt	Testverfahren und Beschreibung (je ein Verfahren verlangt)
vor dem Go-live (klickbarer Prototyp)	Thinking-Aloud-Test: Etwa fünf Testpersonen aus den Zielgruppen (z. B. Senioren, Familien) lösen am Klickprototyp typische Aufgaben („Kaufen Sie eine Familienkarte für Samstag“) und sprechen dabei ihre Gedanken laut aus. Ein Moderator beobachtet, protokolliert Probleme und zeichnet ggf. Bildschirm und Ton auf. Ebenfalls richtig: heuristische Evaluation bzw. Expertenreview, Eye-Tracking, Cognitive Walkthrough.
nach dem Go-live (laufender Betrieb)	A/B-Test: Zwei Varianten einer Seite (z. B. Ticketkauf mit drei oder mit vier Schritten) werden zufällig verschiedenen Nutzergruppen gezeigt. Verglichen werden Kennzahlen wie Abschluss- oder Abbruchquote; die bessere Variante wird übernommen. Ebenfalls richtig: Nutzungsanalyse (Web-Analytics, Abbruchstellen), Fragebogen wie SUS bzw. In-App-Feedback.

Zeitpunkt

Testverfahren und Beschreibung (je ein Verfahren verlangt)

vor dem Go-live (klickbarer Prototyp)

Thinking-Aloud-Test: Etwa fünf Testpersonen aus den Zielgruppen (z. B. Senioren, Familien) lösen am Klickprototyp typische Aufgaben („Kaufen Sie eine Familienkarte für Samstag“) und sprechen dabei ihre Gedanken laut aus. Ein Moderator beobachtet, protokolliert Probleme und zeichnet ggf. Bildschirm und Ton auf.
Ebenfalls richtig: heuristische Evaluation bzw. Expertenreview, Eye-Tracking, Cognitive Walkthrough.

nach dem Go-live (laufender Betrieb)

A/B-Test: Zwei Varianten einer Seite (z. B. Ticketkauf mit drei oder mit vier Schritten) werden zufällig verschiedenen Nutzergruppen gezeigt. Verglichen werden Kennzahlen wie Abschluss- oder Abbruchquote; die bessere Variante wird übernommen.
Ebenfalls richtig: Nutzungsanalyse (Web-Analytics, Abbruchstellen), Fragebogen wie SUS bzw. In-App-Feedback.

je Zeitpunkt 2 P – 1 P für ein passendes Verfahren, 1 P für die Beschreibung des Ablaufs. Ein A/B-Test vor dem Go-live ist nur eingeschränkt sinnvoll (es fehlen echte Nutzer in großer Zahl) und gibt dort höchstens 1 P.

Aufgabe GUI-03.3 · 18 Punkte

a) Mängel aus UI/UX-Sicht (8 P, vier verlangt)

Abb. L-4: Entwurf aus Anlage 4 mit markierten Usability-Mängeln (U8, U11 und U13 fehlen im Entwurf und sind deshalb nicht markiert)

Nr.	Mangel (mit Auswirkung)	Grundsatz
U1	keine Seitenüberschrift, kein markierter Menüpunkt, keine Breadcrumb; der Kursname steht nur im grauen Kleintext – man erkennt nicht, wo man ist und welchen Kurs man bucht	Selbstbeschreibungsfähigkeit
U2	großes, automatisch wechselndes Werbekarussell nimmt das obere Drittel ein, hat mit der Buchung nichts zu tun und lenkt ab; das Formular rutscht nach unten	Aufgabenangemessenheit
U3	Kursdatum als Freitextfeld, obwohl nur feste Termine möglich sind; Datum und Uhrzeiten getrennt, freie Plätze nicht als Zahl – Nutzer muss raten, ungültige Termine sind eingebbar	Aufgabenangemessenheit (auch Robustheit)
U4	technische Fehlermeldung „Fehler 422 – Eingabe ungültig“ ohne Feldbezug und ohne Lösungshinweis	Robustheit gegen Benutzerfehler (auch Selbstbeschreibungsfähigkeit)
U5	„Zurücksetzen“ ist die auffälligste Schaltfläche, steht direkt neben dem Absenden und löscht ohne Rückfrage alle Eingaben	Robustheit gegen Benutzerfehler
U6	Absende-Schaltfläche englisch („Submit“) auf einer deutschen Seite und so blass gestaltet, dass sie deaktiviert wirkt; unklar, ob verbindlich und kostenpflichtig gebucht wird	Erwartungskonformität (auch Selbstbeschreibungsfähigkeit)
U7	Schieberegler für 1–4 Personen ohne Wertanzeige – ungenau, man sieht nicht, wie viele Personen gewählt sind	Aufgabenangemessenheit (auch Selbstbeschreibungsfähigkeit)
U8	(fehlt) kein Preis und keine Zusammenfassung vor dem Absenden (Anforderung A4)	Selbstbeschreibungsfähigkeit
U9	Link „hier klicken“ öffnet die Kursbeschreibung in einem neuen Fenster – die Zurück-Taste funktioniert nicht, Nutzer verlieren die Orientierung	Erwartungskonformität (auch Steuerbarkeit)
U10	Newsletter-Checkbox ist vorausgewählt – Nutzer abonnieren ungewollt Werbung, das untergräbt das Vertrauen (zudem keine wirksame Einwilligung nach DSGVO)	Benutzerbindung (auch Erwartungskonformität)
U11	(fehlt) keine Möglichkeit, die Buchung abzubrechen oder zur Kursübersicht zurückzukehren (Anforderung A6)	Steuerbarkeit
U12	Symbole „merken, teilen, drucken“ ohne Beschriftung – Bedeutung unklar	Selbstbeschreibungsfähigkeit
U13	(fehlt) nur ein Namens- und ein Geburtsdatumsfeld, obwohl bis zu vier Personen angemeldet werden können (Anforderung A3)	Aufgabenangemessenheit

Bewertung: je Mangel 2 P – 1 P für den nachvollziehbar beschriebenen Mangel mit Auswirkung auf den Nutzer, 1 P für einen passenden Grundsatz (begründete andere Zuordnungen werden akzeptiert). Reine Barrierefreiheitsmängel (Kontrast, Farbe, CAPTCHA) geben in dieser Teilaufgabe keine Punkte. Auch Mängel bei Positionierung und Ausrichtung werden akzeptiert, wenn die Auswirkung beschrieben ist (z. B. „Elemente nicht an einem Raster ausgerichtet, zusammengehörige Felder auf zwei Spalten verteilt – Reihenfolge der Eingabe unklar“).

b) Verbessertes Mockup (10 P)

Abb. L-5: Musterlösung – überarbeitete Seite „Kurs buchen“ (Desktop); A bis J siehe Anmerkungen

Orientierung: aktiver Menüpunkt „Kurse“, Breadcrumb und Überschrift mit Kursname (behebt U1).
Kursinfo mit allen Angaben aus A1 in gut lesbarer Schrift; aussagekräftiger PDF-Link, der im selben Fenster öffnet (A1; U9, B1, B7).
Termine als Liste mit Radiobuttons: freie Plätze als Text, ausgebuchte Termine deaktiviert, mit Warteliste (A2; U3, B2, B9).
Sichtbare Beschriftungen mit Formatangabe, Pflichtfelder mit *; Fehlermeldungen erscheinen bei Bedarf als Text direkt am Feld, Eingaben bleiben erhalten (U4, B3, B4).
Personen über „+ Weitere Person hinzufügen“ (bis zu vier), je Person Name und Geburtsdatum – kein Schieberegler (A3; U7, U13, B8).
Zusammenfassung mit Gesamtpreis vor dem Buchen (A4; U8).
AGB-Bestätigung als Pflicht, Newsletter freiwillig und nicht vorausgewählt (A5; U10).
„Abbrechen“ als Sekundärbutton, eindeutige deutsche Hauptaktion „Zahlungspflichtig buchen“ hervorgehoben; kein „Zurücksetzen“ (A6; U5, U6, U11).
Kein Werbekarussell, kein CAPTCHA: Die Buchung beginnt direkt unter der Überschrift; Bot-Schutz unsichtbar auf dem Server (U2, B5, B6).
Bestätigung nach dem Buchen auf dem Bildschirm und per E-Mail (A7); Symbole ohne Beschriftung entfallen (U12, B10).

Bewertung (10 P): je 1 P für die Umsetzung von A1 bis A7 (7 P; A7 genügt als Randnotiz oder Folgeseite in der Skizze), 3 P für die erkennbare Beseitigung der in a) genannten Mängel und eine übersichtliche, ausgerichtete Anordnung. Andere Anordnungen sind gleichwertig, z. B. ein mehrstufiger Ablauf (Schritt 1 Termin, Schritt 2 Personen, Schritt 3 Prüfen) mit Schrittanzeige, Termine als Kalender mit Text „frei/ausgebucht“ oder ein Stepper für die Personenanzahl, der entsprechend viele Namensfelder einblendet.

Erklärung: Die Teilaufgaben a) und b) hängen zusammen – der Prüfer vergleicht, ob die in a) genannten Mängel in b) behoben sind. Wer einen Mangel nennt, ihn in der Skizze aber wiederholt (z. B. wieder „Submit“), verliert dort Punkte. Ein Bildkarussell darf es geben, wenn es nicht automatisch wechselt und die Buchung nicht verdrängt – nötig ist es für die Aufgabe nicht.