evux testet: Unmoderiert testen mit teston.io

 

 

Kürzlich meinte Susanne in unserem evux Weekly Meeting, sie habe da jemanden kennengelernt – das mag ja nichts Neues sein, unsere Sanne lernt ständig neue Menschen kennen – aber dieser Mensch arbeitete bei Teston. Und Teston habe sich auf das unmoderierte User Testing spezialisiert. Auch bieten sie via teston.io eine Plattform an, mit welcher man solche Tests ganz schnell und einfach abwickeln kann. Da wollten wir uns natürlich ein genaueres Bild verschaffen. Wie gut klappt denn ein solcher Test via teston.io? Und wann eignet sich ein solcher unmoderierter remote Usability Test überhaupt?

Was haben wir vorher über das unmoderierte Testen gedacht?

Grundsätzlich finden wir evüxe ja den moderierten Usability Test oder Usability Walkthrough ganz vorzüglich. In moderierten Tests sind wir nah am Nutzer, wir lernen ihn kennen und können so Empathie zu ihm aufbauen. Zudem können wir dort vertiefter nachfragen und bohren, wo wir es gerade für notwendig empfinden und das ganz spontan. Wir können auch die Testpersonen motivieren, beim Thema zu bleiben und so sicherstellen, dass alle Punkte des Leitfadens passiert werden. Ja genau, mit dem moderierten Nutzertest haben wir die Kontrolle und das gefällt uns.

Des Weiteren kann der moderierte Test durch Kunde und Projektteam miterlebt werden, live im Nebenraum oder aus der Ferne per Übertragung. Der im Nebenraum platzierte Protokollant nimmt direkt Schwierigkeiten auf, was den Moderator entlastet und ausserdem ermöglicht, dass wir schon am nächsten Tag mit Empfehlungen zur Verbesserung parat sein können. Und zu guter Letzt können wir hier in jeder Reifestufe des Konzepts agieren und Unzulänglichkeiten des Prototyps wegen der Fidelity ausgleichen. Das heisst, wir können auch bei Buttons, die (noch) nicht funktionieren fragen, was Nutzer dahinter erwarten.

Geht alles nicht mit dem unmoderierten Test, so dachten wir. Und wenn wir doch noch ein bisschen Spontanität imitieren wollen, dann müssen wir einen so wasserdichten Ablauf sowohl im Prototyp als auch in der Befragung abbilden, dass uns das extra Zeit kostet.

Also noch mal in Kürze unsere Thesen:

1. In unmoderierten Tests kann ich keinen Einfluss auf die Testperson nehmen und riskiere, dass sie früher abbricht und zu wenig Auskunft über den eigentlichen Untersuchungsinhalt gibt.
2. Die Fragestellungen muss ich in unmoderierten Tests wasserdicht vorbereiten.
3. In unmoderierten Tests habe ich Zusatzaufwände, um den Prototyp vorzubereiten, um ungewollte Sackgassen zu vermeiden.
4. Die Auswertung der Tests kann je nach Unterstützung aufwändiger als vorher sein.
5. Uns ist die Durchlaufzeit der Studie wichtig, da wir schnell zu Ergebnissen kommen wollen, die aber auch eine gewisse Tiefgründigkeit gewährleisten. Hier sind wir sehr unsicher.

Nichtsdestotrotz sind das alles Vorurteile, solange wir das nicht ausprobieren, und das haben wir gemacht. Kurz dazu noch, wie Teston funktioniert. Ein dort aufgesetzter Test kann gebucht werden als 5-Minuten- oder 20-Minuten-Test, was die Testzeit für die einzelne Person widerspiegelt. Die Testpersonenanzahl sowie ihre Eigenschaften können dann konfiguriert werden (also Testpersonen gehören mit dazu zur Leistung von Teston). Das Tool hilft dem Testleiter sogar dabei, wie man Fragestellungen formulieren soll. Die Testfragen werden dann abschnittsweise mit Hilfe von Links auf den Prototyp mit demselben verknüpft.

So «hangelt» sich die Testperson von einer Station zur nächsten. Als Ergebnis erhält der Testleiter die Videos der Tests im Portal von Teston und kann dann dort mit der Auswertung beginnen – keine Zusatzsoftware notwendig. Wir hatten einen kleinen Experimentalprototyp im Test, für den ein 5-minütiger Test ausreichend war. Schon ein Vorteil: Für so einen Test würde vermutlich niemand den Aufwand betreiben, Nutzer einzuladen, das Equipment aufzustellen, um zu übertragen etc.

These 1: Kein Einfluss auf die Testperson = keine Testmotivation

Das können wir aus der Erfahrung mit unserem Teston-Test nicht bestätigen, aber auch noch nicht völlig verwerfen. Wir haben hier keine generalisierbare Menge an Tests durchgeführt. Es war genau einer, aber die Testpersonen waren alle bei der Sache, haben hervorragend «laut gedacht» und eine gute Menge an Schwierigkeiten aufgedeckt. Testpersonen werden mit dem Tool geführt und man kann relativ sicher gehen, dass man Probleme findet. Wir sind noch nicht abschliessend überzeugt, weil die Testzeit so kurz war – er war auf 5 Minuten ausgelegt, die Tester brauchten und investierten demnach auch mehr als die 5 Minuten (unbekannter Weise: Herzlichen Dank dafür!). Diese Motivation nimmt möglicherweise bei längeren Tests ab.

These 2: Wasserdichte Fragestellungen

Eine Testaufgabe muss zwingend erfüllbar sein, insofern hat sich diese These bestätigt. In moderierten Tests kann man eben, wie oben schon beschrieben, auch mal nach der Erwartung eines nichtfunktionierenden Buttons fragen. Wenn der erste Weg nicht zum Ziel führt, versuchen Testnutzer weiter, die Aufgabe zu erfüllen. Ist das gar nicht möglich im Prototyp, kann das ein Abbruch oder unerwünschte Frustration bedeuten, die sich auf die allgemeine Einstellung auswirkt. Das halten wir für einen Punkt, der die Testergebnisse tatsächlich massgeblich beeinflussen kann.

These 3: Prototyp mit höherer Fidelity notwendig

Ja, das stimmt. Der Prototyp muss als solches in ein vollständig selbsterklärendes Testobjekt verarbeitet werden. Für unseren ersten Test hatten wir Seiten eingefügt, die den Testnutzer dazu anhielten, jetzt im Test zur nächsten Frage zu gehen, bevor es weiter geht. Damit hatten wir alle Testabschnitte inklusive dieser Moderationsseiten in einem relativen mid-fi Prototyp zusammengefasst. Eine Person klickte nach Aufgabe 1 nicht auf den Button, wo die Moderationsseite ausgelöst werden sollte, sondern ging direkt auf den Teston-Tab zurück und machte dort mit den Aufgaben weiter. Als sie wieder zurück auf den Prototyp-Tab ging und dann den Button klickte, kam natürlich die Moderationsseite. Schliesslich führte dies dazu, dass sie nie auf dem End-Screen landete.

Wir denken, auf solche, den Testablauf steuernde Mittel (oder Workarounds) würden wir in zukünftigen unmoderierten Tests verzichten. Da muss man schon ganz schön aufpassen, weil zwei Artefakte synchron gehalten werden müssen, also Prototyp und Fragebogen. Wenn man sicher gehen will, dass der Testablauf für jede Testperson funktioniert, wäre in unserem Falle sicher besser, statt der Moderationsseiten pro Teilaufgabe einen neuen Link mit einem passenden Seitenstatus zu benutzen. Das bedeutet etwas Mehraufwand beim Prototyp, der aber absolut machbar wäre.

Einen Prototyp in noch geringerem Ausbaustand würden wir nicht empfehlen, da eben sonst Aufgaben möglicherweise nicht mehr wirklich erfüllbar wären. Selbstverständlich kann man dann in einem befragungsähnlichen Set-up zu Einzelseiten Fragen stellen, aber darin ginge es «nur» noch um den Aufbau bestimmter Seiten, Interaktionen liessen sich so schlecht prüfen, ein Walkthrough ist also nur schwierig realisierbar.

These 4: Aufwändigere Auswertung

It depends. Wir sind erstens davon überzeugt, dass wir genauso viele Fehler gefunden haben, wie wir sie in einem moderierten Test gefunden hätten. Zweitens sind wir sehr angetan von der Unterstützung durch das Teston-Tool aus der Sicht des Testleiters. Wir sehen die Videos von den Testpersonen, sehen, um was es bei ihnen auf dem Bildschirm geht, können nebendran Notizen erfassen, auf dem Videozeitbalken Momente markieren und sogar Sprache in Text umwandeln.

So lassen sich auch die O-Töne (Originalaussprüche der Nutzer) leicht in den Ergebnisbericht oder die Präsentation überführen. Ausserdem kann man eine Farbcodierung verwenden, um zum Beispiel positive oder negative Erlebnisse oder Aussagen zu markieren, oder echte Schwierigkeiten von solchen, die an der Versuchsanlage liegen zu trennen. Für den überschaubaren Testrahmen sind die angebotenen Funktionalitäten die Richtigen und sicher besser als nur das blanke Video. «Supertools» wie Morae liefern noch Filterungen auf den Markierungen, Statistiken zu den Findings und können in moderierten Tests Beobachter, Moderator und Tester synchron unterstützen.

Wir schätzen sehr, dass man hier nicht die eierlegende Wollmilchsau bauen will, weil dies natürlich die Benutzung leicht zu erlernen macht. Den Bock schiesst man sich eigentlich nur selbst, wenn man den Fragebogen oder den Prototyp ungünstig konstruiert. Deshalb sollte mit einem kleinen Dry-run vor dem eigentlichen Test auch die Auswertung im gleichen Aufwandsrahmen sein wie in einem moderierten Set-up.

These 5: Unsicherheit des Zeitrahmens

Hier hat uns Teston weggefegt. In nur 3 h nach dem Aufsetzen des Tests waren die Ergebnisvideos parat. Wir konnten also noch am gleichen Tag auswerten. Unsicherheit im Zeitrahmen? Jetzt definitiv nicht mehr!

Weitere Themen, die uns bei der Nutzung aufgefallen sind

Unser Prototyp war ein mobiler Prototyp. Diesen musste man allerdings, weil Teston (noch) so funktioniert, auf dem Desktop verwenden. Das Bedienen des auf mobile Geräte ausgelegten Prototyps mit Laptop-Touchpad oder Maus fiel den Personen schwer. Eine Person hatte Mühe mit dem Scrollen und dann die Eingaben zu machen. Eine andere musste immer 4-Mal klicken, bis ihre Eingabe akzeptiert wurde. Das ist auf einem Handy direkt sicher einfacher für die Personen. Leider stand die Umgebung von Teston zu unserem Test noch nicht für mobile Endgeräte zur Verfügung, aber ab demnächst wird das der Fall sein.

Bei der Durchmischung der Personen war super, dass wir alle ausgewählten Länder dabeihatten (Deutsche, Österreicherin und Schweizerin). Ganz toll wäre, wenn das Alter noch etwas durchmischter gewesen wäre (im angegebenen Range von 30-45 waren die Teilnehmer*innen 32, 33 und 37). In einem realen Case würden wir in diesem Fall vermutlich «nachbestellen». Zudem waren zwei Tester selbst Designer. Ihre Inputs sind zwar auch spannend, aber Experten denken bei den Tests zu weit, sind zu stark lösungsorientiert unterwegs und hinterfragen gerne das Design. Während sie den Prototyp benutzen, denken sie schon an Alternativlösungen. Das hat sich auch hier wieder bestätigt. Ein nächstes Mal würden wir Techies (Softwareentwickler) und Designer im Recruitement ausklammern. Über diese Funktion verfügt Teston bereits, wir haben sie nur nicht genutzt. Die Qualität der Tester ist essenziell für die kleinzahligen Tests. Deshalb wünschen wir uns sehr, dass Teston hier weiter dran arbeitet.

Fazit und Empfehlung, wo unmoderierte Tests in dieser Form geeignet sind

1. Kurze Testrahmen, vor allem, wo man sonst nicht testen würde. Die kurzen Interventionen, kleinere abgesteckte Rahmen wie ein Onlinerechner oder eine Microsite, wo Auftraggeber oder Projektleiter mit den Augen rollen, wenn ein Nutzertest stattfinden soll (weil sie das unverhältnismässig finden), lassen sich so methodisch absolut vertretbar durchführen und auch regelmässig wiederholen. Leitfaden mit Aufgaben und das Testerprofil stehen ja, zack, wiederholten Test mit angepasstem Prototyp live schalten.
2. Integration in ein agiles Vorgehen einer reifen Applikation. Wenn ein Produkt bereits live ist und die inkrementellen Ausbauten nicht mehr substanziell sind, wir also im Continuous Discovery angekommen sind, können unmoderierte Tests auf Varianten sicher eine tolle Ergänzung sein, um mehr Informationen aus dem Feld zu erlangen – quasi A/B-Tests mit qualitativen Inputs.
3. Initialtests für bestehende Webapplikationen ohne bisherige Nutzerinterventionen. Eine laufende Webapplikation lässt sich vermutlich am einfachsten mit Teston testen bzw. mit einem unmoderierten Test. Wenn hier ein Nutzer nicht weiterkommt, ist es definitiv ein Problem und kann nicht an der Testanlage liegen. Hier ist dann auch die Skalierung interessant auf beispielsweise 50 oder sogar mehr Tester. Hierfür würden wir eine zweistufige Auswertung empfehlen. Stufe 1: Mit den Nutzungsaufgaben werden standardisierte Fragen (z. B. SUS, UEQ oder ähnliche) mitgeliefert, die als Richtungswert oder Benchmark bereits verwendet werden können. Stufe 2: Markierung von Problemen und Erarbeitung von Lösungsvorschlägen.
4. Verhaltenstests: Wenn es Fragen gibt, bei denen man Nutzer in der heute existierenden Welt beobachten möchte. Also zum Beispiel: Wie gehst du vor, wenn du eine neue Krankenversicherung suchen willst. Und das ganz ohne Prototyp. Da kommen sicher auch spannende Pfade heraus.

Unser Fazit lautet also:

Der Test hat super Spass gemacht und es ist auch eine Wohltat, wenn die erste Frage eines Account Managers nicht ist, «wie findest du mein Tool», sondern «hat der Test was gebracht?» – Danke Teston! Unseren Prototyp konnten wir weiterentwickeln und haben obendrein unseren Horizont erweitert. Unmoderierte Tests sind auf jeden Fall eine hervorragende Ergänzung des Testmethodenrepertoires. Aber auch den moderierten Test werden wir weiterhin durchführen, vor allem bei sehr komplexen Kontexten, politischen Umfeldern und in frühen/früheren Phasen der Produktentwicklung. Was denkt ihr darüber? Lasst uns gerne wissen…