Bernd Lohmeyer
Ein weiteres Missverständnis: Usability Tests sind teuer
In einem vorigen Artikel schrieb ich schon über verschiedene Usability-Missverständnisse (Usability – Schluss jetzt mit den Missverständnissen!). Ich möchte die Sammlung noch ein wenig erweitern.
Gerne werden an allen Ecken und Enden Kosten gespart. Und da wird gerne auf Usability Tests verzichtet: “Das hat ja schließlich ein guter Designer entworfen…” Nun, auch Designer sind nur Menschen und können Fehler machen. Die sollte man schon aus Gründen des Investitionsschutzes frühestmöglich aufdecken. Und dazu sind eben Usability Tests da. Doch nun zu den Kosten. Denkt man an solche Tests, fallen häufig Stichwörter wie Usability Labor, Eye Tracking, Erhebungskampagnen, statistische Validierung etc. Ja, das kann alles dazu gehören – muss es aber nicht. Die Buchung und Beauftragung eines professionellen Usability-Labors ist kostenaufwendig. Aber selbst das lohnt sich in den meisten Fällen. Ich möchte hier aber zwei sehr einfache Testmethoden vorstellen, die mit wenig Aufwand durchzuführen sind und dennoch wertvolle Erkenntnisse liefern.
Papierprototypen-Test
Wie zuvor schon kurz erwähnt braucht man für diesen Test noch nicht mal lauffähigen Sourcecode. Es reichen Papierskizzen, die man aus dem Entwurfsprozess (frühe Konzeptionsphase) extrahiert. Diese Skizzen (Mockups) fallen da ja eh an, da man anhand dieser die Benutzerinteraktion durchdenkt und visualisiert. Nun überlegt man, welche Szenarien man mit welchen Nutzern überprüfen möchte. Man wählt die entsprechenden User Interface-Skizzen aus und lädt die Testteilnehmer ein. Eine Auswahl von fünf bis sechs Testteilnehmern sollte reichen. Mehr Teilnehmer erhöhen den Erkenntnisgewinn in der Regel nicht. Und statistisch belastbare Aussagen wird man auch mit 20 Teilnehmern nicht erreichen. Darum geht es aber auch gar nicht. Und wer keine sechs Teilnehmer “loseisen” kann, beschränkt sich eben auf zwei. Lieber einen kleinen Test machen als gar keinen!
Ein einzelner Test läuft dann wie folgt ab:
Man braucht einen Moderator, einen Testteilnehmer (möglichst repräsentativ für die spätere Nutzergruppe) und einen Kollegen, der den Computer simuliert. Nachdem der Moderator dem Teilnehmer die Situation erklärt hat, erhält der Nutzer eine Testaufgabe. Und es geht los: Der Kollege legt das Papier mit dem ersten Screen auf den Tisch. Der Testteilnehmer schaut sich den Screen an und beschreibt, was er sieht – er ist zuvor gebeten worden “laut zu denken”. Er “klickt” nun mit einem Stift oder Finger auf das Element, das ihn seiner Meinung nach weiterbringt. Der Kollege, der den Computer simuliert, legt nun die nächste Maske auf den Tisch oder “blendet” durch Auflegen eines Papierausschnitts ein Popup ein. Der Testteilnehmer interagiert nun durch Ausfüllen mit dem Stift oder Klicken mit dem Finger mit dem Papier-System. Der Kollege zeigt nun die nächste Maske – und so fort. Währenddessen macht der Moderator für die spätere Auswertung Notizen und hilft auch mal ein wenig nach, falls es erforderlich ist. Aber nicht zu früh, da sonst die Aussagen verwässern.
Eine solche Session sollte nicht länger als 60 Minuten dauern. Danach lässt bei allen Beteiligten die Konzentrationsfähigkeit nach. Man wiederholt diesen Test für jeden Testteilnehmer. Diese Lo-Fidelity-Methode mag zuerst befremdlich bis komisch wirken – aber sie funktioniert hervorragend! Genau wie bei Rollenspielen überrascht die Realitätsnähe immer wieder. Und wenn man das ganze noch etwas ausbauen möchte, kann man die Tests mit einer einfachen Videokamera aufzeichnen. So hat man für die Auswertung sogar noch Ton und Bild. Dieses einfache Testvorgehen liefert bereits in einer sehr frühen Projektphase wichtige Erkenntnisse. Ist man auf dem richtigen Weg? Wo muss man nachschärfen? Je früher man das erfährt, desto günstiger sind Änderungen vorzunehmen.
Aufwand: Die Auswahl der Testszenarien und Teilnehmer ist schwer zu schätzen. In dem Projektumfeld, in dem ich mich normalerweise bewege, ist das aber in zwei Tagen möglich. Der Moderator ist mit zwei Tagen Vorbereitung, einem Tag Durchführung und zwei Tagen Nachbereitung beschäftigt. Der Kollege, der den Computer simuliert, ist in der Regel so tief im Projekt drin, dass die Vorbereitung sich auf ein paar Stunden beschränkt. Es kommt für ihn der Tag der Durchführung hinzu. Die Testteilnehmer sind mit jeweils einer guten Stunde eingebunden. Das ist überschaubar.
Funktionaler Prototypen-Test
Später im Projekt, wenn in der Entwicklungsphase nun schon die ersten funktionalen Ergebnisse entstehen, sollte man diese auch so früh wie möglich testen. Das Vorgehen ist ganz ähnlich. Nur dass man keine Papier-Mockups verwendet, sondern die Testteilnehmer mit echter Software umgehen lässt. Der Computer muss nicht mehr simuliert werden – der geschätzte Kollege ist dafür also nicht mehr erforderlich. Ansonsten ist der Ablauf derselbe: Man braucht den Moderator, der die Tests vorbereitet, begleitet und nachbereitet. Und natürlich brauchen wir wieder fünf bis sechs Testteilnehmer. Jeder Einzeltest dauert ca. 60 Minuten. Der Moderator begleitet die Tests wie zuvor. Bei einem Usability Test funktionaler Prototypen sollte man ernsthaft in Erwägung ziehen, eine Protokollsoftware einzusetzen. Diese protokolliert alle Ereignisse auf dem Bildschirm, nimmt den Ton auf (erinnere: “laut denken”) und zeichnet über eine einfache Webcam das Bild der Testperson auf. So können später kleine Clips erstellt werden, die die Stolpersteine in der Software sehr anschaulich verdeutlichen.
Aufwand: Nachdem die Testszenarien identifiziert und Teilnehmer eingeladen sind, leistet der Moderator zwei Tage Vorbereitung und einen Tag Durchführung. Die Sichtung der Software-Protokolle ist etwas umfangreicher als beim Papier-Test. Die Nachbereitung ist aber dennoch in vier Tagen gewissenhaft zu erledigen. Die Protokollsoftware gibt es je nach Ausbaustufe von OpenSource bis Highend. Ich komme mit einer Software für ca. EUR 1000,- als Einzelplatzlizenz sehr gut zurecht. Eine Anschaffung, die sich wirklich lohnt.
Fazit
Zusammengefasst kann ich nur sagen, Usability Tests müssen nicht aufwendig sein. Man kann vieles schon mit Bordmitteln erreichen. Man muss nicht unbedingt super ausgestattete Labore engagieren. Ich möchte damit nicht gegen professionelle Usability-Labore reden. Ganz im Gegenteil: Unternehmen wie Amazon und Co können darauf nicht verzichten – das wäre ein teurer Spaß, sie verlören Millionen. In vielen anderen Projektsituationen kann man es aber gerne ein wenig kleiner angehen. Denn lieber ein kleiner Usabilitytest als gar keiner!