• Facebook
  • Google+
  • Twitter
  • XING
25.07.2010

Interviews mit Nutzern

Trotz diverser Schwächen sind Interviews eine wertvolle Methode für die frühe Nutzerforschung. (exploratory user research)

 

by Jakob Nielsen (deutsche Übersetzung) - 26.07.2010

 

Was die Nutzer sagen und was sie tun, sind verschiedene Dinge - diese Feststellung habe ich schon zahllose Male gemacht. Ich habe sogar einmal eine Kolumne mit dem Titel geschrieben: "Die erste Regel der Usability: Hören Sie nicht auf die Nnutzer" - und die ist heute immer noch genauso relevant wie vor neun Jahren. (Die besten Usability-Methoden sind sehr langlebig, was der Grund dafür ist, dass das Erlernen valider Methodiken so eine hohe und lebenslange Rendite abwirft.)

Aufmerksame Leser haben bemerkt, dass ich kürzlich in meiner Analyse der Verzögerungen durch Reaktionszeiten gegen mein eigenes Rezept verstossen habe. In jenem Artikel habe ich über eine Serie von Interviews berichtet, die wir in Vorbereitung unseres Seminars "Marke als Erlebnis" mit Nutzern durchgeführt haben. Was hat es also damit auf sich, dass ich plötzlich Leute danach frage, was sie denken, anstatt ihr wirkliches Verhalten zu beobachten?

Die Antwort lautet: Interviews sind in der Tat eine passende Methode der Nutzerforschung - wenn man sie nur in den wenigen Fällen anwendet, in denen sie valide Daten erzeugen.

Wozu Interviews nichts taugen

Bevor wir zur guten Seite der Interviews kommen, wollen wir ihre zahlreichen Nachteile rekapitulieren. (Viele davon haben sie mit Fokusgruppen gemeinsam, die bei Webdesign-Projekten grob überschätzt werden.)

Der entscheidende Fehler von Nutzer-Interviews liegt darin, dass Sie die Leute entweder bitten, sich an eine vergangene Nutzung zurückzuerinnern, oder darum, über die zukünftige Nutzung eines Systems zu spekulieren. Beide Typen von Antworten sind ausserordentlich schwach und häufig irreführend.

  • Das menschliche Gedächtnis ist fehlbar. Die Leute können sich nicht an die Details erinnern, wie sie eine Website benutzt haben, und neigen oft dazu, eine Geschichte zu erfinden, um das zu rationalisieren, woran sie sich noch erinnern (oder fälschlich erinnern), damit der Ablauf logischer erscheint, als er in Wirklichkeit war.
  • Die Nutzer sind pragmatisch und konkret. Sie haben normalerweise keine Ahnung, auf welche Weise sie eine neue Technik gebrauchen könnten, wenn sie ihnen lediglich beschrieben wird. Nutzer sind keine Designer, und die Fähigkeit, sich etwas vorzustellen, das nicht existiert, ist selten. (Umgekehrt gilt: Designer sind keine Nutzer, deshalb hat es keine Bedeutung, wenn sie persönlich der Meinung sind, dass etwas einfach zu handhaben sei.)

Wenn wir uns den Zeitstrahl der Nutzerkommentare vorstellen, gilt: Nur ein einziger Punkt darauf produziert valide Daten - die Gegenwart: das, was die Nutzer jetzt im Moment gerade wirklich tun. Hüten Sie sich vor falschen Erinnerungen an die Vergangenheit und vor falschen Voraussagen für die Zukunft.

Dass Spezifikationen (Pflichtenhefte) nicht funktionieren, liegt unter anderem daran, dass die Nutzer (und das Management) nicht sagen können, ob eine Anforderung etwas dokumentiert, das eines ihrer Probleme lösen wird, sobald es gebaut ist. In geschriebener Form hört sich alles gut an, aber tausende von Fallstudien mit Nutzer-Rückmeldungen sind zu Schlussfolgerungen gekommen, die sich als riesige Fehler herausgestellt haben.

Deshalb sind agile Entwicklungsmethoden und Papierprototypen so wertvoll. Wenn die Nutzer etwas Konkretes in der Hand haben, mit dem sie interagieren können, zeigt sich normalerweise ganz schnell, ob Sie eine Problemlösung gefunden haben, die leicht fällt und mit der zu arbeiten angenehm ist - oder ob das eben nicht der Fall ist.

Die meisten spezifischen Designfragen können mit Nutzerinterviews nicht beantwortet werden. Hier ein paar Dinge, die Sie per Interview niemals herausbekommen:

  • Sollte der Kaufen-Button rot oder orange sein?
  • Ist es für diese konkrete Auswahl besser, ein Drop-down-Menü zu verwenden oder einen Satz Radio-Buttons?
  • Wo sollte die Produktlinie Soundso in der Informationsarchitektur angeordnet werden?
  • Ist es besser, mit drei Navigationsebenen zu arbeiten, oder besser, mit zwei Ebenen, bei denen die Menüs entsprechend länger ausfallen?
  • Wie sollten die Hilfe-Informationen formuliert sein, damit sie den Leuten am besten erklären, wie man das System korrekt nutzt?

Sicher, Sie können den Nutzern alle diese Fragen stellen, aber die Antworten werden nichts zur effektiven Gestaltung einer realen Website beitragen. Streitfragen, die mit spezifischen Elementen einer Nutzeroberfläche zu tun haben, können nur durch das Beobachten von Nutzern geklärt werden, die mit einem Design interagieren, das eine spezifische Lösung enthält, so dass man erkennen kann, wie gut sich die im realen Gebrauch macht. (Sie können auch mehrere Optionen implementieren und einen vergleichenden Test laufen lassen.)

Sie können natürlich auch nicht fragen: "Würden Sie (Futur Konjunktiv) die Funktion X nutzen?", weil die Nutzer nicht voraussagen können, was sie noch nicht gesehen haben. Sie können noch nicht einmal bei Funktionen, die bereits existieren, fragen: "Wie nützlich ist die Funktion Y?" In der Tat haben die Befrager bei vielen Studien die Nutzer gebeten, spezifische Funktionen zu kommentieren, die gar nicht existierten - man hat das als Kontrollfragen eingebaut; und die Nutzer lieferten reichlich Rückmeldungen.

(Was bringt Ihnen das? Wenn man Sie zwingt, Nutzer danach zu fragen, wie sehr sie bestimmte Funktionen mögen, dann bauen Sie unbedingt ein paar nicht-existente Funktionen in die Befragung ein, um eine Referenzgrundlage zu erzeugen.)

In einer berühmt gewordenen Studie hat Microsoft seine Kunden gebeten, neue Funktionen für Office 2007 vorzuschlagen, bevor man sich an die Arbeit für dieses Produkt gemacht hat. Die meisten "neuen" Funktionen, die die Nutzer verlangt hatten, existierten in Wirklichkeit bereits in Office 2003, so dass das Design-Team die richtige Schlussfolgerung zog, dass ihr grösstes Problem die Entdeckbarkeit der existierenden Funktionalitäten war.

Der Königsweg, um Funktionen einzuschätzen, besteht darin, dass man die Leute dazu bringt, sie zu nutzen. Achten Sie definitiv auf Nutzerkommentare, während sich die Nutzer mit den Funktionen auseinandersetzen. Zusätzlich können Sie kurz nach Beendigung der Aufgaben um Kommentare bitten, wenn die Funktionen sich noch im Kurzzeitgedächtnis der Nutzer befinden.

Was Sie mit Interviews erfahren können

Für unser Seminar über Marken wollten wir erfahren, in welcher Weise die Verwendung einer Website mit der Zeit Eindrücke von der Website erzeugt und die Erwartungen der Nutzer an das Markenversprechen beeinflusst. Mit anderen Worten, wir waren nicht an einzelnen Seitendesigns interessiert - diese hatten wir mit Nutzertests erforscht -, sondern wir wollten wissen, was die Nutzer von einer Website hielten, nachdem sie sie benutzt hatten. Und das schätzt man am besten dadurch ein, dass man sie fragt.

Interviews sind auch dann nützlich, wenn Sie die generellen Haltungen von Nutzern erforschen wollen, also die Art und Weise, wie sie über ein bestimmtes Problem denken. Wenn Sie solche Informationen haben, liegt es in Ihrer Verantwortung, Funktionen zu gestalten, die das Problem ansprechen (und Design-Prototypen jener Funktionen zu testen, um sicher zu gehen, dass Sie sie richtig verstanden haben).

Bei solchen explorierenden Interviews ist die Methode "kritischer Zwischenfall" besonders nützlich: Bitten Sie die Nutzer, sich an bestimmte Zwischenfälle zurückzuerinnern, bei denen sie einen besonders schwierigen Fall vor der Nase hatten oder bei denen etwas besonders gut funktioniert hat. Solche Extremfälle werden oft besonders lebhaft erinnert, so dass Sie Details erfahren, die Sie für nützliche Funktionen brauchen.

(Wenn Sie die Leute dagegen fragen, wie sie gewöhnlich eine Aufgabe erledigen, beschreiben sie häufig einen idealisieren Arbeitsablauf ohne die vielen Abkürzungen und Umwege, die charakteristisch sind für reale Projekte, egal ob zuhause oder im Büro. Eine der Schlüssel-Determinanten für gute Anwendungs-Workflows besteht darin, idealisierte Situationen zu vermeiden und für den Weg zu gestalten, auf dem die Leute wirkliche Sachen erledigen.)

Vorsicht vor dem Befragungs-Effekt!

Immer wenn Sie Nutzer nach ihren Meinungen fragen, müssen Sie den Befragungs-Effekt beachten: Die Leute können sich über alles und jedes eine Meinung bilden und tun das auch, sobald sie gefragt werden. So erreichen Sie oft, dass sich die Nutzer des Langen und Breiten über eine Kleinigkeit auslassen, an die sie aus eigenem Antrieb keine zwei Gedanken verschwendet hätten.

Es ist gefährlich, grosse Änderungen am Design vorzunehmen, weil "die Nutzer das nicht mögen" oder weil "die Nutzer danach gefragt haben". Wenn Sie Leitfragen stellen oder Druck ausüben, um Antworten zu bekommen, können die Nutzer Meinungen äussern, die ihre wirklichen Präferenzen in keiner Weise wiedergeben.

Wenn Sie die Leute zum Beispiel nach Ihrem visuellen Design befragen, bekommen Sie unausweichlich Kommentare über die Farben zu hören, auch wenn die den Nutzern gar nicht besonders wichtig sind. Andererseits, wenn Sie hören, wie die Leute (ungebeten) die Farben erwähnen, während sie die Website nutzen, dann liegt dort wahrscheinlich wirklich ein Problem begraben. (Sagen wir, ein Kommentar wie "Uh, dieses Neonblau tut aber den Augen weh", oder eine eher positive Feststellung wie "Dieses Ultramarinblau ist schön und beruhigend").

Methoden kombinieren im Datendreieck

Interviews sind eine grossartige Ergänzung zu anderen Usability-Methoden. Wenn Sie nur eine Sache tun können, empfehle ich Ihnen immer Nutzertests. Aber warum sollten Sie sich auf eine Methode beschränken? Jede Methode erfordert vielleicht nur ein paar Tage Arbeit, also können Sie mehrere Methoden kombinieren, jeweils mit dem kleinstmöglichen Budget.

Jede Methode hat ihre Stärken und Schwächen. Wenn Sie den jeweils besten Input aus jeder Methode ziehen, erzielen Sie ein viel reicheres Verständnis, als Sie es aus jeweils einer Methode allein gewinnen können. Dazu kommt, wenn Sie jede Methode mit einigen anderen Ansätzen ergänzen, können Sie Ihre Ergebnisse auf mehrere Füsse stellen und sich vor irreführenden Einzelergebnissen schützen.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.

Kommentare auf diesen Beitrag

    Keine Kommentare

Kommentar hinzufügen

Die mit * gekenzeichneten Felder sind zwingend auszufüllen