Eine Frau versucht, ein Folgerezept nachzubestellen. Mit einem Arm hält sie ein Kleinkind, mit der anderen Hand ihr Smartphone, den Daumen ausgestreckt nach einem Button in der oberen Ecke, während die Sonne so stark vom Display reflektiert, dass sie die Augen zusammenkneifen muss. Mitten in der Aufgabe kommt eine Nachricht, sie wirft einen kurzen Blick darauf, verliert den Faden und schließt die App. Niemand in Ihrem Team hat das mitbekommen, denn niemand in Ihrem Team testet so.
Genau das ist das stille Versagen im Kern der meisten Usability-Tests für mobile Apps: Die Methode wird unverändert aus dem Web übernommen, wo eine moderierte Session bedeutet, dass ein Teilnehmer an einem Schreibtisch sitzt, bei gutem Licht, mit freien Händen, und Ihnen fünfundvierzig Minuten lang seine volle Aufmerksamkeit schenkt. Desktop-Usability-Tests messen eine Version Ihres Nutzers, die es auf dem Smartphone nicht gibt.
Wie führt man Usability-Tests für mobile Apps durch?
Usability-Tests für mobile Apps bedeuten, echte Menschen dabei zu beobachten, wie sie echte Aufgaben auf dem tatsächlichen Gerät erledigen, unter Bedingungen, die der realen Nutzung des Produkts möglichst nahekommen, und dabei zu messen, ob sie die Aufgabe abschließen, wie lange sie dafür brauchen und wo sie hängen bleiben. Die Methode richtet sich nach der Fragestellung: moderierte Sessions auf dem Gerät für das „Warum“, unmoderierte Remote-Tests für die Skalierung, Guerilla-Tests für den realen Nutzungskontext und First-Launch-Studien für den Moment, den es nur ein einziges Mal gibt. Keine einzelne Methode deckt alle vier Fragen ab; die meisten Usability-Probleme liegen genau in der Lücke dazwischen.
So weit die Kurzfassung. Die ausführliche Version lautet: Usability-Tests für mobile Anwendungen sind nicht eine Tätigkeit, sondern vier, und wer für die Frage, die er eigentlich beantworten will, die falsche wählt, bekommt am Ende einen Bericht voller Befunde, die nicht vorhersagen, was nach dem Launch passiert.
Warum sich die Desktop-Methode nicht übertragen lässt
Führen Sie eine klassische moderierte Usability-Session durch, testen Sie eine Person mit zwei freien Händen, stabiler Verbindung und großem Bildschirm, die niemand anspricht und deren Akku keine Rolle spielt. Kommt das Produkt aufs Smartphone, konkurriert dieselbe Aufgabe plötzlich mit einer Bushaltestelle, einer Slack-Benachrichtigung, lückenhaftem Empfang und einem Daumen, der einen 6,7-Zoll-Bildschirm abdecken muss, ohne dass etwas herunterfällt.
Die Zahlen belegen, wie unterschiedlich Menschen diese Geräte tatsächlich halten und nutzen. In einer vielzitierten Feldstudie mit 1.333 Personen, die Mobilgeräte in der Öffentlichkeit nutzten, stellte der Forscher Steven Hoober fest, dass von denjenigen, die den Bildschirm berührten, 49 % ihr Smartphone mit einer Hand hielten, 36 % es in einer Hand abstützten und mit der anderen tippten und nur 15 % den beidhändigen „Gebetsgriff“ nutzten, von dem die meisten desktopgeprägten Designer standardmäßig ausgehen (UXmatters, “How Do Users Really Hold Mobile Devices?”). Fasst man diese Griffarten zusammen, steuern laut Josh Clark die Daumen 75 % aller Interaktionen mit dem Smartphone (A List Apart, “How We Hold Our Gadgets”). Wenn Ihr Usability-Test dem Teilnehmer das Smartphone in die Hand drückt und ihn bequem mit beiden Händen am Tisch arbeiten lässt, haben Sie bereits eine Haltung getestet, die nur etwa einen von sieben Ihrer tatsächlichen Nutzer beschreibt.
Hinzu kommt die Aufmerksamkeit. Ein Teilnehmer an einem Desktop-Test bekommt keinen Anruf. Ein mobiler Nutzer sehr oft schon, oder er ist gerade zu Fuß unterwegs oder nur einen Tab davon entfernt, etwas ganz anderes nachzusehen. Nichts davon ist auf Mobilgeräten ein Randfall. Es ist der Normalzustand.
Methoden für mobile Usability-Tests: die Auswahlmatrix
Jede Methode beantwortet eine andere Frage und macht Sie für eine andere Gruppe von Problemen blind. Wer nur eine davon einsetzt, meist die moderierte Session, weil sie am vertrautesten ist, lässt die anderen drei Fragen unbeantwortet.
Moderierte Sessions auf dem Gerät
Warum ein Nutzer zögert oder an einer Aufgabe scheitert; die Überlegung hinter dem Klick
Ablenkung im echten Leben, echter einhändiger Griff, wenn der Teilnehmer sitzt und entspannt ist
Vor dem Launch, Redesigns, komplexe Abläufe, die „lautes Denken“ erfordern
Unmoderierte Remote-Tests (Bildschirm- und Gesichtsaufzeichnung)
Erfolg oder Scheitern von Aufgaben in großer Zahl, über viele Geräte und OS-Versionen hinweg, ohne einen Moderator einplanen zu müssen
Das „Warum“ hinter einem Zögern; Sie sehen sich eine Aufzeichnung an, statt nachfragen zu können
Schnelle Validierung eines Ablaufs mit 15 bis 30 Teilnehmern, Vergleich zweier Designvarianten
Guerilla-Tests in der realen Umgebung
Wie die Aufgabe draußen funktioniert, einhändig, unterwegs bei Erledigungen, mit echtem Umgebungslärm und Blendlicht
Tiefe. Die Sessions sind kurz (5 bis 10 Minuten), und Randfälle lassen sich nicht vertiefen
Prüfen, ob ein Ablauf auch unter realen Bedingungen besteht, nicht nur im Labor
First-Launch- und Onboarding-Studien
Ob ein völlig neuer Nutzer den Mehrwert erreicht, bevor er aufgibt; die entscheidenden ersten 60 bis 90 Sekunden
Langfristige Usability, Verhalten bei wiederholten Besuchen, alles nach dem Onboarding
Jede App, bei der die Abwanderung am ersten Tag ein bekanntes oder vermutetes Problem ist
Keine dieser Methoden ersetzt eine andere. Eine moderierte Session, die zeigt, dass „Nutzer dieses Icon nicht verstehen“, und eine Guerilla-Session, die zeigt, dass „Nutzer dieses Icon bei direktem Sonnenlicht nicht antippen können“, decken zwei verschiedene Fehler mit zwei verschiedenen Lösungen auf, und ein Testplan mit nur einer Methode findet immer nur einen davon.
Wie viele Testpersonen brauchen Usability-Tests für mobile Apps?
Fünf Nutzer pro Segment und Runde sind nach wie vor der richtige Ausgangswert. Die Zahl stammt aus der Forschung von Jakob Nielsen und Thomas Landauer, hinter der die Nielsen Norman Group bis heute steht: Eine erste Runde mit fünf repräsentativen Teilnehmern deckt in der Regel rund 85 % der Usability-Probleme auf, die eine deutlich größere Studie finden würde, weil sich die meisten Probleme bei mehreren Nutzern wiederholen, statt nur bei einer einzelnen Person aufzutreten (NN/g, “Why You Only Need to Test with 5 Users”).
Der mobile Haken liegt darin, was als „ein Segment“ gilt. Wenn Ihre App deutlich unterschiedliche Nutzergruppen hat (ein Ablauf für pflegende Angehörige gegenüber einem für medizinisches Fachpersonal, eine überwiegend iOS-basierte Nutzerbasis gegenüber einer überwiegend Android-basierten mit älteren Geräten), braucht jede dieser Gruppen ihre eigenen fünf, nicht fünf, die auf alle verteilt werden. Und bei unmoderierten Remote-Tests lohnt es sich, weil sie pro Teilnehmer günstiger sind, meist über fünf hinaus auf 15 bis 30 zu gehen, damit Sie eine echte Streuung über Bildschirmgrößen, OS-Versionen und Netzwerkbedingungen erhalten, statt fünf Personen, die zufällig alle auf einem neuen iPhone über WiFi getestet haben.
Usability-Tests für mobile Apps in der Praxis: Onboarding im Detail
So sieht eine solche Studie in der Praxis aus, dargestellt an einem zusammengesetzten Onboarding-Ablauf, der Muster widerspiegelt, die QAwerk bei mobilen Kunden immer wieder beobachtet, und nicht ein einzelnes, namentlich genanntes Projekt.
Der getestete Ablauf: eine Onboarding-Sequenz aus fünf Screens für eine Content-Creation-App (Registrierung, Verbindung eines Social-Media-Kontos, Auswahl einer Startvorlage, Abschluss eines ersten Projekts, Aufruf des Speichern-/Export-Screens).
Aufgaben für die Teilnehmer: ein Konto ohne Hilfetexte anlegen, ein externes Konto verbinden, in weniger als drei Minuten ein erstes Stück Content erstellen und exportieren, alles auf dem eigenen Smartphone, einhändig, im Freien.
Erfasste Metriken: Abschlussrate pro Screen, Zeit pro Aufgabe, Anzahl der Taps bis zum ersten erfolgreichen Export und die Stelle im Funnel, an der jeder Teilnehmer abgebrochen hat (erfasst per Bildschirmaufzeichnung, nicht per Selbstauskunft, denn was Menschen nach eigener Aussage tun würden und was sie tatsächlich tun, stimmt bei einem Ablauf über fünf Screens selten überein).
Drei Befunde und die jeweilige Lösung:
- Beim Schritt „Konto verbinden“ stiegen 40 % der Tester aus, nicht weil die Integration defekt war, sondern weil der Bestätigungsbutton in der oberen rechten Ecke saß, einem Bereich, der bei den meisten Griffarten außerhalb der bequemen einhändigen Daumenreichweite liegt. Lösung: die primäre Aktion ins untere Drittel des Bildschirms verlegen, den Bereich, den jede Methode der obigen Matrix als ohne Griffwechsel erreichbar markiert hat.
- Tester bei direktem Sonnenlicht übersahen einen kontrastarmen „Überspringen“-Link, der drinnen gut lesbar war und bei Blendlicht verschwand, sodass sie auf den mühsameren manuellen Weg statt auf die Abkürzung auswichen. Lösung: das Kontrastverhältnis erhöhen und es im Freien testen, bevor man es als erledigt abhakt, denn eine Prüfung ausschließlich in Innenräumen lässt einen fehlerhaften Screen durchgehen.
- Ein Telefonanruf unterbrach drei von fünf Sessions, und zwei dieser drei Tester verloren ihren gesamten Onboarding-Fortschritt und mussten bei Screen eins neu beginnen. Lösung: den Formularstatus lokal speichern, damit eine Unterbrechung, die normales mobiles Verhalten und kein Fehler im Test ist, den Nutzer nicht seinen Fortschritt kostet.
Dieser dritte Befund ist genau der, den ein Test im Desktop-Stil strukturell nicht liefern kann, denn ein Desktop-Teilnehmer in einem ruhigen Raum wird nicht auf Kommando unterbrochen. Er zeigt sich nur, wenn das Testprotokoll reale Bedingungen zulässt, statt sie wegzukontrollieren.
Usability-Tests vs. Barrierefreiheitstests: unterschiedliche Fragen
Man wirft die beiden leicht in einen Topf, weil man in beiden Fällen jemandem bei der Nutzung einer App zusieht, doch sie beantworten unterschiedliche Fragen mit unterschiedlichen Bestehenskriterien. Usability-Tests fragen, ob eine Person die Aufgabe überhaupt abschließen kann und wie leicht ihr das fällt. Barrierefreiheitstests fragen, ob das jede Person kann, auch jemand, der VoiceOver, TalkBack oder die Schaltersteuerung nutzt, gemessen an einem definierten Standard wie WCAG 2.2. Ein Screen kann einen Usability-Test bestehen und bei der Barrierefreiheit trotzdem durchfallen, und auch der umgekehrte Fall kommt vor. Zur Compliance-Seite, zur Checkliste und zum Testprozess mit assistiven Technologien lesen Sie QAwerks Leitfaden zu Barrierefreiheitstests für mobile Apps.
Wann Usability-Tests für mobile Apps nicht die richtige Wahl sind
Nicht jedes Release braucht eine vollständige Studie. Eine kleine Textänderung oder ein reiner Backend-Fix rechtfertigt es nicht, Teilnehmer zu rekrutieren; ein fünfminütiger interner Walkthrough mit jemandem, der den Ablauf nicht kennt, findet die offensichtlichen Probleme. Und unmoderierte Remote-Tests sind das falsche Werkzeug, wenn Sie verstehen müssen, warum jemand an einer Aufgabe gescheitert ist, und nicht nur, dass er gescheitert ist; diese Frage erfordert eine moderierte Session, auch wenn sie pro Teilnehmer mehr kostet. Die teure Methode für eine Frage einzusetzen, die die günstige bereits beantwortet, ist ein häufiger Grund dafür, dass Usability-Budgets aufgebraucht sind, bevor sie bei dem Ablauf ankommen, der die genaue Prüfung wirklich braucht.
So führt QAwerk Usability-Tests für mobile Apps durch
Der Usability-Testprozess von QAwerk kombiniert Hallway-Tests, heuristische Evaluierung und strukturierte, aufgabenbasierte Sessions auf echten iOS- und Android-Geräten statt auf Simulatoren und prüft dabei den Navigationsfluss, das Verhalten interaktiver Elemente und ob die App tatsächlich das Ziel erfüllt, für das ein Nutzer sie geöffnet hat. Bei Unfold, der Content-Creation-App, die heute zu Squarespace gehört, brachte diese Kombination aus Funktions- und Usability-Tests auf 8 iOS- und 12 Android-Geräten über 1.000 Bugs und mehr als 2.800 Testszenarien vor Releases hervor, die der App halfen, eine 5-Sterne-Bewertung im App Store zu halten; alle Details finden Sie in der vollständigen Unfold-Fallstudie.
Da QAwerk in jeder Phase testet und nicht erst, wenn ein Build fertig ist, können Usability-Sessions an einem klickbaren Prototyp laufen, bevor auch nur ein Sprint in den falschen Ablauf investiert wird, oder an einer Live-App, um aufzudecken, was sich erst nach dem Launch zeigt. Sehen Sie sich den vollständigen Usability-Testprozess an oder die umfassenderen Testdienstleistungen für mobile Anwendungen, wenn Usability nur ein Teil einer größeren Prüfung vor dem Launch ist.
Checkliste für Usability-Tests mobiler Apps
Ob vollständige Studie mit fünf Teilnehmern oder schneller interner Bauchcheck: Usability-Tests für mobile Anwendungen laufen auf fünf Punkte hinaus, die Sie prüfen sollten, bevor Sie einen Ablauf als fertig betrachten:
- Daumenreichweite: Primäre Aktionen liegen in den unteren zwei Dritteln des Bildschirms, nicht in den oberen Ecken.
- Größe der Touch-Ziele: Interaktive Elemente sind mindestens 44x44pt (iOS) bzw. 48x48dp (Android) groß, mit echtem Abstand zwischen benachbarten Zielen, nicht nur mit optischem Padding.
- Fehlerwiederherstellung: Eine fehlgeschlagene Aktion (abgebrochene Verbindung, falscher Tap, unterbrochener Ablauf) teilt dem Nutzer mit, was passiert ist und wie er es erneut versuchen kann, ohne dass er seine Position verliert.
- Robustheit bei Unterbrechungen: Formular- und Ablaufstatus überstehen einen Telefonanruf, eine in den Hintergrund verschobene App oder eine Warnung bei niedrigem Akkustand.
- Einhändige Erreichbarkeit: Die Kernaufgabe lässt sich einhändig erledigen, getestet auf dem tatsächlichen Gerät und nicht nur auf einer Desktop-Spiegelung des Bildschirms geprüft.
Häufig gestellte Fragen
Wie führt man Usability-Tests für mobile Apps durch?
Rekrutieren Sie Teilnehmer, die Ihrer realen Nutzerbasis entsprechen, geben Sie ihnen realistische Aufgaben auf dem tatsächlichen Gerät (nicht auf einem Simulator oder einer Desktop-Spiegelung) und kombinieren Sie mindestens zwei Methoden, typischerweise eine moderierte Session für das „Warum“ und entweder Guerilla- oder unmoderierte Tests für reale Bedingungen, denn keine einzelne Methode erfasst sowohl Verständnisprobleme als auch umgebungsbedingte Probleme.
Welche Methoden gibt es für mobile Usability-Tests?
Die vier zentralen Methoden sind moderierte Sessions auf dem Gerät, unmoderierte Remote-Tests mit Bildschirm- und Gesichtsaufzeichnung, Guerilla-Tests in der realen Umgebung des Teilnehmers sowie First-Launch- oder Onboarding-spezifische Studien. Jede zielt auf eine andere Art von Fehler ab, und die meisten mobilen Produkte brauchen im Laufe ihres Lebenszyklus mehr als eine davon.
Wie viele Testpersonen brauchen Usability-Tests für mobile Apps?
Fünf Teilnehmer pro Nutzersegment und Testrunde decken in einem ersten Durchgang in der Regel den Großteil der Usability-Probleme auf. Unterschiedliche Nutzersegmente brauchen jeweils ihre eigenen fünf; unmoderierte Remote-Tests lohnt es sich meist auf 15 bis 30 Teilnehmer zu skalieren, um Geräte und Netzwerke ausreichend abzudecken.
Sind Usability-Tests für mobile Apps dasselbe wie Barrierefreiheitstests?
Nein. Usability-Tests prüfen, ob ein typischer Nutzer eine Aufgabe leicht abschließen kann. Barrierefreiheitstests prüfen, ob Nutzer, die auf assistive Technologien angewiesen sind, sie überhaupt abschließen können, gemessen an einem Standard wie WCAG 2.2. Die meisten mobilen QA-Programme brauchen beides, getrennt durchgeführt.
Wie lange dauert eine Runde Usability-Tests für mobile Apps?
Eine moderierte Runde mit fünf Teilnehmern dauert von Anfang bis Ende in der Regel ein bis zwei Wochen, einschließlich Rekrutierung, Sessions und Ergebnisbericht. Guerilla- und unmoderierte Runden gehen schneller, oft in drei bis fünf Tagen, weil die Terminplanung mit einem Moderator wegfällt.
Sehen Sie, wie wir Magic Mountain vom MVP zum Premium-Produkt gebracht haben mit täglich wachsenden Abonnements
