Vom Menschen zur Anforderung

Worum es geht

Das Sport- und Freizeitzentrum in Gossau hat ein Problem, das auf den ersten Blick gar nicht nach Webdesign klingt: Das Telefon an der Kasse klingelt ununterbrochen. Gäste rufen an, um einen Badmintonplatz zu reservieren oder ihr Kind für einen Schwimmkurs anzumelden, obwohl das alles online ginge. Die Geschäftsleitung sagt zu Nico, Mediamatiker im 3. Lehrjahr bei der Kernform AG in St. Gallen: «Mach uns eine schönere Reservationsseite.»

Genau hier entscheidet sich, ob ein Projekt gut wird. Wer jetzt sofort Figma öffnet und ein hübsches Layout zeichnet, löst vielleicht ein Problem, das niemand hat. Denn warum rufen die Leute eigentlich an? Ist die Seite hässlich? Zu langsam? Finden sie die freien Zeiten nicht? Verstehen sie die Begriffe nicht? Oder sitzen sie im Auto und haben keine Hand frei?

In dieser Lektion lernst du, wie du herausfindest, wer eine Oberfläche nutzt, in welcher Situation und mit welchem Ziel, und wie du daraus prüfbare Anforderungen formulierst. Das ist der erste Schritt im ganzen Modul: Alles, was später kommt (Prototyp, Komponenten, Barrierefreiheit, Tests), misst sich an diesen Anforderungen.

UX und UI: zwei Seiten derselben Oberfläche

Die zwei Begriffe werden oft verwechselt, darum zuerst sauber:

Eine Analogie: Die UI eines Billettautomaten sind Bildschirm, Tasten und Kartenleser. Die UX ist, ob du dein Ticket erwischst, bevor der Zug abfährt. Ein Automat kann eine wunderschöne UI haben und trotzdem eine schlechte UX, wenn du dreimal zurück musst, weil das Halbtax erst am Schluss abgefragt wird.

Als Mediamatikerin oder Mediamatiker stehst du genau an der Schnittstelle: Du gestaltest die UI, aber du verantwortest sie im Dienst einer guten UX. Darum beginnt dieses Modul bei den Menschen und nicht beim Layout.

Den Nutzungskontext erfassen

Der Nutzungskontext beschreibt alles, was rund um die Nutzung wichtig ist. Fünf Fragen helfen dir, ihn vollständig zu erfassen:

1. Wer? Welche Gruppen nutzen die Oberfläche? (Badmintonspielende, Eltern, Seniorinnen im Aquafit)
2. Welches Ziel? Was wollen sie am Ende erreicht haben? (Platz für Donnerstagabend gesichert)
3. In welcher Situation? Wo, wann, unter welchem Zeitdruck? (in der Mittagspause, im Tram, mit einem Kind auf dem Arm)
4. Mit welchem Gerät und welchen Fähigkeiten? Handy oder Desktop, Touch oder Maus, Sehschwäche, wenig Deutschkenntnisse?
5. Wie oft? Einmal im Jahr (Kursanmeldung) oder jede Woche (Stammspieler)? Häufige Nutzende wollen Abkürzungen, seltene brauchen Führung.

Die Antworten holst du dir aus zwei Quellen: aus Daten (Webanalyse, Supportanfragen, Telefonnotizen) und aus Gesprächen mit echten Nutzenden. Nico wertet zuerst die Webanalyse aus: 70 Prozent der Besuche kommen vom Handy, und die meisten Abbrüche passieren bei der Wahl des Zeitfensters. Das sagt ihm, wo es klemmt, aber nicht warum. Dafür braucht er Interviews.

Ein kurzes Interview führen

Für diesen Zweck reichen kurze Gespräche von zehn bis fünfzehn Minuten, zum Beispiel an der Kasse. Ein Leitfaden mit wenigen offenen Fragen hält dich auf Kurs:

Interviewleitfaden Reservation (ca. 10 Min.)

Einstieg
- Wie oft kommst du ins Sportzentrum, und was machst du hier?

Letztes Mal erzählen lassen
- Erzähl mir, wie du deine letzte Reservation gemacht hast. Wo warst du?
- Was hast du als Erstes gemacht? Und dann?
- Gab es einen Moment, in dem du nicht weiterwusstest?

Ziele und Ärger
- Was ist dir beim Reservieren am wichtigsten?
- Was nervt dich daran am meisten?

Abschluss
- Gibt es etwas, das ich nicht gefragt habe, das aber wichtig ist?

Die wichtigste Regel: Frag nach vergangenem Verhalten, nicht nach Wünschen für die Zukunft. «Würdest du eine App mit Push-Nachrichten nutzen?» beantworten fast alle mit Ja, weil es höflich ist. «Erzähl mir, wie du letzte Woche reserviert hast» liefert dagegen echte Abläufe, echte Hindernisse und echte Ausweichstrategien (zum Beispiel: «Ich habe dann angerufen»).

Personas und Jobs-to-be-done

Nach sechs Gesprächen hat Nico viele Notizen. Damit das Team mit diesen Erkenntnissen arbeiten kann, verdichtet er sie in zwei Formate.

Persona: ein Gesicht für eine Gruppe

Eine Persona ist eine fiktive, aber auf Recherche gestützte Person, die eine typische Nutzergruppe vertritt. Für die UI-Arbeit braucht sie nicht viel, aber das Richtige:

• Name und kurzer Satz zur Situation
• Ziel(e) in Bezug auf die Oberfläche
• Nutzungskontext: Gerät, Ort, Zeitdruck, Häufigkeit
• Frustpunkte mit echten Zitaten
• was für sie «erfolgreich» bedeutet

Hobbys, Lieblingsessen und Sternzeichen haben in einer UI-Persona nichts zu suchen, ausser sie beeinflussen die Nutzung. Wie man Personas datenbasiert aus grossen Datenmengen ableitet, lernst du ausführlich in Modul 368. Hier reicht eine schlanke Arbeitspersona.

Jobs-to-be-done: die Aufgabe hinter dem Klick

Der Ansatz Jobs-to-be-done (JTBD) fragt nicht «Wer ist die Person?», sondern «Welche Aufgabe will sie gerade erledigt haben?». Menschen «engagieren» ein Produkt für einen Job. Eine Job Story hat diese Form:

Wenn [Situation], will ich [Motivation], damit [erwartetes Ergebnis].

Wenn ich am Montagmittag mit meinem Team abmache,
will ich sofort sehen, welche Plätze am Donnerstag ab 18 Uhr frei sind,
damit ich die Reservation erledigt habe, bevor alle wieder an der Arbeit sind.

Job Stories sind besonders nützlich, weil sie die Situation betonen. Daraus folgen oft direkte UI-Anforderungen: «sofort sehen» heisst, dass freie Zeiten ohne Login und ohne Scrollen sichtbar sein müssen.

User Stories mit Akzeptanzkriterien

Personas und Job Stories beschreiben das Problem. Das Entwicklungsteam braucht aber Anforderungen, die es umsetzen und prüfen kann. Dafür gibt es User Stories:

Als [Rolle] möchte ich [Funktion], damit [Nutzen].

Eine User Story ist erst dann brauchbar, wenn klar ist, wann sie erfüllt ist. Das leisten Akzeptanzkriterien. Bewährt hat sich das Format «Gegeben, Wenn, Dann» (auf Englisch Given, When, Then):

User Story
Als Badmintonspieler möchte ich die freien Zeiten eines Tages auf einen Blick sehen,
damit ich ohne Ausprobieren einen passenden Platz finde.

Akzeptanzkriterien
1. Gegeben ich öffne die Reservation auf einem Handy (390 px breit),
   wenn die Seite geladen ist,
   dann sehe ich ohne Scrollen mindestens 6 Zeitfenster des heutigen Tages.
2. Gegeben ein Zeitfenster ist belegt,
   wenn ich die Übersicht ansehe,
   dann ist es mit Text und Symbol als belegt erkennbar, nicht nur durch Farbe.
3. Gegeben ich tippe auf ein freies Zeitfenster,
   wenn die Auswahl erfolgt ist,
   dann sehe ich Platz, Datum, Zeit und Preis in CHF zusammengefasst.

Siehst du, wie konkret das ist? «Auf einen Blick» wurde zu «ohne Scrollen mindestens 6 Zeitfenster bei 390 px Breite». Das kann man im Prototyp und später im Code überprüfen. Kriterium 2 sorgt nebenbei schon für Barrierefreiheit, ein Thema, das dich in Lektion 8 wieder einholt.

Der ganze Weg von der Beobachtung zur Anforderung sieht so aus:

Schritt für Schritt: Von sechs Gesprächen zu prüfbaren Anforderungen

Nico hat an zwei Abenden an der Kasse sechs Gäste befragt. So geht er vor:

Schritt 1: Zitate wörtlich sammeln. Eine Notiz pro Aussage, mit Kürzel der Person:

Schritt 2: Muster bilden. Nico gruppiert die Zitate: Sichtbarkeit freier Zeiten (G1, G2, G4), doppelte Eingaben (G3), wiederkehrende Buchung (G5), fehlende Bestätigung (G6). Drei von sechs Personen nennen das gleiche Kernproblem: Sie finden freie Zeiten nicht.

Schritt 3: Zwei Personas ableiten.

Marco, 34, Badminton jeden Donnerstag
Ziel: in der Mittagspause schnell einen Platz für abends sichern
Kontext: Handy, unterwegs, 2 bis 3 Minuten Zeit, wöchentlich
Frust: «Ich sehe nie, was frei ist.»
Erfolg: Reservation in unter 2 Minuten, Bestätigung sofort sichtbar

Sandra, 41, sucht einen Schwimmkurs für ihre Tochter Lea (7)
Ziel: passenden Kurs finden und Lea anmelden
Kontext: Handy oder Laptop am Abend, 1 bis 2 Mal pro Jahr, braucht Führung
Frust: «Ich musste alles zweimal eingeben.» Unklare Begriffe
Erfolg: Kurs gefunden, Anmeldung bestätigt, ohne Anruf

Schritt 4: Job Stories formulieren. Für Marco: «Wenn ich mittags mit meinem Team abmache, will ich sofort die freien Plätze für heute Abend sehen, damit ich reservieren kann, bevor die Pause vorbei ist.»

Schritt 5: User Stories und Akzeptanzkriterien. Aus den Mustern entstehen fünf Stories, unter anderem die Story mit den drei Kriterien aus dem Abschnitt oben sowie diese:

Als Elternteil möchte ich die Daten meines Kindes nur einmal eingeben,
damit die Anmeldung nicht doppelt so lange dauert.
Kriterium: Gegeben ich bin im Schritt «Teilnehmende», wenn ich «Ich melde
mein Kind an» wähle, dann fragt das Formular Name und Geburtsdatum des
Kindes genau einmal ab und übernimmt meine Kontaktdaten automatisch.

Schritt 6: Anforderungen an die UI notieren. Nico übersetzt die Stories in eine kurze Liste, die später für Prototyp und Code gilt:

Diese Tabelle ist Gold wert: Jede spätere Gestaltungsentscheidung kann Nico mit einem Satz begründen, etwa «Die Tagesreiter sind 48 px hoch, weil G2 am Handy oft den falschen Tag trifft (UI-2)». Genau das wollen Expertinnen und Experten im Kompetenznachweis sehen.

Typische Fehler

1. Mit dem Layout beginnen. Wer zuerst gestaltet, baut seine eigenen Vorlieben. Korrektur: Erst Nutzungskontext und Ziele klären, dann skizzieren.
2. Suggestivfragen im Interview. «Wäre ein grösserer Kalender besser?» legt die Antwort in den Mund. Korrektur: «Erzähl mir, wie du zuletzt einen Tag ausgewählt hast.»
3. Persona als Steckbrief ohne Bezug zur Nutzung. Lieblingsband und Haustier helfen beim Gestalten nicht. Korrektur: Ziele, Kontext, Frust und Erfolgskriterium.
4. User Story ohne Nutzen. «Als Nutzer möchte ich einen Filter» sagt nicht, wozu. Korrektur: «damit ich nur Plätze mit Ballmaschine sehe».
5. Unprüfbare Kriterien. «Die Seite ist übersichtlich» kann niemand abnehmen. Korrektur: Zahlen, Zustände und beobachtbares Verhalten.

Zusammenfassung

• UI ist die bedienbare Oberfläche, UX das ganze Erlebnis beim Erreichen eines Ziels. Gute UI dient einer guten UX.
• Der Nutzungskontext klärt Wer, Ziel, Situation, Gerät und Häufigkeit. Daten zeigen, wo es klemmt, Interviews zeigen warum.
• Interviewfragen sind offen, neutral und fragen nach vergangenem Verhalten. Zitate wörtlich notieren.
• Personas machen Gruppen greifbar, Job Stories betonen die Situation: «Wenn …, will ich …, damit …».
• User Stories brauchen Akzeptanzkriterien im Format Gegeben, Wenn, Dann, mit prüfbaren Werten.
• Eine Anforderungstabelle mit Quelle macht jede spätere Gestaltungsentscheidung begründbar.