Hintergrund

The only way to experience an experience is to experience it!” (Die einzige Art & Weise eine Erfahrung wirklich zu machen ist es, diese zu erleben!”)
– Bill Moggridge (Designer des ersten Laptops)

Jeder auf den Menschen ausgerichtete Designprozess hängt in hohem Maße von der Interaktion mit den zukünftigen Nutzenden (oder Zielgruppen) des anvisierten Produktes ab. Ein Produkt in diesem Sinne kann alles sein: ein Produkt im eigentlichen Sinne, ein neues Dashboard, ein zukünftiger Organisationsprozess oder sogar eine Strategie. All diese „Produkte“ können als Erfahrungen betrachtet werden, und jede dieser Erfahrungen kann prototypisch entwickelt und getestet werden. (siehe “Prototyping”).

In der agilen Welt verlassen wir uns weniger auf den so genannten „Wasserfall-Ansatz“, bei dem man zunächst alle Anforderungen in einem Dokument genau beschreibt und dann auf der Grundlage dieses Dokuments ausführt. Stattdessen entwickeln wir künftige Lösungen, indem wir uns iterativ an die beste Version des Produkts herantasten. Normalerweise beginnt das Design- und Entwicklungsteam mit Prototypen in niedriger Auflösung (z. B. Papierprototypen oder groben Skizzen), geht dann zu hochauflösenderen Prototypen über (z. B. Click-Dummies oder Mock-ups) und beginnt schließlich mit der Implementierung des Produkts (oft in Form eines Minimum Viable Product – MVP). Alle diese Schritte sollten von Tests begleitet werden. Eine der effektivsten Methoden zum Testen von (Software-)Produkten ist das so genannte Think Aloud Testing.

Schritt-für-Schritt-Anleitung

Um einen Think Aloud-Test durchzuführen, brauchst du eine Experience (in Form eines Prototyps oder eines bestehenden Produkts), die du testen möchtest. Du kannst zum Beispiel einen solchen Test auf der Basis eines bestehenden PowerBI-Dashboards durchführen, um zu erfahren, welche Herausforderungen die Benutzer bei der Interaktion mit dem Dashboard haben könnten. Oder du könntest ein neues Artefakt erstellen, das dein Konzept eines zukünftigen Dashboards so greifbar wie möglich macht und es der testenden Person ermöglicht, das zukünftige Dashboard live zu erleben (z. B. auf Papier, PowerPoint oder einem Online-Kollaborationsboard).

1. Bereite den Prototyp so vor, dass du nur ein Minimum an Erklärungen abgeben musst. Der Prototyp sollte so nah wie möglich an der Realität sein. Solange du nicht in der echten Entwicklungsumgebung (z.B. PowerBI) arbeitest, lautet das Mantra für diesen Schritt: „Fake it until you make it!“
2. Wähle die Benutzer/innen aus, mit denen du den Test durchführen möchtest. (Weitere Informationen über die Auswahl der Benutzer/innen: siehe unten)
3. Beschreibe ein Szenario, das der Benutzer mit Hilfe deines Prototyps bewältigen muss. Zum Beispiel: „ Dein Vorgesetzter hat Dich angerufen, weil die Zahlen in Deinem Verantwortungsbereich ungewöhnlich erscheinen. Bitte suche die entsprechenden Zahlen im Dashboard und bereite eine Antwort für deinen Vorgesetzten vor. Wie würdest du vorgehen?“ Stelle sicher, dass das Szenario für den Benutzer, mit dem du es testen willst, relevant und realistisch ist. Beginne das Szenario an einem relevanten Punkt (z. B. willst du testen, ob der Benutzer dein Produkt auf den internen Servern findet? Willst du testen, wie er sich bei deinem System anmeldet, oder willst du nur dein Dashboard testen?)
4. Lade den Probanden dazu ein, das von dir vorbereitete Szenario zu erfüllen. Versichere ihm oder ihr, dass du hier bist, um von ihm oder ihr zu lernen, nicht um seine oder ihre Fähigkeiten im Umgang mit einem bestimmten Werkzeug zu bewerten. Schließlich ist schlechtes Design ein Fehler von Designern und nicht von Benutzern!
5. Bitte die Testpersonen, laut auszusprechen, was sie denken. Sie sollten jeden Schritt, den sie tun, mündlich erklären: „Ich suche nach KPI XYZ, also gehe ich auf diese Registerkarte und klicke darauf… Oh, das sieht sehr seltsam aus … Das Datum ist falsch… Mal sehen, wo kann ich das Datum ändern?” Während die Anwender versuchen, die Aufgabe zu erfüllen, mache dir Notizen zu allen wichtigen Dingen.
6. Idealerweise gibt es eine Person, die Notizen macht, und eine Person, die die Testsession leitet (Interviewer). So kann sich der Interviewer wirklich auf die Person konzentrieren. Hier gilt die 80/20-Regel: Der Benutzer sollte 80 Prozent der Zeit sprechen! Denk daran: Du testest eine Lösung und verkaufst sie nicht! Wenn du dir Notizen machst, achte darauf, dass du vollständige Zitate und nicht nur einzelne Wörter festhältst. So kannst du dich später viel leichter daran erinnern, was die Benutzer gesagt haben. Zusätzlich kannst du eine Methode zum Sammeln von Feedback verwenden, um das Nutzerfeedback zu strukturieren (siehe unsere Methode zum Sammeln von Feedback).
7. Sobald der Benutzer seine Aufgabe beendet hat, kannst du weitere Fragen stellen. Achte darauf, dass du nicht zu hypothetisch fragst. Fragen wie „ Würdest du das benutzen?“ werden dir nicht viel Aufschluss geben, weil dein Gegenüber vielleicht höflich ja sagt. Stelle stattdessen offene Fragen wie „Was hältst du von diesem Prototyp?“ oder „Wo siehst du generell Verbesserungsmöglichkeiten?“.
8. Danke dem Teilnehmer oder der Teilnehmerin und frage sie, ob und inwieweit du sie in den weiteren Prozess einbeziehen kannst.
9. Sammel das Feedback der verschiedenen Benutzertests, die du durchgeführt hast. Idealerweise arbeitest du mit deinem Designteam zusammen, um das Nutzerfeedback sinnvoll zu nutzen (siehe Methode Working with a whiteboard, insbesondere den Abschnitt über divergentes und konvergentes Denken).
10. Pass deinen Prototyp entsprechend dem gesammelten Feedback an. Sei dir bewusst, dass einzelne Nutzende Meinungen haben können, die nicht in den größeren Rahmen deines Produkts passen. Nur weil du mit ihnen getestet hast, heißt das nicht, dass du das gesamte Feedback umsetzt. Feedback ist ein Geschenk, aber das sollte dich nicht daran hindern, es kritisch zu betrachten. Oft hilft es, einige Dinge, die ein Benutzer sagt, in Frage zu stellen (z. B. Wenn der Benutzer einen roten Button will, solltest du versuchen zu verstehen, warum? Vielleicht möchte er/sie nur, dass die entsprechende Taste besser sichtbar ist, und eine Verschiebung in einen anderen Bereich des Bildschirms ist tatsächlich die bessere Lösung).
11. Manchmal kann ein Feedback auch ignoriert werden, wenn es dafür gute Gründe gibt (z. B. wenn der Benutzer zusätzliche Informationen sehen möchte, diese aber nicht ohne weiteres im System verfügbar sind).
12. Achte darauf, dass du deine Entscheidungen für spätere Überlegungen oder künftige Versionen deines Produkts dokumentierst.

Das “Extreme User Framework”

Es gibt ein hervorragendes Framework für die Auswahl von Testern, das es gleichzeitig ermöglicht, nicht zu viele Tests durchzuführen. Es ist das sogenannte “Extreme User Framework”.

Teile deine Benutzer entlang der X-Achse nach ihrem Wissensstand in Bezug auf das Thema (z. B. Steuererklärung, wenn du versuchst, an einem steuerbezogenen Problem zu arbeiten) oder nach dem Kenntnisstand über ein bestimmtes Tool (z. B. PowerBI, wenn du für PowerBI entwirfst). Schaue die nun die Anzahl der möglichen Benutzer/innen auf der Y-Achse an.
Normalerweise findet man in jeder Gruppe von Personen eine Art von Normalverteilung. Einige wenige sind vielleicht echte Experten, andere haben vielleicht überhaupt keine Erfahrung. Die meisten werden sich irgendwo in der Mitte befinden.

Beim Testen eines Prototyps lernt man am schnellsten von den beiden Extremen: Menschen, die das Thema oder das Tool überhaupt nicht kennen, und Menschen, die regelmäßig damit zu tun haben. Nach dem Testen mit 4-6 Personen werden sich deren Antworten wiederholen und du wirst in der Lage sein, Muster zu erkennen.

Das gleiche Schema kann auch für die anfängliche Recherche verwendet werden, bevor man überhaupt Ideen für Lösungen entwickelt.

Schau dir dieses Video an, um Tips von einem Profi zu erhalten

RELATED METHODS