Card Sorting: Wie man Schlüsselwort-Effekte vermeidet

Es passiert leicht, dass Nutzertests oder Card-Sorting-Studien dadurch verzerrt werden, dass die Teilnehmer sich auf zutreffende Schlüsselworte konzentrieren, statt das zugrunde liegenden Problem abzuarbeiten.

 

by Jakob Nielsen (deutsche Übersetzung) - 31.08.2009

 

Ein klassischer Weg, um Ergebnisse von Usability-Tests zu verfälschen, besteht darin, dass man in die Problemstellung für die Nutzer Befehlsnamen oder Navigationsbezeichnungen einbaut, die sie wahrscheinlich nutzen werden.

Wenn Sie zum Beispiel testen wollen, ob die Leute die Excel-Funktion "Duplikate beseitigen" finden und verwenden können, dürfen Sie ihnen nicht sagen: "Sie haben eine Liste von Firmen, die früher bereits Ihr Produkt gekauft haben, aber manche Firmen tauchen dort mehrmals auf. Beseitigen Sie diese Duplikate."

Mit einer solchen Benennung der Aufgabe im Kopf werden viele Nutzer die Nutzeroberfläche nach Bezeichnungen absuchen, die die Worte "Duplikate" oder "beseitigen" enthalten. Auf diese Weise testen Sie nicht, ob die Bezeichnung effektiv ist und die Funktionalität des Befehls kommuniziert, und auch nicht den kommunikativen Nutzen von Kombinationen des Befehlsnamens mit korrespondierenden Symbolen (Icons) und Tooltipps. Sie testen lediglich, ob die Nutzer den Terminus wiederfinden können.

(Ich habe sogar schon eine noch schlimmere Aufgabenbeschreibung gesehen, die von drittklassigen Usability-Leuten stammte: "Verwenden Sie den Befehl Duplikate beseitigen, um zusätzliche Exemplare jedes Namens beseitigen." Wenn Sie den Leuten sagen, welche Funktion sie nutzen sollen, finden Sie niemals heraus, wie sie auf natürliche Weise mit der Software umgehen. Sie tun dann bloss, was sie tun sollen, und nicht das, was sie normalerweise tun.)

Eine gute Aufgabenbeschreibung für "Duplikate beseitigen" wäre folgende: "Sie haben eine Liste von Firmen, die früher bereits Ihr Produkt gekauft haben, aber manche Firmen tauchen dort mehrmals auf. Bearbeiten Sie die Tabelle so, dass jede Firma nur noch einmal vorkommt." Jetzt kennen die Testteilnehmer ihr Ziel, und es wird in einem sinnvollen Szenario präsentiert - aber sie können das Problem nicht einfach dadurch lösen, dass sie nach Schlüsselworten suchen. Stattdessen müssen sie nach Befehlen suchen, die ihnen vielleicht helfen könnten, die Aufgabe zu lösen. So testen Sie viel besser, ob die Nutzeroberfläche der Anwendung die Ziele der Nutzer unterstützt.

Auch sollten sie allgemeinere Aufgaben testen, die nicht mit einem einzelnen Befehl gelöst werden können.

Treffende Schlüsselworte beim Card Sorting

Das Problem der zutreffenden Schlüsselworte kann auch andere Forschungsmethoden durcheinanderbringen wie zum Beispiel das Card Sorting.

Ein gutes Beispiel dafür stammt aus unserem jüngsten Projekt, bei dem wir die Usability einer Patienten-Informations-Website im Gesundheitswesen verbessern wollen. Die Website soll Informationen über verschiedene verwandte Erkrankungen und über die jeweiligen Heilmethoden anbieten. Um die Angelegenheit weiter zu verkomplizieren, bietet die Website sowohl Informationen für das breite Publikum als auch für Profis an. Deshalb bestand eine der wichtigsten Herausforderungen darin, welche Organisationsprinzipien am besten als strukturierende Prinzipien für die oberste Ebene der Informationsarchitektur geeignet sind.

Card Sorting ist oft ein gutes Mittel, um erste Einsichten in das mentale Modell der Nutzer von einem Informationsraum zu gewinnen, und bei unserem Projekt hat es in der Tat gutes Ausgangsmaterial für die Informationsarchitektur geliefert. Nach der Card-Sorting-Studie haben wir mehrere Nutzertestrunden an Prototypen (Wireframes) durchgeführt, um die Struktur und ihre Präsentation durch die Website weiter zu verfeinern. Dieser ganze Aufwand wäre umsonst gewesen, wenn unseren Daten die Fähigkeit der Nutzer, Schlüsselworte zu finden, zugrunde gelegen hätte und nicht die Art und Weise, wie sie an die von der Website gemeinten Gesundheitsthemen herangehen.

Um die Vertraulichkeit des Kunden zu wahren, werde ich hier Beispiele der Probleme und Lösungen zeigen, die ich auf eine andere Branche übertragen habe - sagen wir: Landwirtschaft.

In dem (fiktionalen) Fall unserer landwirtschaftlichen Website behandeln wir verschiedene Feldfrüchte wie zum Beispiel Erdbeeren, Himbeeren, Mais und Weizen. Ausserdem behandeln wir verschiedene Tätigkeiten wie Aussaat, Anzucht und Ernte. Schliesslich zielen wir mit unseren Inhalten sowohl auf professionelle Bauern als auch auf Leute ab, die in ihrem Hinterhof ein paar Pflanzen anbauen wollen.

Eine Option wäre es, die Website primär nach den Feldfrüchten und sekundär nach den Tätigkeiten zu strukturieren. Nennen wir dies IA #1:

• Erdbeeren
  • Aussaat
  • Anzucht
  • Ernte

• Weizen
  • Aussaat
  • Anzucht
  • Ernte

• usw.

Alternativ könnten wir die Website primär nach den Tätigkeiten und sekundär nach den Feldfrüchten organisieren. Nennen wir das die IA #2:

• Aussaat
  • Erdbeeren
  • Himbeeren
  • Mais
  • Weizen

• Anzucht
  • Erdbeeren
  • Himbeeren
  • Mais
  • Weizen

• usw.

Angenommen, wir hätten eine Card-Sorting-Studie durchgeführt, um herauszufinden, mit welcher ersten Informationsarchitektur wieder den ersten Prototypen aufsetzen sollen. Es folgen zwei mögliche Kartensätze:

Kartensatz A	Kartensatz B
Erdbeeren säen	Aussaat von Erdbeeren
Erdbeeren anziehen	Anzucht von Erdbeeren
Erdbeeren ernten	Ernte von Erdbeeren
Weizen säen	Aussaat von Weizen
Weizen anziehen	Anzucht von Weizen
Weizen ernten	Ernte von Weizen

Er ist klar: Wenn wir einen dieser Kartensätze an die Nutzer ausgäben, würden wir sie Sortier-Übung ernsthaft verzerren. Geben wir Satz A aus, würden die meisten Nutzer die Informationsarchitektur Nr. 1 konstruieren, indem sie alle "Erdbeeren"- Karten zusammenlegen, alle Weizen-Karten usw. Geben wir Satz B aus, würde in der Regel Informationsarchitektur Nr. 2 herauskommen, da die meisten Nutzer die Karten nach den Tätigkeiten Aussaat, Anzug, Ernte sortieren würden.

Lösungen: Synonyme und divergierende Strukturen

Um ein besseres Ergebnis zu erzielen, muss unsere Card-Sorting-Studie die Nutzer zwingen, härter zu arbeiten und wirklich darüber nachzudenken, wie sie an die Konzepte auf den Karten herangehen.

Dies widerspricht natürlich unserem allgemeinen Usability-Ziel, bei dem es normalerweise darum geht, Aufgaben einfacher zu machen und die kognitive Belastung der Nutzer zu reduzieren. Aber denken Sie daran: Das Card-Sorting selbst ist kein Nutzeroberflächen-Design; es ist eine Übung, Denkmuster zu verstehen, um die mentalen Modelle der Nutzer zu erkennen. Deshalb ist es richtig, die Usability der Karten zu verringern, weil die Leute in der wirklichen Nutzeroberfläche keine Karten benutzen werden.

(Natürlich dürfen Sie die Usability der Karten nicht so stark reduzieren, dass die Teilnehmer sie gar nicht mehr verstehen, denn das würde sie beim Sortieren in die Irre führen.)

Um zu vermeiden, dass die Teilnehmer einfach nach passenden Schlüsselworten suchen können, bietet sich als Methode an, unterschiedliche Worte für das gleiche Konzept zu verwenden - also Synonyme einzuführen. Zum Beispiel können wir sagen: "Erdbeeren pflücken" statt "Erdbeeren ernten".

Um die Sache noch weiter aufzumischen, können wir eine Karte "Fragaria pflücken" einführen mit dem wissenschaftlichen Namen der Gattung Erdbeere. Das würde ich nicht wirklich tun, es sei denn, die Website zielte auf professionelle Botaniker ab, aber in unserem Beispiel aus dem Gesundheitswesen (unserem wirklichen Kundenprojekt) konnten wir sowohl die gewöhnlichen als auch die medizinischen Namen für den gleichen Sachverhalt auf verschiedenen Karten verwenden, und die meisten Nutzer konnten beide verstehen.

Ein anderer Weg, um die Suche nach treffenden Schlüsselworten zu vereiteln, besteht darin, divergierende (nicht-parallele) Strukturen in der Darstellung zu verwenden. Zum Beispiel können Sie auf eine Karte schreiben: "Aussaat von Mais", auf die andere: "Weizen säen".

Solche Taktiken verletzen eine der traditionellen Richtlinien für das Schreiben im Web, die besagt, dass parallele Strukturen schneller überflogen und leichter miteinander verglichen werden können und deshalb für das Präsentieren von Themenlisten besser sind. Wiederum gilt: "Schlechtes Design" ist hier richtig, weil es nicht unser Ziel ist, eine optimale Usability für die Karten zu entwickeln. Wir wollen die Teilnehmer aus der Routine herausreissen und zum Nachdenken bringen, und nicht dazu, ihre Aufgabe einfach und schnell zu erledigen.

Verzerrungen von Studien vermeiden

Ich sage normalerweise, Nutzertests sind einfach: Im Grunde geht es darum, sich ein paar wirkliche Kunden zu holen und zu beobachten, wie sie mit der Website oder Anwendung umgehen. Dieser Artikel aber berührt eine der Schwierigkeiten bei der Durchführung grösserer Studien: das Minimieren von Verzerrungen. Um das zu erreichen, müssen Sie sehen, wie sich die Leute aus eigenem Antrieb verhalten, anstatt ihnen Ihr eigenes Denken aufzuzwingen. Im letzteren Fall spiegeln sie das einfach nur wider, und Sie lernen nicht daraus, wie Sie Ihr Design für den Gebrauch im echten Leben verbessern können.

In den vielen Jahren, in denen ich Usability-Methoden lehre, habe ich gelernt, dass zwei der grössten Usability-Herausforderungen darin bestehen, gute Test-Aufgaben zu schreiben und die Test-Sitzungen auf eine möglichst neutrale Weise anzuleiten. Wie unsere Fallstudie hier zeigt, kann es aber auch schwierig sein, bei Card-Sorting-Studien zu vermeiden, dass die Teilnehmer beeinflusst werden.

Die Schönheit von Usability besteht darin, dass ihre Methoden so robust sind, dass sie auch dann nützliche Ergebnisse zeitigen, wenn Sie sie nicht richtig anwenden. Das gilt besonders für Nutzertests: Jedes Mal, wenn Sie Kunden beobachten, lernen Sie etwas, um die Profitabilität Ihrer Website zu steigern. Aber wenn Sie alles richtig machen, lernen Sie mehr. Und wenn Sie sich einmal der potenziellen Beeinflussung der Nutzer bewusst sind, können Sie Verzerrungen vermeiden und so den Wert Ihrer Forschungen steigern.

 

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