Um eine unübersichtliche App zu untersuchen, betrachten Sie ihre Bildschirme, Bedienelemente und Reaktionen, während jemand eine von der App unterstützte Aufgabe versucht. Achten Sie auf die erste Stelle, an der die nächste Aktion unklar wird. Vergleichen Sie die Erwartung der Person mit dem, was die App tut und meldet. Ein fehlgeschlagener Speichervorgang oder eine fehlende Funktion erfordert eine andere Korrektur als eine unklare Bezeichnung oder Route.
Stellen Sie sich vor, jemand versucht, eine bestehende Buchung zu ändern. Die Person öffnet mehrere Menüs, kehrt zum Startbildschirm zurück und fragt einen Kollegen. Diese Abfolge ist ein Ausgangspunkt für eine Beobachtung. Sie allein kann weder erklären, ob die Person die App später deinstalliert, noch welcher Bildschirm neu gestaltet werden muss.
Warum geht in einer unübersichtlichen App der nächste Schritt verloren?
Personen können das Ziel verstehen und dennoch eine unklare Aktion oder Reaktion übersehen. Wir suchen nach der ersten sichtbaren Abweichung zwischen der beabsichtigten Aufgabe und dem angezeigten Bildschirm. Legen Sie sich erst auf eine Erklärung fest, nachdem Sie den Vorgang geprüft haben. Was wie ein Navigationsproblem aussieht, kann auch eine fehlgeschlagene Anfrage oder ein vom Produkt nicht unterstütztes Ergebnis sein.
Die Formulierung deutet auf eine andere Aktion hin. Eine Person erwartet nach dem Tippen auf Weiter möglicherweise einen weiteren Prüfbildschirm, während die App sofort eine Anfrage sendet. Apples Leitlinien für Schaltflächen empfehlen, den Zweck deutlich zu machen. Vergleichen Sie die Erwartung mit der tatsächlichen Wirkung, bevor Sie eine Ersatzbezeichnung wählen.
Das Ergebnis bleibt ungewiss. Jemand tippt erneut, weil nicht erkennbar ist, ob die App die Anfrage angenommen hat. Prüfen Sie, was tatsächlich gespeichert und was auf dem Bildschirm gemeldet wurde. Eine fehlende Bestätigung und ein fehlgeschlagener Vorgang benötigen unterschiedliche Korrekturen.
Hinweise zur Eingabe erscheinen erst nach dem Fehler. Prüfen Sie, ob das Feld erklärt, welchen Wert es benötigt.
Für Webinhalte verlangt das W3C-Kriterium zu Beschriftungen oder Anweisungen Beschriftungen oder Anweisungen, wenn Inhalte eine Eingabe erfordern. Nutzen Sie diese Referenz für Webbildschirme innerhalb einer App. Native Apps benötigen eine separate plattformspezifische Prüfung.
Die Route verliert ihren Kontext. Jemand kehrt von einem Detailbildschirm zurück und findet das bearbeitete Element nicht wieder. Erfassen Sie diesen Ausgangspunkt, die gewählte Aktion und den resultierenden Bildschirm. Halten Sie den ersten verwirrenden Übergang so genau fest, dass er reproduzierbar ist.
Wie untersuchen Sie eine unübersichtliche App?
Beginnen Sie mit einem unterstützten Ergebnis und einem vergleichbaren Ausgangszustand. Verwenden Sie ein Testkonto und sichere Testdaten für Aktionen, die etwas senden, Kosten verursachen, Daten löschen oder andere Personen betreffen. Formulieren Sie das Ziel, ohne das Menü oder Bedienelement zu nennen, das dorthin führt. Sie möchten erfahren, was die Person finden und verstehen kann, bevor Sie eine Erklärung geben.
- Definieren Sie den Abschluss. Ist das beabsichtigte Ergebnis bei einer Buchungsänderung eine gesendete Anfrage oder eine bestätigte neue Buchung? Prüfen Sie, welches Ergebnis diese Version und dieses Konto unterstützen.
- Erfassen Sie den Ausgangszustand. Notieren Sie App-Version, Gerät, Sprache, Berechtigungen und ob die Buchung bereits besteht. Das Konto eines Administrators kann eine andere Route anzeigen als das Konto eines Kunden.
- Beobachten Sie, ohne das Bedienelement zu nennen. Bitten Sie die Person, das Ziel zu erreichen. Erfassen Sie den gewählten Bildschirm, die gelesene Bezeichnung und die Erwartung. Wenn Sie helfen, notieren Sie die Hilfe; ein späterer Abschluss macht sie nicht ungeschehen.
- Prüfen Sie das Ergebnis separat. Vergleichen Sie die sichtbare Reaktion mit der gespeicherten Buchung. Öffnen Sie sie im Testkonto erneut oder prüfen Sie den Testdatensatz des Anbieters. Ein Tippen oder ein nach Erfolg aussehender Bildschirm belegt nicht, dass die beabsichtigte Aktualisierung erfolgt ist.
Wenn Sie die App allein prüfen, erfassen Sie, was Sie reproduzieren können, und machen Sie diese Einschränkung sichtbar. Ihre Produktkenntnis verändert die Aufgabe. Eine spätere Beobachtung mit einer damit nicht vertrauten Person liefert andere Erkenntnisse.
Bearbeiten Sie diese fiktive Buchungsaufgabe
Betrachten Sie eine erfundene App zur Kursbuchung, mit der jemand einen anderen Kurstermin anfragen kann. Der Anbieter muss diese Anfrage annehmen, bevor sich die Buchung ändert. Die folgenden Notizen zeigen, wie sich ein Missverständnis untersuchen lässt. Für dieses Beispiel haben wir weder eine echte App noch ein echtes Konto oder einen Teilnehmer verwendet, und wir haben die vorgeschlagene Formulierung nicht getestet.
| Beobachtung | Notiz |
|---|---|
| Beabsichtigte Aufgabe | Eine bestehende Kursbuchung auf einen anderen Kurstermin verschieben. |
| Aktion und genauer Wortlaut | Die Person tippt auf Buchung ändern; die Schaltfläche sendet eine Anfrage. |
| Erwartetes Ergebnis | Die Person glaubt, dass der neue Kurstermin bereits gebucht ist. |
| Tatsächlicher Zustand | Die ursprüngliche Buchung bleibt bestehen, während die Anfrage auf Annahme wartet. |
| Vorgeschlagene Prüfung | Änderung anfragen und eine Meldung ausprobieren, die besagt, dass die Anfrage gesendet wurde. |
Die beobachtete Abweichung betrifft die Bedeutung der Aktion. Eine andere Bezeichnung ist eine Hypothese, die anhand des tatsächlichen Vorgangs geprüft werden muss. Wenn die Anfrage den Anbieter nie erreicht, untersuchen Sie auch den fehlgeschlagenen Vorgang. Wenn eine sofortige Bestätigung für das Produkt unverzichtbar ist, handelt es sich um eine separate Produktentscheidung und nicht um etwas, das eine Schaltflächenbezeichnung leisten kann.
Schreiben Sie eine Beobachtung vor deren Interpretation auf. “Buchung geöffnet, auf Buchung ändern getippt und Bestätigung erwartet” beschreibt das Verhalten in dieser fiktiven Übung. “Die Oberfläche ist schlecht” überspringt die Frage, die Sie noch beantworten müssen.
Nehmen Sie die kleinste Änderung vor, die die Beobachtung klärt
Wählen Sie eine Korrektur, die auf die erfasste Abweichung eingeht und den beabsichtigten Vorgang bewahrt. Beginnen Sie mit Formulierungen, Anweisungen oder Rückmeldungen, wenn diese Punkte ungewiss sind. Eine geänderte Navigationsstruktur oder eine umfassendere Neugestaltung benötigt eine in der Aufgabe begründete Rechtfertigung. Halten Sie Funktionsfehler sichtbar, damit eine klarere Erklärung keinen weiterhin fehlschlagenden Vorgang verdeckt.
-
Probieren Sie einen fokussierten Entwurf aus. Zeigen Sie für die fiktive Buchung eine vorgeschlagene Aktionsbezeichnung und den resultierenden Zustand in einem klickbaren Entwurf. Unsere App-UX-Audits und Prototypen folgen dieser Abfolge von der Aufgabe zum Prototyp. Vergleichen Sie die Erwartung der Person vor dem Tippen mit dem danach erkannten Zustand; beschreiben Sie die vorgeschlagene Bezeichnung nicht als nachgewiesene Verbesserung.
-
Prüfen Sie einen Fehlerpfad. Das W3C-Kriterium zur Fehlererkennung für Webinhalte verlangt, dass bei einem automatisch erkannten Eingabefehler das betroffene Element benannt und der Fehler in Textform beschrieben wird. Eine farbige Umrandung allein lässt diese Erklärung vermissen. Native Bedienelemente und eine vollständige Prüfung der Barrierefreiheit erfordern eigene plattformspezifische Prüfungen.
-
Prüfen Sie die Reaktion auf dem Bildschirm und mit assistiver Technologie. Bei Webinhalten behandelt das W3C-Kriterium zu Statusmeldungen, wie definierte Statusänderungen für assistive Technologien verfügbar gemacht werden, ohne den Fokus vom aktuellen Bedienelement wegzubewegen. Prüfen Sie, was auf dem Bildschirm erscheint und was assistive Hilfsmittel erkennen können. Ein Screenreader ist beispielsweise eine Software, die Inhalte einer Oberfläche vorlesen kann. Dieses ausgewählte Kriterium zertifiziert die App nicht, legt kein Ziel für die Reaktionszeit fest und repariert keinen langsamen Vorgang.
-
Verfolgen Sie den Webübergang. Wenn dieselbe Konto- oder Buchungsroute auf eine Webseite wechselt, beziehen Sie diesen Übergang in den Test ein. Die Entwicklung von Websites und Web-Apps sollte die Formulierung der Aufgabe und den tatsächlichen Zustand über diese Grenze hinweg bewahren.
Was sollten Sie nach der Änderung prüfen?
Wiederholen Sie dieselbe beabsichtigte Aufgabe von einem vergleichbaren Zustand aus und erfassen Sie, was passiert ist. Halten Sie App-Version, Gerät, Sprache und erhaltene Hilfe neben dem Ergebnis sichtbar. Ein nützlicher Vergleich betrifft die beobachtete Aufgabe: ob die Person die Aktion gefunden, ihre Wirkung verstanden und das tatsächliche Ergebnis erkannt hat. Lassen Sie weitergehende geschäftliche Schlussfolgerungen offen, bis Sie dafür Belege haben.
Erfassen Sie Abschluss und Hilfe gemeinsam, die erste falsche Abzweigung, Eingabefehler, welche die Person nicht deuten konnte, und ob sie eine Anfrage mit einer Bestätigung verwechselte. Wiederholen Sie relevante Prüfungen mit der Sprache und der Barrierefreiheitskonfiguration, die Sie untersuchen. Prüfen Sie längere Bezeichnungen und die über diese Konfiguration verfügbaren Informationen, statt anzunehmen, dass der englische Bildschirm jede Version repräsentiert.
Wenn Sie bereits App-Aktionen erfassen, etwa den Start einer Anfrage zur Buchungsänderung oder ihr Eintreffen beim Anbieter, prüfen Sie, ob die Aufzeichnungen diesen tatsächlichen Zuständen entsprechen. Betrachten Sie Veränderungen bei Supportfragen zusammen mit derselben Route. Fehlende App-Downloads sind ein separates Akquiseproblem; unser Leitfaden zu einer App ohne Downloads setzt an, bevor jemand das Produkt öffnet.
Eine erfolgreiche Wiederholung kann diese Beobachtung beschreiben. Sie kann weder feststellen, warum Personen die App deinstallieren, noch eine Veränderung der Bindung der Korrektur zuschreiben. Erfassen Sie die nächste ungelöste Frage zusammen mit der für ihre Prüfung verantwortlichen Person.
Wo wir ins Spiel kommen
Wir beginnen mit der unterstützten Aufgabe, dem ersten unklaren Übergang und den erforderlichen Nachweisen für die Wahl einer Korrektur. Daraus können wir einen Prototyp erstellen, die implementierte Route prüfen und ihr Web-Gegenstück einbeziehen. Bringen Sie eine Beschreibung der Aufgabe und der Stelle, an der sie stoppte, zu einem Projektgespräch mit. Entfernen Sie Kundennamen und andere personenbezogene Daten aus jedem Beispiel, das Sie teilen.
