Usability systematisch evaluieren

Usability systematisch evaluieren

0:00 Tag drei beginnt, und mit ihm das Prüfen. Wir haben zwei Tage lang gebaut — jetzt schauen wir nach, ob es funktioniert. Und der Leitsatz dieses Moduls ist eine der zuverlässigsten Beobachtungen der ganzen Disziplin: Was Menschen sagen und was sie tun, fällt regelmäßig auseinander. Das ist keine Kritik an Menschen, das ist einfach, wie unser Gedächtnis arbeitet. Wir konstruieren im Nachhinein plausible Geschichten über unser eigenes Verhalten.

0:27 Genau deshalb sind Beobachtungen so viel wertvoller als Befragungen — und genau deshalb sind sie teurer. Ob sie es wert sind, klärt dieses Modul.

Usability systematisch evaluieren

0:36 Der dritte Tag ist nach Prüftiefe sortiert. Erst Usability — also dieses Modul —, dann Accessibility Testing, dann der Prozess, in dem beides verankert wird. Und danach die KI, die auf all dem aufsetzt. Innerhalb dieses Moduls gehen wir acht Kapitel durch: die Unterscheidung formativ und summativ, zwei Expertenverfahren, dann der aufgabenbasierte Test mit seinen Kennzahlen.

0:57 Danach die besonderen Anforderungen bei Sitzungen mit Menschen mit Behinderungen, die Begründung für Beobachtung statt Befragung, und zum Schluss die Frage, wie aus Befunden tatsächlich Änderungen werden.

Formative und summative Evaluation

1:10 Zwei Wörter, die den Aufbau einer ganzen Untersuchung bestimmen. Der Unterschied klingt akademisch und entscheidet darüber, ob Ihre Ergebnisse überhaupt etwas taugen. Denken Sie an einen Hausbau. Formative Evaluation ist der Bauleiter, der während der Arbeit immer wieder vorbeischaut und Probleme findet, solange Ändern billig ist.

1:30 Summative Evaluation ist die Bauabnahme am Ende, die einen Zustand feststellt und protokolliert. Beides ist sinnvoll, und beides braucht einen völlig anderen Aufbau. Formativ arbeiten Sie mit wenigen, gut beobachteten Personen und suchen Ursachen. Summativ brauchen Sie viele Teilnehmende und statistische Tragfähigkeit, weil Sie eine Zahl produzieren wollen, die etwas bedeutet.

1:52 Wer das verwechselt, bekommt Ergebnisse, die keiner der beiden Fragen antworten. Die entscheidende Zeile ist die dritte: die Stichprobe. Formativ genügen fünf Personen — das reicht, um die groben Probleme zu finden, weil dieselben Hürden bei fast jedem auftreten. Summativ brauchen Sie ein Vielfaches, weil Sie eine belastbare Zahl wollen.

2:12 Und daraus folgt die häufigste Enttäuschung in diesem Feld: der Versuch, mit fünf Personen eine Kennzahl zu belegen. „Achtzig Prozent haben die Aufgabe geschafft" — das sind vier von fünf, und das ist keine Aussage über Ihre Nutzerschaft. Der Aufbau entscheidet über die Aussagekraft, nicht der Fleiß bei der Durchführung.

2:32 Der erste Stolperstein ist der eben besprochene: mit fünf Personen eine Kennzahl belegen wollen. Der zweite ist die kommunikative Variante desselben Fehlers: formativ testen und das Ergebnis als Qualitätsnachweis verkaufen. „Wir haben getestet" klingt gut und beantwortet die Frage nach dem Zustand nicht. Und der dritte ist ein Reihenfolgefehler mit Geldverschwendung: summativ messen, bevor die groben Probleme behoben sind.

2:56 Dann bezahlen Sie eine teure Messung, die Ihnen sagt, was eine formative Runde mit fünf Leuten für einen Bruchteil gefunden hätte. Erst finden, dann beheben, dann messen.

Heuristische Evaluation und Cognitive Walkthrough

3:07 Jetzt zwei Verfahren, die ohne Testpersonen auskommen — schnell, günstig und mit einer Grenze, die man kennen muss. Sie finden nämlich zuverlässig die Probleme von Fachleuten. Zwei verschiedene Zugänge. Bei der heuristischen Evaluation prüfen mehrere Fachleute unabhängig voneinander gegen einen festen Satz Prinzipien und führen ihre Befunde anschließend zusammen.

3:29 Das Unabhängige ist der Kern — jeder sieht anderes, und die Zusammenführung erzeugt den Wert. Beim Cognitive Walkthrough geht eine Gruppe eine Aufgabe Schritt für Schritt durch und stellt an jedem Schritt dieselbe Frage: Weiß eine unerfahrene Person hier, was zu tun ist? Das ist mühsam und deshalb wirksam. Beide Verfahren sind hervorragende Vorstufen zu einem echten Test — sie räumen das Offensichtliche weg, bevor Sie Menschen einladen.

3:54 Achten Sie auf die letzte Zeile — sie ist bei beiden Verfahren identisch, und das ist die eigentliche Aussage dieser Tabelle. Die Grenze ist in beiden Fällen die Sicht der Fachleute. Sie finden Verstöße gegen Prinzipien und Lücken in der Benutzerführung, und zwar zuverlässig und günstig. Was sie nicht finden, sind die Überraschungen: der Weg, auf den niemand im Team gekommen wäre, das Wort, das außerhalb des Hauses etwas anderes bedeutet, die Erwartung aus einer ganz anderen Anwendung.

4:22 Diese Befunde bekommen Sie nur von Nutzenden. Nutzen Sie die Expertenverfahren zum Vorräumen, nicht als Ersatz. Der erste Stolperstein ist eine Etikettenfrage mit Folgen: die Befunde als Nutzerbefunde ausgeben. Im Bericht liest sich das gleich, in der Diskussion trägt es nicht — „die Nutzer sagen" ist etwas anderes als „wir haben festgestellt".

4:42 Der zweite ist ein Aufbaufehler bei der heuristischen Evaluation: nur eine Person prüfen lassen. Der Nutzen entsteht aus der Zusammenführung mehrerer unabhängiger Blicke; mit einer Person ist es eine Meinung. Und der dritte ist beim Walkthrough entscheidend: ihn mit Menschen fahren, die den Ablauf gebaut haben. Sie können die Frage „weiß eine unerfahrene Person das?" schlicht nicht ehrlich beantworten.

Aufgabenbasierte Usability-Tests

5:06 Jetzt zum Kern der Untersuchung. Und der ganze Test steht und fällt mit einem einzigen Unterschied — dem zwischen einer Aufgabe und einer Anleitung. Der lässt sich an einem Satz zeigen. Eine gute Aufgabe beschreibt eine Situation und ein Ziel — und keinen Weg. „Sie fahren nächsten Freitag nach Kirchbach und sitzen gern am Fenster.

5:27 Buchen Sie die Fahrt." Das ist eine Aufgabe. „Klicken Sie auf Sitzplatzwahl" ist eine Anleitung, und sie misst nichts außer der Fähigkeit, Anweisungen zu befolgen. Das klingt banal und ist der häufigste Grund, warum Usability-Tests erstaunlich gute Ergebnisse liefern und trotzdem nichts finden. Denn wenn die Wörter der Oberfläche in der Aufgabe stehen, haben Sie den Weg mitgeliefert — und genau der Weg war die Frage.

5:52 Vergleichen Sie die beiden Formulierungen. Oben stehen die Wörter der Oberfläche direkt in der Aufgabe: „Sitzplatzwahl", „Plan", „Fensterplatz". Die Person muss nur noch suchen, wo diese Wörter stehen — das ist ein Suchbild-Spiel, kein Test. Unten steht eine Situation: Termin, Ziel, Vorliebe, und dann das Ziel. Der Weg dorthin ist die Leistung, die wir beobachten wollen.

6:15 Das ist übrigens genau der Kniff aus dem Tree Test in Modul vier — dort haben Sie es schon einmal gesehen, und die Regel ist dieselbe. Sobald die Oberflächenwörter in der Aufgabe stehen, ist der Weg vorgegeben. Der erste Stolperstein ist der gerade besprochene und der folgenreichste: die Begriffe aus der Navigation in die Aufgabe schreiben.

6:36 Er passiert versehentlich, weil man die Anwendung kennt und in ihren Begriffen denkt. Lassen Sie die Aufgaben von jemandem gegenlesen, der die Oberfläche nicht kennt. Der zweite ist ein Realitätsproblem: Aufgaben stellen, die im echten Leben niemand hätte. Menschen verhalten sich dann anders, weil ihnen die Motivation fehlt.

6:55 Und der dritte ist der schwerste, weil er so menschlich ist: während des Tests Hilfestellung geben. Damit löschen Sie exakt den Befund, den Sie gerade beobachten.

Erfolgsquote, Bearbeitungszeit, Fehler und Abbrüche

7:05 Vier Kennzahlen genügen für fast alle Fragen. Der entscheidende Punkt liegt aber nicht bei den Zahlen, sondern beim Zeitpunkt ihrer Definition. Vier Zahlen — mehr brauchen Sie in aller Regel nicht. Und die eigentliche Arbeit steckt darin, sie vorher zu definieren. Was gilt als Erfolg? Zählt es, wenn die Person gebucht hat, aber den falschen Tag? Wann beginnt die Zeitmessung — beim Erscheinen der Seite oder beim ersten Klick? Was zählt als Fehler?

7:32 Ohne diese Festlegung wird nachträglich interpretiert. Und dann passiert das, was in jeder Disziplin passiert, in der man nachträglich definiert: Die Zahlen bestätigen die Erwartung derjenigen, die sie auswerten. Nicht aus Unehrlichkeit — die Grenzfälle werden einfach unbewusst in die naheliegende Richtung entschieden. Die rechte Spalte beschreibt, was passiert, wenn Sie es nicht vorher tun. Teilerfolge werden großzügig gewertet — das kennen wir seit Modul eins.

8:01 Zeiten sind nicht vergleichbar, weil verschiedene Startpunkte gewählt wurden. Nur Auffälliges wird als Fehler gezählt, also das, was der Beobachter bemerkt hat. Und die letzte Zeile ist die interessanteste: Ohne Abbruchdefinition gilt Aufgeben als lange Bearbeitung. Jemand hat resigniert, und in Ihren Daten steht eine hohe Zeit bei erfolgreichem Abschluss.

8:22 Das verschiebt die ganze Auswertung — Sie sehen dann ein Effizienzproblem, wo ein Effektivitätsproblem war. Der erste Stolperstein ist die nachträgliche Großzügigkeit: Teilerfolge als Erfolg werten und die Quote schönrechnen. Der zweite ist eine subtile Messverschiebung, die gut gemeint ist: die Zeit erst ab dem zweiten Klick messen, weil der erste ja Suchen war. Genau dieses Suchen wollten Sie messen.

8:46 Und der dritte macht Vergleiche wertlos: Kennzahlen zwischen zwei Testrunden unterschiedlich definieren. Wenn Sie nach dem Umbau erneut messen, muss dieselbe Definition gelten — sonst vergleichen Sie zwei verschiedene Größen und feiern eine Verbesserung, die aus der Definition kommt.

Moderierte Tests und Nutzer mit Behinderungen

9:03 Jetzt kehrt ein Thema aus Modul zwei zurück, diesmal aus der Prüfperspektive. Sitzungen mit Menschen mit Behinderungen brauchen mehr Vorbereitung — und einen Prüfschritt, der über die Gültigkeit entscheidet. Zunächst die allgemeine Abwägung: Moderiert bekommen Sie Nachfragen und Begründungen, unmoderiert mehr Teilnehmende zu geringeren Kosten. Beides hat seinen Ort.

9:24 Für Menschen mit Behinderungen ist moderiert allerdings meist die bessere Wahl, und zwar aus einem sehr praktischen Grund: Technische Hürden im Testwerkzeug erscheinen sonst als Produktprobleme. Wenn die Testplattform selbst nicht mit dem Screenreader funktioniert, protokollieren Sie Befunde über die Plattform und halten sie für Befunde über Ihr Produkt.

9:44 Ein Moderator merkt das. Ein automatisiertes Protokoll nicht. Deshalb brauchen solche Sitzungen mehr Vorbereitung — schauen wir sie uns an. Diese fünf Schritte kennen Sie aus Modul zwei, und sie sind hier genauso gültig. Verständliche Aufgaben ohne Vorwissen. Teilnehmende über eine Interessenvertretung oder ein Panel. Entschädigung und Ablauf vorab schriftlich — das ist Arbeit, und Arbeit wird bezahlt.

10:09 Schritt vier ist der über die Gültigkeit entscheidende: Prüfen Sie den Testaufbau selbst auf Barrieren. Das Terminwerkzeug, das Einverständnisformular, die Videokonferenz, die Einladungsmail. Ein unzugängliches Testwerkzeug misst am Ende sich selbst. Und Schritt fünf: eigene Technik der Teilnehmenden, nicht gestellte. Menschen haben ihre Software über Jahre eingerichtet; auf fremder Konfiguration testen Sie die Umstellung.

10:36 Der erste Stolperstein ist der eben genannte: mit gestellter Technik testen. Was Sie dann sehen, ist jemand, der sich in einer fremden Umgebung zurechtfinden muss — das hat mit Ihrer Anwendung wenig zu tun. Der zweite: ohne Aufwandsentschädigung anfragen und Freiwilligkeit voraussetzen. Das ist nicht nur unfair, es verzerrt auch die Teilnehmerschaft.

10:56 Und der dritte ist ein Planungsfehler, den ich häufig sehe: die Sitzung so eng takten, dass für Umwege keine Zeit bleibt. Dann drängt der Moderator, die Person spürt es und beeilt sich — und genau die Umwege, die Sie beobachten wollten, finden nicht mehr statt.

Beobachtung statt Meinungsabfrage

11:12 Jetzt zur Begründung für den ganzen Aufwand. Warum sind Usability-Tests teurer als Umfragen, und warum lohnt sich das trotzdem? Die Antwort hat mit unserem Gedächtnis zu tun. Der Leitsatz dieses Moduls kommt hier zu seinem Kern: Was Menschen sagen und was sie tun, fällt regelmäßig auseinander. Die Frage „Fanden Sie das verständlich?" liefert Ihnen Höflichkeit — die meisten Menschen wollen nicht sagen, dass sie etwas nicht verstanden haben, und viele erinnern die Schwierigkeit auch gar nicht mehr, sobald sie am Ziel sind.

11:44 Die Beobachtung des dritten Anlaufs dagegen liefert einen Befund. Meinungen sind nicht wertlos — als Ergänzung sind sie nützlich, sie erklären das Erlebte. Als Hauptdatenquelle taugen sie nicht. Deshalb protokollieren wir Handlungen und nicht Aussagen. Vier Dinge, die eine Befragung strukturell nicht liefern kann. Den Moment des Zögerns — niemand erinnert später, dass er drei Sekunden gezögert hat, und genau dort sitzt das Problem.

12:09 Den Umweg, den die Person selbst für den richtigen Weg hält; sie kann ihn nicht berichten, weil sie ihn nicht als Umweg wahrnimmt. Die Stelle, an der geraten statt gelesen wird — das ist mein liebster Befundtyp, weil er so viel über Beschriftungen verrät. Und den Abbruch, der in der Befragung als kleine Unsicherheit erscheint. Alle vier haben gemeinsam: Sie sind dem Beobachteten selbst nicht zugänglich.

12:33 Der erste Stolperstein ist der Kurzschluss aus Modul eins: nach Zufriedenheit fragen und daraus auf Bedienbarkeit schließen. Zufriedenheit hängt stark an Optik und Freundlichkeit, nicht an der Erfolgsquote. Der zweite ist der schwerste im Moderationsalltag, und er passiert aus Mitgefühl: während der Beobachtung erklären.

12:52 In dem Moment, in dem Sie helfen, ändert sich das Verhalten — und Sie beobachten ab dann jemanden, der Ihre Erklärung anwendet. Und der dritte ist ein Protokollfehler mit Folgen: Aussagen protokollieren statt Handlungen. Später liest jemand das Protokoll und findet Meinungen, wo Beobachtungen stehen sollten.

Ergebnisse priorisieren und in Anforderungen überführen

13:10 Das letzte inhaltliche Kapitel behandelt den Schritt, an dem die meisten Untersuchungen versanden. Ein Bericht ist kein Ergebnis — er ist ein Dokument, bis daraus Tickets werden. Ein Bericht ohne Priorisierung erzeugt keine Änderung. Er landet im Wiki, alle finden ihn interessant, und im nächsten Sprint passiert nichts — weil niemand weiß, was zuerst.

13:32 Nützlich ist eine Einordnung nach Schwere und Häufigkeit, verbunden mit einem konkreten Vorschlag. Und dann der entscheidende Satz, der zugleich der Übergang zu Modul sechzehn ist: Jeder angenommene Befund muss in ein Ticket mit Akzeptanzkriterium münden. Ohne Akzeptanzkriterium ist es eine Beschreibung eines Problems, nicht eine Beschreibung eines Zielzustands — und dann weiß bei der Umsetzung niemand, wann es erledigt ist.

13:56 Diese Tabelle ist bewusst so gebaut, dass die Konsequenz gleich mitsteht — das ist der Teil, um den sonst diskutiert wird. Blockierend heißt: vor dem nächsten Release, keine Verhandlung. Schwer heißt: eingeplant, mit Termin — also nicht sofort, aber verbindlich. Leicht heißt: gesammelt, beim nächsten Anfassen dieser Stelle. Und Hinweis heißt: notiert, nicht eingeplant.

14:20 Diese vierte Kategorie ist wichtiger, als sie aussieht, denn sie erlaubt Ihnen, Einzelmeinungen ehrlich aufzunehmen, ohne sie zu Arbeit zu machen. Ohne diese Kategorie werden solche Befunde entweder unterschlagen oder überbewertet. Der erste Stolperstein ist gut gemeint und lähmend: alle Befunde gleich gewichten. Ein Bericht mit dreiundvierzig gleichrangigen Punkten wird nicht abgearbeitet, er wird verschoben.

14:46 Der zweite ist eine unvollständige Priorisierung: nach Schwere ordnen, ohne die Häufigkeit zu berücksichtigen. Ein leichtes Problem, das jede Person hatte, ist wichtiger als ein schweres, das einmal auftrat. Und der dritte ist der eben besprochene: Befunde ohne Akzeptanzkriterium ins Backlog legen. Sie werden dann in drei Monaten von jemandem gelesen, der nicht dabei war, und nach bestem Wissen falsch umgesetzt.

Übung — einen Usability-Test planen und auswerten

15:11 In der Übung planen und fahren Sie einen Test — mit einem Vergleich am Ende, der den wichtigsten Punkt dieses Moduls schlagartig sichtbar macht. Sie planen einen Test für den Umbuchungsvorgang und fahren ihn. Geübt wird, einen aufgabenbasierten Test so aufzusetzen, dass die Befunde ohne nachträgliche Interpretation auswertbar sind — das ist der Kern.

15:31 Erfolgreich sind Sie mit drei Aufgaben ohne Oberflächenwörter, vier vorab definierten Kennzahlen und drei priorisierten Anforderungen mit Akzeptanzkriterium. Und der Zusatz für die Schnellen ist der eigentliche Aha-Moment: Formulieren Sie eine Aufgabe absichtlich mit den Wörtern der Oberfläche und vergleichen Sie. Dieselbe Gruppe, dieselbe Oberfläche, deutlich andere Quote. Danach glaubt niemand mehr an Zufall bei der Aufgabenformulierung.

15:56 Fünf Schritte in strenger Reihenfolge. Erst die drei Aufgaben ohne Oberflächenwörter — lassen Sie sie gegenlesen. Dann die vier Kennzahlen definieren, bevor jemand testet; das ist keine Formalie, sondern der Unterschied zwischen Messung und Interpretation. Dann gegenseitig fahren, ohne Hilfestellung und ohne Erklärung. Dann Handlungen protokollieren, nicht Aussagen.

16:18 Und zum Schluss nach Schwere und Häufigkeit ordnen und drei Anforderungen ableiten. Die Fußzeile enthält die Regel, die im Moment am schwersten fällt: Wer während des Tests erklärt, hat den Befund gelöscht, den er gerade beobachtet. Halten Sie es aus. Der erste Stolperstein ist der Reihenfolgefehler mit der größten Wirkung: die Kennzahlen erst nach dem Test festlegen.

16:41 Sie wissen dann schon, wie die Fälle ausgegangen sind, und definieren unbewusst passend. Der zweite ist der Protokollfehler: Aussagen der Testperson als Befund protokollieren. „Sie fand die Seite unübersichtlich" ist keine Beobachtung, das ist eine Meinung — beobachtet haben Sie vielleicht, dass sie zweimal gescrollt und dann zurückgeklickt hat.

17:01 Und der dritte ist der Abschlussfehler: Anforderungen ohne Akzeptanzkriterium formulieren. Dann endet Ihre gute Untersuchung als Dokument statt als Änderung. Vier Punkte. Formativ findet Probleme, summativ misst Zustände — das sind verschiedene Aufbauten, und man kann den einen nicht als den anderen verkaufen. Eine Aufgabe ohne Oberflächenwörter misst den Weg, nicht die Lesefähigkeit. Kennzahlen werden vorher definiert, sonst bestätigen sie zuverlässig die Erwartung.

17:29 Und ein Befund ohne Akzeptanzkriterium bleibt ein Dokument. Der Satz in der Fußzeile gilt auch für das nächste Modul: Expertenverfahren finden die Probleme von Fachleuten. Nutzerbefunde bekommt man nur von Nutzenden. Als Nächstes übertragen wir dieses Prüfdenken auf die Barrierefreiheit.