Usability Tests für jedermann

Nachdem wir im letzten Teil dieser Artikelserie zum Thema User Experience über mentale Modelle gesprochen haben, sind diesmal Usability Tests das Thema. Zu Zeiten meines Studiums war die Durchführung von Usability Tests noch mit einem enormen Aufwand verbunden. Die allgemeine Vorstellung ihrer Durchführung war dadurch lange geprägt von kostspieligen Usability-Labs, in der die Probanden, wie in einer amerikanischen Krimiserie, durch eine einseitig durchsichtige Spiegelwand beobachtet wurden. Dazu teure Eyetracking-Vorrichtungen und natürlich eine große Anzahl an Testpersonen. Wir wollen ja schließlich relevante Ergebnisse…

Für die Einrichtung eines professionellen Testlabors kommen da schnell einige 10.000 € zusammen. Nicht, dass wir uns falsch verstehen: Wer die Möglichkeiten hat, auf eine solche Umgebung zuzugreifen – sei es als eigenes Labor oder über den Einkauf von Usability-Experten – kann sich glücklich schätzen. Gerade in kleinen und mittelständischen Betrieben wird es aber schwer sein ein Budget für diesen Einsatz zu finden.

Fehlendes Budget ist allerdings längst keine Entschuldigung mehr, keine Usability Tests durchzuführen. Ihre neu gewonnene Popularität verdanken sie wohl Jakob Nielsen oder Steve Krug mit seinem tollen Buch  “Don’t make me think”. Letzterer beschreibt eine sehr pragmatische Herangehensweise an Usability Tests, wie sie eigentlich in jeder Firma durchführbar sind.

Usability Tests sollten also in jedem Projekt zum Standard-Repertoire gehören. Und ich kann mich in meiner Laufbahn an nicht einen einzigen Test erinnern, der nicht hilfreich gewesen wäre.

Usability Tests erfüllen mich oft mit einer seltsamen Mischung aus Scham und Befriedigung: Scham, wenn man – als verantwortlicher Product Owner oder Entwickler – sieht wie der Anwender an Dingen scheitert, die man einfach nicht bedacht hat. Befriedigung, wenn man wertvolle Dinge gelernt hat und wenn Designs und Designanpassungen so funktionieren wie gewollt.

Was ist zu tun, wenn ich mit meinem Team anfangen möchte in die Welt der Usability Tests einzusteigen?

Wann testet man?

Eine der ersten Fragen die sich im Zusammenhang mit Usability Tests stellt, ist die Frage, wann der geeignet Zeitpunkt für Tests ist. Diese Frage lässt sich erstaunlich einfach beantworten: So früh wie möglich. Und das bedeutet wirklich früh: Schon bevor wir die erste Version der Software freigeben.

Ganz im Sinne der agilen Softwareentwicklung wollen wir kurze Feedbackzyklen. Aus dieser Sicht macht es keinen Sinn ein Design erst komplett auszuimplementieren, wenn wir es bereits vorher hätten verproben können.

Testen wir zu spät, laufen wir Gefahr, dass schlechte Design-Entscheidungen schon so weit zementiert sind, dass sie sich nicht oder nicht vertretbarem Aufwand mehr ändern lassen.

Usability Tests sind bereits sehr früh im Projekt möglich, sei es auf Basis von Papier-Prototypen, Klick-Dummies oder schon etwas weitergehende Prototypen. Dabei reicht es, wenn wir zum Zeitpunkt des Tests nur einen ganz bestimmten Pfad abbilden können. Dazu definieren wir Testaufgaben, die ausreichend scharf eingegrenzt sind (dazu später mehr).

Zutaten für einen erfolgreichen Usability Test

Für einen erfolgreichen Usability Test sind einige Dinge dringend erforderlich:

1. Ziele des Tests
2. Schriftliche fixierte Testaufgaben
3. Ein Testmoderator
4. Ein Screensharing Tool
5. Probanden die den Test ausführen
6. Team-Mitglieder die die Testergebnisse protokollieren
7. Eine professionelle Vorbereitung
8. Eine gemeinsames Nachbesprechung

Ziele des Tests

Wichtig bei einem Usability Test ist, dass wir nicht einfach nur einem Probanden einen Entwurf oder eine Software-Version zeigen und allgemein Feedback einholen. Vor dem Test werden die Ziele festgelegt. Beispiele für Ziele könnten sein:

• Findet der Anwender auf einem Touch-Gerät das Kontextmenü?
• Kann der Anwender unser Tutorial erfolgreich durcharbeiten?
• Kommt der Anwender damit zurecht, wenn wir alle Änderungen direkt speichern und keinen Speicher-Knopf mehr anbieten?

Testaufgaben

Basierend auf den Test-Zielen werden nun Aufgaben festgelegt, die ein Proband im Rahmen eines Tests erledigen soll. Vom Umfang her sollten die Aufgaben so geschnitten werden, dass die Dauer eines Tests 30 Minuten nicht überschreitet.

Testmoderator

Die Aufgabe des Moderators ist die Durchführung des Tests. Zu Anfang wird dieser den Probanden willkommen heißen und ihm die Testaufgabe erklären.
Zudem sollte hier bereits klar gemacht werden, dass nicht der Proband getestet wird, sondern die Software. Das Letzte was wir wollen, ist das die Testperson sich schlecht fühlt, weil unser Entwurf nicht funktioniert.
Als Moderator ist es wichtig, die Testperson nicht zu beeinflussen. Gerade wenn man selbst an der Entwicklung beteiligt war, was sich in einem kleinen Team oft nicht vermeiden lässt, kann dies anfangs sehr schwer fallen. Unbewusst verfällt man gerne in Suggestivfragen oder eine Rechtfertigungshaltung. Wenn die eigene Arbeit also nicht so funktioniert, wie man es sich vorher überlegt hat, oder der Entwurf kritisiert wird, muss man das hier einfach ertragen. Denn genau dafür machen wir den Test ja.
Während der Testdurchführung ist die Hauptaufgabe des Moderators, den Probanden dazu zu bringen laut zu denken (think aloud protocol). Wann immer die Testperson an einer Stelle hängt und überlegt, ist für uns interessant, was Sie gerade denkt. Sucht die Testperson nach einem bestimmten Begriff? Ist etwas unklar? Ist vielleicht etwas passiert, was für den Probanden überraschend war?
All das ist von außen nur schwer ersichtlich. Also wollen wir an diesen Denkprozessen beteiligt werden. Hilfreich sind hier Fragen wie “Was überlegst du gerade?”, “Wonach suchst du?” oder wenn etwas scheinbar Unerwartetes passiert: “War das das, was du erwartet hast?”.
Während eines Tests kommt es oft vor, dass Anwender den Moderator um Hilfe bitten, zum Beispiel “Wo kann ich das Dokument den speichern?”. Solche Fragen sollte der Moderator nicht direkt beantworten. In der Realität sind wir ja auch nicht da, um ihm zu helfen. Stattdessen können wir die Frage zurückspiegeln: “Wo würdest du diese Funktion denn erwarten?” und “Was würdest du jetzt tun, wenn ich nicht neben dir sitzen würde?”.
Natürlich kann es aber vorkommen, dass sich ein Anwender durch einen Fehler in unserem Design in eine Sackgasse manövriert. Wenn es erkennbar keinen Fortschritt gibt oder der Anwender deutlich frustriert wirkt, sollten wir natürlich eingreifen.

Screensharing-Tool

Das Screensharing-Tool klingt in der Zutatenliste vielleicht zunächst etwas überraschend. Aber wir wollen den Testverlauf ja verfolgen und dokumentieren. Dies ist die Aufgabe der weiteren Teammitglieder, da der Moderator sich voll auf seine Aufgabe des Moderierens konzentrieren soll.

Der Moderator und der Proband sollen den Test ungestört durchführen, auch um nicht künstlichen Druck zu erzeugen.

Wenn wir keinen extra Beobachtungsraum mit einem Einweg-Spiegel haben, übernimmt diese Aufgabe die Screensharing Software. Mit ihrer Hilfe übertragen wir den Bildschirminhalt des Testrechners in einen Extraraum, in dem der Rest des Teams die Beobachterrolle einnimmt.

Remote Usability Tests

Vorteil dieses Vorgehens ist, dass sich auch Moderator und Proband physikalisch an unterschiedlichen Orten befinden können. Dies erleichtert oft die Rekrutierung von Probanden, da nicht noch zusätzliche Aufwände durch eventuell notwendige Anreise entstehen.

Probanden

Die Probanden für den Test zu finden, ist oft eine Herausforderung. Idealerweise stehen uns “echte” Anwender für unseren Test zur Verfügung. Wie man diese rekrutieren kann, ist je nach Projekt sehr unterschiedlich. Realisiere ich ein Projekt für einen Kunden, ist es vielleicht einfach Tester aus einer Fachabteilung zu gewinnen. Verkauft man Software an Endkunden, hilft einem vielleicht ein Spezialanbieter.

Sollte kein “echter” Testanwender zur Verfügung stehen, ist ein Test nicht gleich unmöglich. In vielen Fällen können Tests auch mit alternativen Personen wie zum Beispiel Kollegen aus einem anderen Projekte oder Bekannten Sinn machen. Dies ist stark davon abhängig, wieviel Fachwissen zur Bedienung der Software notwendig ist und welche Aspekte wir testen wollen.

Neben der Frage, wer als Proband in Frage kommt, ist natürlich die Anzahl an Probanden zu klären. Um sinnvolle Testergebnisse zu erzielen, sind weitaus weniger Testteilnehmer notwendig als man erwarten könnte. Folgt man den Empfehlungen von Krug oder Nielson sind bereits 3-5 Benutzer ausreichend. Wenn man auf konkrete Projekte schaut, ist diese Anzahl aber schnell verständlich. Wir wollen ja nicht eine ultimative Liste aller Usability Probleme in unserer Software erstellen, sondern nur die schlimmsten identifizieren – und fixen!

Mit diesem Anspruch stellt man sehr schnell fest, dass sich auch bei einer geringen Anzahl an Testern die Ergebnisse schnell wiederholen. Fast jede Software hat viele schwerwiegende Usability Probleme, die sie einem förmlich zuruft. Man muss nur hinhören. Und genau das ermöglichen uns die Usability Tests.

Vorbereitung

Ein erfolgreicher Usability Test erfordert eine gründliche Vorbereitung. In dieser Vorbereitungsphase müssen folgende Punkte erledigt werden:

• Testaufgaben erstellen: Die Aufgaben für den Test müssen schriftlich fixiert werden. Wenn der Umfang wie oben beschrieben auf ca. 30 Minuten ausgelegt ist, sollte man pro Testperson mit Einführung und abschließenden Fragen eine volle Stunde einplanen
• Moderator bestimmen: Idealerweise findet man einen Moderator, der nicht direkt an der Umsetzung beteiligt war. Hat die entsprechende Person noch keine Erfahrung mit Usability Tests, empfehlen sich einige Team-interne Proberunden um die Moderatorfähigkeiten zu schärfen.
• Räume buchen: Die Räume müssen gebucht werden. Wir brauchen einen Raum, in dem Moderator und Proband ungestört den Test durchführen können. Ein weiterer Raum wird für das Beobachter Team gebucht.
• Hardware bereitstellen: Im Beobachter-Raum muss ein Rechner samt Beamer für die Übertragung zur Verfügung stehen. Im Test-Raum brauchen wir den Testrechner und ein extra Mikrofon um eine ausreichende Sprachqualität bei der Aufzeichnung und Übertragung zu gewährleisten.
• Software bereitstellen: Neben der zu testenden Software benötigen wir noch die Screensharing-Software für die Übertragung in den Beobachter-Raum und die parallele Aufzeichnung. Zum Glück ist in vielen Unternehmen eine passende Software bereits vorhanden (WebEx, GoTo Meeting, Skype Business, Zoom um nur ein paar Namen zu nennen).
• Dry Run durchführen: Vor jedem Test ist ein Probedurchlauf Pflicht. Insbesondere folgende Punkte sollten dabei geprüft werden:
  • Kann ich die gewählte Aufgabe mit dem zu testenden Artefakt überhaupt erfüllen?
  • Funktioniert die Übertragung?
  • Ist die Tonqualität ausreichend?
  • Funktioniert die Aufzeichnung?
  • Ist die Bildqualität der Aufzeichnung ausreichend?

All dies sind Punkte, die vor dem ersten Test geklärt sein müssen. Schließlich opfern die Probanden ihre Zeit für uns und können eine professionelle Durchführung erwarten.

Nachbesprechung

Nach der Durchführung treffen sich die Beobachter und der Moderator, aber nicht die Probande, zum gemeinsamen Debriefing.

Ziel dieses Meetings ist die gemeinsame Identifikation der schlimmsten Usability Probleme und die Definition von Maßnahmen. Im Debriefing nennt jeder Beobachter pro Test und Proband die schlimmsten Probleme (maximal eine Handvoll) die er im Test beobachtet hat.

Die Chance ist groß, dass bestimmte Probleme von mehreren Beobachtern identifiziert wurden.