Usability-Tests für Apps: Menschen bei echten Aufgaben beobachten

Technisch richtig ist nicht automatisch verständlich

Stellen Sie sich eine App für Kursbuchungen vor. Eine Teilnehmerin möchte ihre bereits angezahlte Fitnessstunde auf Donnerstag verschieben. Sie findet die Buchung, sieht einen passenden Termin und bleibt trotzdem stehen. Bedeutet „Ändern“, dass die Anzahlung erhalten bleibt? Oder wird zuerst die alte Buchung storniert?

Das ist ein erfundenes Beispiel, kein Kundenbericht. Es zeigt eine wichtige Lücke: Die Anwendung kann eine Umbuchung fehlerfrei ausführen, während ein Mensch nicht sicher genug ist, sie auszulösen. Eine technische Prüfung würde hier möglicherweise bestehen. Ein Nutzungstest macht die Unsicherheit sichtbar.

Wenn Sie nur fragen, ob die Oberfläche gefällt, erfahren Sie wenig über diese Entscheidung. Geben Sie stattdessen eine realistische Aufgabe und sehen Sie zu. Das ergänzt den UX-Designprozess für Apps, ohne dass daraus gleich ein umfangreiches Forschungsprojekt werden muss.

Stellen Sie eine Frage, die sich beobachten lässt

„Ist unsere App leicht zu bedienen?“ klingt nach einem vernünftigen Forschungsziel. Für eine erste Runde ist es meist zu weit gefasst. Jemand findet die Buchung nicht, jemand anderes findet sie sofort, versteht aber die Zahlungsbedingungen falsch. Aus beiden Beobachtungen folgt nicht dieselbe Änderung.

Grenzen Sie die Frage deshalb ein: Können Menschen eine angezahlte Kursbuchung verschieben und erklären, was dabei mit der Anzahlung passiert? Damit prüfen Sie einen konkreten Ablauf und eine konkrete Erwartung. Am Ende lässt sich entscheiden, ob die Information zur Umbuchung überarbeitet werden muss.

Notieren Sie vorab, woran Sie einen erfolgreichen Abschluss erkennen: die richtige Buchung gefunden, einen neuen Termin gewählt und den neuen Zustand einschließlich Zahlung verstanden. Diese Kriterien gehören in Ihre Unterlagen, nicht in die Aufgabenbeschreibung. Sonst verraten Sie einen Teil der Antwort.

Auch die Grenzen des Verfahrens sind wichtig. Ob Ihre Geschäftsidee genügend Nachfrage findet, gehört zur Validierung einer App-Idee. Abstürze, Zahlungsfehler und Datenverlust erfordern eigene Prüfungen. Bedienbarkeit und technische Zuverlässigkeit hängen zusammen, sind aber nicht austauschbar.

Testen Sie die passende Version, nicht zwingend die fertige App

Für Fragen zur Reihenfolge der Ansichten oder zur Bedeutung von Texten reicht oft ein klickbarer Prototyp. Für Tastaturverhalten, Benachrichtigungen und Unterbrechungen ist eine funktionsfähige App aussagekräftiger. Der Vergleich zwischen Prototyp und MVP hilft bei dieser Auswahl.

Bereiten Sie einen Testzugang mit einer glaubwürdigen Buchung vor. Dann beginnt die Sitzung dort, wo Ihre Frage liegt, statt mit einer langen Registrierung. Nutzen Sie erfundene Kundendaten und eine sichere Zahlungsumgebung. Niemand sollte im Versuch einen echten Kurs stornieren oder versehentlich eine Zahlung auslösen.

Kennen Sie die Grenzen des Prototyps. Eine noch nicht gebaute Verknüpfung ist kein Beleg dafür, dass jemand die Oberfläche nicht versteht. Umgekehrt sollten Sie nicht vorsorglich jede Ansicht erklären. Auch ein unfertiger Prototyp kann zeigen, ob die vorhandenen Bezeichnungen verständlich sind.

Geeignete Menschen sind wichtiger als bequeme Termine

Kolleginnen und Kollegen kennen häufig den vorgesehenen Weg. Sie erinnern sich an Besprechungen und verstehen deshalb eine Bezeichnung, die Außenstehenden nichts sagt. Freunde möchten helfen und halten sich mit Kritik womöglich zurück. Beide Gruppen können den Ablauf der Sitzung erproben, ersetzen aber nicht automatisch die künftige Zielgruppe.

Für die Kurs-App interessieren Menschen, die kürzlich einen Kurs gebucht und einen Termin geändert haben. Fragen Sie nach dieser konkreten Erfahrung: Wie lief es ab, auf welchem Gerät und mit welchen Unsicherheiten? Ein allgemeines „Würden Sie eine solche App nutzen?“ liefert deutlich weniger Anhaltspunkte.

Nielsen Norman Group erläutert die Teilnehmerzahl im Zusammenhang mit qualitativen, wiederholten Untersuchungen. Fünf passende Personen können für einen eng umrissenen ersten Durchgang sinnvoll sein. Das ist keine statistische Aussage über den ganzen Markt.

Kursgäste, Lehrkräfte und Verwaltungsmitarbeitende haben unterschiedliche Aufgaben. Fünf Personen aus diesen drei Rollen ergeben nicht fünf Beobachtungen je Rolle. Untersuchen Sie unterschiedliche Bedürfnisse getrennt, statt aus einer kleinen gemischten Runde eine große Schlussfolgerung abzuleiten.

Die Aufgabe darf den Lösungsweg nicht vorwegnehmen

„Öffnen Sie Meine Buchungen, tippen Sie auf Bearbeiten und wählen Sie Donnerstag“ lässt kaum erkennen, ob die Navigation verständlich ist. Sie haben sie gerade erklärt. Die Person führt nun Ihre Anleitung aus.

Ein brauchbares Szenario beschreibt die Situation und das Ziel. Welche Elemente dafür nötig sind, muss die Person selbst herausfinden. Die NN/G-Empfehlungen zu Aufgabenszenarien erklären diesen Unterschied. Unsere eigenen Beispiele für die Kurs-App sehen so aus:

Wenn jemand wegen unklarer Bedingungen abbricht, kann das ein wertvolles Ergebnis sein. Im Alltag würde diese Person vielleicht beim Anbieter anrufen. Ein Test muss keinen erfolgreichen Abschluss erzwingen, um nützlich zu sein.

Lassen Sie die Unsicherheit sichtbar werden

Erklären Sie zu Beginn, dass die App geprüft wird, nicht die Fähigkeiten der Person. Besprechen Sie eine mögliche Aufzeichnung und holen Sie vorher die Zustimmung ein. Auf dem eigenen Smartphone können private Nachrichten erscheinen. Vereinbaren Sie, wie damit umgegangen wird und wer eine Aufzeichnung sehen darf. Die GOV.UK-Anleitung für moderierte Tests behandelt diese Vorbereitung.

Danach braucht es etwas Zurückhaltung. Ein kurzer stiller Moment fühlt sich für Beobachtende oft länger an, als er ist. Ein gut gemeintes „Die Schaltfläche ist weiter unten“ verändert die Situation sofort. Ab jetzt sehen Sie Nutzung mit Unterstützung. Helfen Sie, wenn das für die Sitzung nötig ist, und dokumentieren Sie den Hinweis.

Neutrale Fragen sind hilfreicher: „Was erwarten Sie an dieser Stelle?“ oder „Was ist Ihrer Meinung nach gerade passiert?“ Dagegen lenkt „Haben Sie gesehen, dass die Anzahlung erhalten bleibt?“ schon zur gewünschten Deutung. Auch Lob für den vorgesehenen Weg kann dazu führen, dass Teilnehmende Ihre Zustimmung suchen.

Die Moderationshinweise der GDS-Forschenden bieten dazu praktische Anregungen. Fragt jemand nach der Bedeutung eines Wortes, fragen Sie zunächst, wie diese Person es selbst versteht. Die Erklärung können Sie später geben; die unbeeinflusste Erwartung lässt sich nicht nachholen.

Auf dem Smartphone gelten andere Bedingungen

In einer großen Entwurfsansicht ist viel Platz. Auf einem gewöhnlichen Telefon verdeckt die Tastatur vielleicht den nächsten Schritt. Ein längeres Datum bricht um, oder eine wichtige Aktion lässt sich mit einer Hand schlecht erreichen. Solche Details sind entscheidend, wenn sie mitten in der eigentlichen Aufgabe auftreten.

Machen Sie daraus keinen künstlichen Hindernislauf. Beobachten Sie zunächst eine normale Nutzung und prüfen Sie anschließend Bedingungen, die für Ihre Zielgruppe relevant sind. Werden Buchungen unterwegs geändert, kann eine kurze Unterbrechung sinnvoll sein: Ist der gewählte Termin danach noch vorhanden? Benötigt die Zielgruppe größere Schrift, testen Sie die passende Einstellung.

Auch die Sprache gehört zur Bedienung. Eine englische Sitzung bestätigt nicht, dass deutsche Bezeichnungen und Datumsangaben klar sind. Verwenden Sie die tatsächliche Sprachversion. Und verwechseln Sie allgemeine Bedienbarkeit nicht mit einer vollständigen Prüfung der Barrierefreiheit. Der Leitfaden zur App-Barrierefreiheit hilft, dafür gezielt weitere Untersuchungen zu planen.

*Eine Illustration des Vorgehens: erst die Unterbrechung im Weg erkennen, dann beim Weiterkommen helfen.*

Beobachtung, Deutung und Lösung sind drei verschiedene Dinge

„Die Schaltfläche ist zu klein“ klingt bereits nach einem Befund. Vielleicht ist es aber nur Ihre erste Vermutung. Genauer wäre: Die Person öffnet die Buchung zweimal, liest die Zahlungszeile und hält inne. Auf Nachfrage erklärt sie, dass sie bei einer Terminänderung den Verlust der Anzahlung erwartet. In diesem erfundenen Fall behebt eine größere Schaltfläche die Unsicherheit womöglich überhaupt nicht.

Halten Sie deshalb fest, was Sie gesehen haben, wie Sie es erklären und welche Änderung Sie daraus ableiten. Vielleicht erscheint die Information zur Zahlung zu spät. Eine frühere Erklärung wäre dann eine überprüfbare Lösungsidee, noch kein bewiesener Erfolg.

Unterscheiden Sie den Abschluss ohne Hilfe, mit Hilfe und den Abbruch. Beschreiben Sie außerdem die Folge: zusätzliche Suchzeit, falscher Termin oder versehentliche Stornierung. „Zwei von fünf Personen brauchten in dieser Runde einen Hinweis“ ist nachvollziehbar. Daraus folgt nicht, dass 40 Prozent aller Kundinnen und Kunden scheitern werden.

Die Schwere zählt neben der Häufigkeit. Eine einzige Beobachtung einer möglichen falschen Stornierung kann dringlicher sein als mehrere Geschmacksurteile über eine Farbe. Die Daten unterstützen Ihre Entscheidung; sie treffen sie nicht automatisch.

Ändern Sie die Ursache und prüfen Sie erneut

Wenn Sie Navigation, Formulierungen und Anordnung gleichzeitig umbauen, kann die nächste Sitzung besser verlaufen, ohne dass Sie wissen, warum. Beginnen Sie mit der plausibelsten Ursache und einer gezielten Änderung. Für unser Beispiel wäre das eine verständliche Information zur Anzahlung vor der Entscheidung.

Geht es um die erste Nutzung, sind neue Teilnehmende besonders hilfreich. Wer den Weg bereits kennt, kann ihn aus dem Gedächtnis wiederholen. Frühere Teilnehmende eignen sich für andere Fragen, solange Sie diesen Unterschied beachten. Lassen Sie auch den Endzustand erklären: Eine erreichte Bestätigung beweist noch nicht, dass die alte Buchung richtig verstanden wurde.

Nach dem Start kann die Nutzungsanalyse der App zeigen, wo Menschen einen Ablauf verlassen. Beobachtungen helfen, die Gründe zu verstehen, und Betatests liefern Erfahrungen mit weiteren Geräten und Nutzungssituationen. Diese Methoden ergänzen sich.

Eine Seite Vorbereitung reicht für den ersten Versuch: Forschungsfrage, passende Personen, wenige Aufgaben, Ausgangskonto, Notizen und die nächste Entscheidung. Wenn Sie dafür Entwicklungshilfe brauchen, schildern Sie Appfyl das konkrete Hindernis oder halten Sie es in einem kurzen Projektbriefing fest. Eine ungeklärte Nutzerentscheidung ist aussagekräftiger als die bloße Bitte um einen weiteren Bildschirm.

Häufige Fragen