Methoden der Nutzerforschung: Usability-Projekte starten

"Verdammt, ich wünschte, das hätten wir ein Jahr früher gemacht!" Das höre ich, direkt nachdem ich mit einem Team sein erstes Nutzerforschungsprojekt gestartet habe. Der Lernprozess im Hinblick darauf, was unsere Nutzer brauchen, ist so mächtig, dass selbst die erfahrensten Führungskräfte sich wünschen, in die Vergangenheit reisen zu können, um ihre Produkte und Dienstleistungen noch einmal zu überarbeiten, diesmal mit dem Wissen, das sie gerade gewonnen haben.

Natürlich können Sie (bis jetzt) nicht in die Vergangenheit reisen, aber Sie können Ihr eigenes Nutzerforschungsprogramm auf der Stelle beginnen. Wenn Sie sich einmal entschließen, diesen Weg zu gehen, werden Sie als erstes bemerken, wie reich die Usability-Welt ist, was ihre Methoden betrifft. Usability-Audits, die Heuristische Evaluation, User-Tests, Feldstudien – Womit anfangen? Was ist am effektivsten?

Usability-Audits

Die Usability-Audit, auch als Usability-Walkthrough bekannt, ist eine einfache aufgabenbasierte Technik, die jedoch am wenigsten effektiv ist. Wenn Sie ein Audit durchführen, setzt sich jemand aus Ihrem Team hin und spielt einen Nutzer, der sich in der Anwendung durch verschiedene Aufgaben arbeitet und dabei nach Stellen Ausschau hält, die die User frustrieren oder aufhalten könnten.

Nehmen wir an, Sie entwickeln ein System für Leute aus dem medizinischen Umfeld, die Informationen über Krebsbehandlungsmethoden und -möglichkeiten finden und mit Patienten und Pflegenden teilen möchten. Das Teammitglied könnte die Rolle einer Krankenschwester oder eines Gesundheitsberaters spielen, nach den richtigen Informationen suchen und so tun, als würde es diese an die Pflegeperson des Patienten weitergeben. Im Rahmen dieses Prozesses würde das Teammitglied die Stellen aufdecken, an denen Informationen schwer zu finden sind und an denen es schwierig ist, Informationen zu teilen.

Obwohl dies eine gute Methode zur Ausarbeitung einer Liste mit Dingen ist, die an der Oberfläche geändert werden sollten, besteht das Problem darin, dass Sie wissen müssen, ob diese Änderungen das Nutzererlebnis eines echten Users tatsächlich verbessern würden. Das Teammitglied spielt ein Rollenspiel und macht das, wovon er glaubt, dass ein wirklicher Nutzer es tun würde.

Wenn das Teammitglied kein erfahrener Mediziner ist, der diese Art Arbeit regelmäßig erledigt, wie soll er dann wissen, was jemanden frustriert, der so ein Profi ist? Die Vermittlung von Informationen an Patienten ist eine sensible Sache, bei der es auf viele Feinheiten und Nuancen ankommt. Ohne die erforderlichen Fähigkeiten und die entsprechende Praxis ist es unwahrscheinlich, die wirklich kritischen Probleme aufzudecken.

Eine Usability-Audit ist wahrscheinlich die preisgünstigste Methode der Nutzerforschung. Aber es fehlt eine kritische Komponente: der User. Der Erfolg hängt davon ab, dass die Teammitglieder die Welt der Nutzer wirklich in- und auswendig kennen. Entwickelt das Team ein Tool, dass es selbst nutzen würde (beispielsweise eine Projektmanagement-Software), wird aus einer Usability-Audit viel eher eine hochqualitative Liste mit Änderungsvorschlägen hervorgehen.

Wenn Sie eine Liste mit Änderungsempfehlungen haben, die nicht darauf basieren, was Nutzer wirklich tun, riskieren Sie Investitionen in Verbesserungen, durch die sich am Ende überhaupt nichts verbessert. Tatsächlich laufen Sie Gefahr, die Software schlechter als vorher zu machen. (Haben Sie jemals ein Update erhalten, das eines Ihrer geliebten Programme schlechter gemacht hat?)

Deshalb haben wir andere Forschungsmethoden.

Heuristische Evaluation

Eine Heuristik ist eine Daumenregel, die normalerweise auf einigen Untersuchungen anderer Leute basiert. Eine Heuristische Evaluation nimmt ein Set von Heuristiken und schaut, inwieweit die Oberfläche ihnen entspricht.

Beispielsweise haben Sie die Heuristik "Das System soll Feedback über sein aktuellen Status geben". Sie können in der Anwendung nach allen Stellen schauen, in denen unklar ist, welchen Status das System hat, und eine Änderung vorschlagen, um das Problem zu beheben.

Heuristische Evaluationen sind besser als Usability-Audits, weil – hoffentlich – Nutzer in die Entwicklung der heuristischen Regeln involviert gewesen sind. Dennoch gibt es wie bei Usability-Audits eine Menge Annahmen im Hinblick darauf, wo man nach Problemen suchen und sie identifizieren soll.

Manche Leute haben den Vorteil, dass sie ihre Heuristiken über viele ähnliche Projekte hinweg feintunen konnten. So hat etwa eine Agentur, die auf Websites im Bereich Bildungswesen spezialisiert ist, eine Sammlung von Heuristiken zusammengestellt, die sich auf die meisten Universitäts-Websites anwenden lassen. Sie können diese Regeln schnell anwenden, um Probleme und Schwachstellen zu finden.

Allerdings versuchen viele Leute, generische Heuristiken zu nutzen, am beliebtesten sind die Zehn Heuristiken für Computersysteme von Molich und Nielsen, die im Original in den 80ern erfasst wurden. Während es möglich ist, eine Liste von Dingen zu erstellen, die geändert werden müssen (es ist immer einfach, Dinge herunterzuleiern, mit denen etwas nicht stimmt), wissen Sie wie in den Usability-Audits nicht, ob die Änderungen die Anwendung voranbringen.

Tatsächlich haben Studien gezeigt, dass bei Leuten, die keinen echten Nutzern zugeschaut haben, die Chancen sehr hoch sind, dass die Oberflächen durch Heuristische Evaluationen schlechter werden. Deshalb mögen wir Untersuchungsmethoden, die echte User direkt einbeziehen.

Schnitzeljagd-User-Tests

Der User-Test ist komplizierter als die Methoden, die ich bislang aufgelistet habe, aber es ist immer noch ziemlich einfach. In der simpelsten Variante setzen Sie sich neben einen User und sehen ihm dabei zu, wie er die Anwendung nutzt. Wie bei so vielen Dingen im Leben gibt es auch hier mehrere Ansätze.

Eine Möglichkeit ist der Schnitzeljagd-User-Test, denn wir bitten die Teilnehmer, spezifische, im Vorfeld definierte Aufgaben zu erfüllen, so wie Sie es eben bei einer Schnitzeljagd machen würden. Wir könnten sie bitten, chirurgische Behandlungsmethoden gegen Bauchspeicheldrüsenkrebs zu finden oder die Vorteile und Risiken einer Whipple-Operation mit der Pflegeperson eines Patienten zu teilen. Wenn sie diese Aufgaben erledigen, können wir sagen, wo die Oberfläche ihnen hilft und wo sie ihnen im Wege steht.

Wir können jede Stelle verzeichnen, an denen die Oberfläche den Nutzer ausbremst oder frustriert. Wir können auch die Stellen verzeichnen, an denen der Nutzer eine falsche Entscheidung trifft oder einen Fehler macht. Dank dieser Informationen sind wir in der Lage, eine Liste mit Dingen zu generieren, die wir ändern müssen. Mit genügend Usern und genügend Aufgaben lassen sich weite Teile der Anwendung abdecken.

Das ist besser als eine Usability-Audit oder eine Heuristische Evaluation, weil wir echten Nutzern bei der Interaktion begegnen. Da die User nicht tief in die Entwicklung der Anwendung involviert waren, sehen wir nun grundsätzlich durch die Augen der Nutzer, was wir da gebaut haben. Vielleicht verheddern sie sich ja mit einem Begriff oder einem Befehl, weil er nicht ihren eigenen Erfahrungen entspricht.

Nichtsdestotrotz setzen Schnitzeljagd-Tests immer noch voraus, dass wir wissen, welche Aufgaben wir die User umsetzen lassen wollen. Wir entwickeln diese Tests aus unserer eigenen Perspektive heraus und müssen auch hier von Annahmen dahingehend ausgehen, was die Nutzer tun und wollen. Der Schnitzeljagd-Test leidet also unter denselben Mängeln wie die Usability-Audit und die Heuristische Evaluation, sofern wir nicht intim mit unseren Usern und ihrer Arbeit vertraut sind. Um das zu kompensieren, haben wir eine andere Variante des User-Tests entwickelt: den interviewbasierten Test.

Interviewbasierte User-Tests

Wie beim Schnitzeljagd-Test bitten wir User, eine Reihe von Aufgaben zu erledigen. Doch hier fangen wir nicht mit vorweg festgelegten Aufgaben an, die abzuarbeiten sind.

Stattdessen machen wir im interviewbasierten Test, was der Name schon impliziert: Wir interviewen unseren Teilnehmer. Beispielsweise könnten wir uns mit einem Krebsexperten zusammensetzen und ihn bitten zu beschreiben, wie er beim letzten Mal einer Familie Behandlungsmethoden vorgeschlagen hat. Während er erzählt, machen wir uns ausführliche Notizen über seine Aktivitäten, über die Details der damaligen Situation und über das spezifische Vokabular, das er nutzt.

Nachdem wir das alles zusammengeführt haben, bitten wir den User, etwas sehr ähnliches mit der Anwendung zu tun. Wir nutzen sein Vokabular statt unseres eigenen Jargons für unsere Anweisungen. Und wir ziehen die Situation, die er beschrieben hat, als Hintergrund heran.

Wenn wir interviewbasierte Tests durchführen, finden wir oft große Löcher in unseren Oberflächen, die wir vorher nicht gesehen haben. Weil die Szenarien, die die Nutzer beschreiben, realistischer sind, sehen wir, dass unsere Anwendung in diesem echten Umfeld nicht funktioniert. Nun kommen wir der Sache näher und können die Probleme finden und die Lösungen identifizieren, die unsere Anwendung wirklich voranbringen.

Feldstudien

Obwohl interviewbasierte User-Tests uns dem näher bringen, was Nutzer wirklich tun und denken, leidet diese Methode immer noch darunter, dass sie außerhalb des tatsächlichen Kontexts des Nutzererlebnisses stattfindet. Aus diesem Grund sind Feldstudien die effektivsten Möglichkeiten, um mit Nutzerforschung zu beginnen.

Eine Feldstudie führt uns in die eigene Umgebung des Users. Wir sehen, was die Nutzer tun, wie sie es tun und wo sie es tun. Wir sehen die Sachen, die an der Wand hängen, wir bekommen mit, wie sie mit ihren Kollegen oder Familienmitgliedern sprechen, und wir tauchen ein in das alltägliche Chaos, das in unser aller Leben herrscht.

Zum Beispiel können wir sehen, was passiert, wenn die Leute durch Dinge unterbrochen werden, die im echten Leben ständig passieren, etwa wenn ein Kollege eine Frage hat und dringend eine Antwort braucht. Wir können sehen, dass die Anwendung, die wir entwickelt haben, auf eine solche Unterbrechung nicht ausgelegt ist, und es damit endet, dass der User eine zeitraubende Aktion noch einmal durchführen muss.

So entscheiden wir uns am Beginn von Usability-Projekten

Unsere erste Wahl ist immer die Feldstudie, sie ist die reichhaltigste, mächtigste Methode. Wenn Sie ein Team (und speziell die Entscheider) mit hinaus in die tatsächlichen Umgebungen der echten Nutzer nehmen, erkennen Sie die meisten Änderungen, die die Anwendung nötig hat. Also fangen wir am liebsten so an.

Das Lustige daran: Sie scheinen teurer zu sein, aber Feldstudien kosten nicht mehr als gut durchgeführte User-Tests. Und wenn wir trotzdem keine Feldstudie in Angriff nehmen können, votieren wir für interviewbasierte Aufgaben.

Im Rahmen der initialen Studien lassen wir die Finger von Schnitzeljagd-Tests, bis wir wirklich sicher im Hinblick auf die Hauptaufgaben sind. Schnitzeljagden führen wir später im Projekt durch, wenn wir die feinen Details eines neuen Features testen, das von unseren früheren Untersuchungen inspiriert wurde.

Wir nutzen fast nie Heuristische Evaluationen und führen niemals Usability-Audits durch. Wir können uns die Risiken einfach nicht leisten, die mit ihnen einhergehen. Sie sind verlockend, weil sie so einfach aussehen, aber das macht sie so böse. Man merkt nicht, dass sie das Projekt auf den Holzweg geführt haben, ehe es zu spät ist.

Es gibt keinen Grund, mit Nutzerforschung zu warten. Wie fangen Sie an?

Dieser Artikel wurde im Original am 18. April 2012 unter dem Titel Starting Your User Research von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.