{"id":13133,"date":"2023-05-31T18:54:38","date_gmt":"2023-05-31T16:54:38","guid":{"rendered":"https:\/\/staging1.mermaidbroccoli.de\/?post_type=method&p=13133"},"modified":"2024-08-28T15:23:03","modified_gmt":"2024-08-28T13:23:03","slug":"think-aloud-testing-laut-nachdenken-beim-testen","status":"publish","type":"method","link":"https:\/\/staging1.mermaidbroccoli.de\/de\/method\/think-aloud-testing-laut-nachdenken-beim-testen\/","title":{"rendered":"Think Aloud Testing (Laut nachdenken beim Testen)"},"content":{"rendered":"\n

Hintergrund<\/h2>\n\n\n\n

The only way to experience an experience is to experience it!\u201d <\/em>(Die einzige Art & Weise eine Erfahrung wirklich zu machen ist es, diese zu erleben!“)
\u2013 Bill Moggridge (<\/em>Designer des ersten Laptops<\/a>)<\/em><\/p>\n\n\n\n

Jeder auf den Menschen ausgerichtete Designprozess h\u00e4ngt in hohem Ma\u00dfe von der Interaktion mit den zuk\u00fcnftigen 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\u00fcnftiger Organisationsprozess oder sogar eine Strategie. All diese \u201eProdukte\u201c k\u00f6nnen als Erfahrungen betrachtet werden, und jede dieser Erfahrungen kann prototypisch entwickelt und getestet werden. (siehe \u201cPrototyping<\/a>\u201d).<\/p>\n\n\n\n

In der agilen Welt verlassen wir uns weniger auf den so genannten \u201eWasserfall-Ansatz\u201c, bei dem man zun\u00e4chst alle Anforderungen in einem Dokument genau beschreibt und dann auf der Grundlage dieses Dokuments ausf\u00fchrt. Stattdessen entwickeln wir k\u00fcnftige L\u00f6sungen, indem wir uns iterativ an die beste Version des Produkts herantasten. Normalerweise beginnt das Design- und Entwicklungsteam mit Prototypen in niedriger Aufl\u00f6sung (z. B. Papierprototypen oder groben Skizzen), geht dann zu hochaufl\u00f6senderen Prototypen \u00fcber (z. B. Click-Dummies oder Mock-ups) und beginnt schlie\u00dflich 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.<\/p>\n\n\n\n

Schritt-f\u00fcr-Schritt-Anleitung<\/h2>\n\n\n\n

Um einen Think Aloud-Test durchzuf\u00fchren, brauchst du eine Experience (in Form eines Prototyps oder eines bestehenden Produkts), die du testen m\u00f6chtest. Du kannst zum Beispiel einen solchen Test auf der Basis eines bestehenden PowerBI-Dashboards durchf\u00fchren, um zu erfahren, welche Herausforderungen die Benutzer bei der Interaktion mit dem Dashboard haben k\u00f6nnten. Oder du k\u00f6nntest ein neues Artefakt erstellen, das dein Konzept eines zuk\u00fcnftigen Dashboards so greifbar wie m\u00f6glich macht und es der testenden Person erm\u00f6glicht, das zuk\u00fcnftige Dashboard live zu erleben (z. B. auf Papier, PowerPoint oder einem Online-Kollaborationsboard).<\/p>\n\n\n\n

    \n
  1. Bereite den Prototyp so vor, dass du nur ein Minimum an Erkl\u00e4rungen abgeben musst. Der Prototyp sollte so nah wie m\u00f6glich an der Realit\u00e4t sein. Solange du nicht in der echten Entwicklungsumgebung (z.B. PowerBI) arbeitest, lautet das Mantra f\u00fcr diesen Schritt: \u201eFake it until you make it!\u201c<\/li>\n\n\n\n
  2. W\u00e4hle die Benutzer\/innen aus, mit denen du den Test durchf\u00fchren m\u00f6chtest. (Weitere Informationen \u00fcber die Auswahl der Benutzer\/innen: siehe unten)<\/li>\n\n\n\n
  3. Beschreibe ein Szenario, das der Benutzer mit Hilfe deines Prototyps bew\u00e4ltigen muss. Zum Beispiel: \u201e Dein Vorgesetzter hat Dich angerufen, weil die Zahlen in Deinem Verantwortungsbereich ungew\u00f6hnlich erscheinen. Bitte suche die entsprechenden Zahlen im Dashboard und bereite eine Antwort f\u00fcr deinen Vorgesetzten vor. Wie w\u00fcrdest du vorgehen?\u201c Stelle sicher, dass das Szenario f\u00fcr 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?)<\/li>\n\n\n\n
  4. Lade den Probanden dazu ein, das von dir vorbereitete Szenario zu erf\u00fcllen. Versichere ihm oder ihr, dass du hier bist, um von ihm oder ihr zu lernen, nicht um seine oder ihre F\u00e4higkeiten im Umgang mit einem bestimmten Werkzeug zu bewerten. Schlie\u00dflich ist schlechtes Design ein Fehler von Designern und nicht von Benutzern!<\/li>\n\n\n\n
  5. Bitte die Testpersonen, laut auszusprechen, was sie denken. Sie sollten jeden Schritt, den sie tun, m\u00fcndlich erkl\u00e4ren: \u201eIch suche nach KPI XYZ, also gehe ich auf diese Registerkarte und klicke darauf\u2026 Oh, das sieht sehr seltsam aus \u2026 Das Datum ist falsch\u2026 Mal sehen, wo kann ich das Datum \u00e4ndern?“ W\u00e4hrend die Anwender versuchen, die Aufgabe zu erf\u00fcllen, mache dir Notizen zu allen wichtigen Dingen.<\/li>\n\n\n\n
  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\u00f6sung und verkaufst sie nicht! Wenn du dir Notizen machst, achte darauf, dass du vollst\u00e4ndige Zitate und nicht nur einzelne W\u00f6rter festh\u00e4ltst. So kannst du dich sp\u00e4ter viel leichter daran erinnern, was die Benutzer gesagt haben. Zus\u00e4tzlich kannst du eine Methode zum Sammeln von Feedback verwenden, um das Nutzerfeedback zu strukturieren (siehe unsere Methode zum Sammeln von Feedback<\/a>).<\/li>\n\n\n\n
  7. Sobald der Benutzer seine Aufgabe beendet hat, kannst du weitere Fragen stellen. Achte darauf, dass du nicht zu hypothetisch fragst. Fragen wie \u201e W\u00fcrdest du das benutzen?\u201c werden dir nicht viel Aufschluss geben, weil dein Gegen\u00fcber vielleicht h\u00f6flich ja sagt. Stelle stattdessen offene Fragen wie \u201eWas h\u00e4ltst du von diesem Prototyp?\u201c oder \u201eWo siehst du generell Verbesserungsm\u00f6glichkeiten?\u201c.<\/li>\n\n\n\n
  8. Danke dem Teilnehmer oder der Teilnehmerin und frage sie, ob und inwieweit du sie in den weiteren Prozess einbeziehen kannst.<\/li>\n\n\n\n
  9. Sammel das Feedback der verschiedenen Benutzertests, die du durchgef\u00fchrt hast. Idealerweise arbeitest du mit deinem Designteam zusammen, um das Nutzerfeedback sinnvoll zu nutzen (siehe Methode Working with a whiteboard<\/a>, insbesondere den Abschnitt \u00fcber divergentes und konvergentes Denken).<\/li>\n\n\n\n
  10. Pass deinen Prototyp entsprechend dem gesammelten Feedback an. Sei dir bewusst, dass einzelne Nutzende Meinungen haben k\u00f6nnen, die nicht in den gr\u00f6\u00dferen Rahmen deines Produkts passen. Nur weil du mit ihnen getestet hast, hei\u00dft 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\u00f6chte er\/sie nur, dass die entsprechende Taste besser sichtbar ist, und eine Verschiebung in einen anderen Bereich des Bildschirms ist tats\u00e4chlich die bessere L\u00f6sung).<\/li>\n\n\n\n
  11. Manchmal kann ein Feedback auch ignoriert werden, wenn es daf\u00fcr gute Gr\u00fcnde gibt (z. B. wenn der Benutzer zus\u00e4tzliche Informationen sehen m\u00f6chte, diese aber nicht ohne weiteres im System verf\u00fcgbar sind).<\/li>\n\n\n\n
  12. Achte darauf, dass du deine Entscheidungen f\u00fcr sp\u00e4tere \u00dcberlegungen oder k\u00fcnftige Versionen deines Produkts dokumentierst.<\/li>\n<\/ol>\n\n\n\n

    Das „Extreme User Framework“<\/h2>\n\n\n\n

    Es gibt ein hervorragendes Framework f\u00fcr die Auswahl von Testern, das es gleichzeitig erm\u00f6glicht, nicht zu viele Tests durchzuf\u00fchren. Es ist das sogenannte „Extreme User Framework“.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

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

    Beim Testen eines Prototyps lernt man am schnellsten von den beiden Extremen: Menschen, die das Thema oder das Tool \u00fcberhaupt nicht kennen, und Menschen, die regelm\u00e4\u00dfig 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.<\/p>\n\n\n\n

    Das gleiche Schema kann auch f\u00fcr die anf\u00e4ngliche Recherche verwendet werden, bevor man \u00fcberhaupt Ideen f\u00fcr L\u00f6sungen entwickelt.<\/p>\n\n\n\n

    Schau dir dieses Video an, um Tips von einem Profi zu erhalten<\/h2>\n\n\n\n
    \n