Usability-Tests von Prototypen

Best-Practices und Experten-Tipps für Tests von Website- und App-Prototypen

RapidUsertests mit Prototypen laufen an sich genauso ab, wie mit einer fertigen Website oder App. Stelle uns einfach den Prototypen als URL zur Verfügung und erstelle den Test über unser Buchungsformular.

Wir empfehlen, Tests mit Prototypen als moderierte Tests durchzuführen. So kannst du Rückfragen stellen und falls noch nicht alles im Prototyp funktioniert, kannst du die Testpersonen besser anleiten.

Es gibt bei Tests mit Prototypen ein paar Besonderheiten, vor allem aus technischer Sicht und bei der Formulierung der Testaufgaben.

Wenn du diese Tipps beachtest, kann beim Usability-Test deines Prototyps aber nichts schiefgehen:

 

Den Prototyp erstellen und für den Test vorbereiten

Geeignete Tools verwenden – Aus unserer Erfahrung eignen sich Sketch, Figma und Adobe XD sehr gut, um den Prototyp zu erstellen. Um ihn per Link zugänglich zu machen, empfehlen wir Invision. Für RapidUsertests ist es aber nur wichtig, dass der Prototyp über eine URL erreicht werden kann. Welche Tools du verwendest ist ansonsten dir überlassen.

Prototyp an den Haupt-Use-Cases ausrichten – Um eine gute Basis für die Optimierung des Prototyps zu schaffen, sollte er die Haupt-Use-Cases abdecken und darauf optimiert sein. Diese müssen sich in den Aufgaben des Usability-Tests widerspiegeln. Sprich: Es müssen nicht alle Links klickbar sein, sondern nur die für den Test wichtigen Links.

Nicht notwendige Elemente ausblenden – Manche Prototyping-Programme (Axure, InVision, Marvel App, Adobe XD) hinterlassen Bedienelemente im Prototyp (Kommentar-Funktion, Screen-Übersicht, Spezifikation etc.), die für die Kollaboration mit dem eigenen Team gedacht sind, aber im Usability-Test  für Nutzer verwirrend und ablenkend sind oder bei mobilen Test oft auch ungewollt auf falsche Screens der Prototypen führen. Diese Elemente lassen sich in den meisten Programmen ausblenden, wie bspw. im Screenshot der Share-Funktion von InVision zu sehen.

Hotspot hinting or not? – In vielen Prototyping-Tools werden „Hotspots“ zur Verlinkung von Elementen genutzt. Diese leuchten – meist blau – auf, um anzuzeigen, welche Bereiche einer Seite anklickbar sind. Dies ist während der Design-Entwicklungs- und Diskussionsphase nützlich, aber wenn du beispielsweise herausfinden möchten, ob Benutzer den Call-to-Action finden, verrät der blaue Hotspot-Blitz ihn und du siehst daher nicht mehr das natürliche Verhalten des Nutzers. Standardmäßig sollten Hotspots daher ausgeblendet sein.
Wenn du das Gefühl hast, Nutzer könnten sich – trotz gut formuliertem Testkonzept – zu sehr „verlaufen“, ziehe einen moderierten Remote-Test mit RapidUsertests in Erwägung.

Screenshots komprimieren – Wenn du bei deinem Prototyp mit Screenshots arbeitest, solltest du sie mit Tools wie compressor.io oder tinypng.com komprimieren, damit die Tester keine langen Ladezeiten ertragen müssen.

Richtige Verlinkungen im Prototyp

Prototypen, deren Verlinkungen in Sackgassen oder aus dem Prototyp herausleiten, führen dazu, dass Nutzer die Orientierung verlieren oder auf den falschen Seiten landen. Vor allem in unmoderierten Tests beeinträchtigen diese Orientierungsverluste die Testergebnisse.

Konsistente und logische Links setzen – Alle Links müssen in sich logisch und konsistent sein, um die Nutzer nicht zu verwirren. Wenn das Logo auf einer Seite zur Homepage verlinkt, sollte es das auf allen anderen Seiten auch tun. Genau so sollten Links in der Navigationsleiste die Nutzer immer zur gleichen Seite führen.

Nicht aus dem Prototyp heraus linken – Vor allem bei Usability-Tests, die nicht moderiert werden (wie RapidUsertests) sollten keine Verlinkungen aus dem Prototyp herausführen, z.B. zu einer bereits fertigen Webseite. Dies birgt sonst das Risiko, dass die Nutzer nicht wieder zum Prototyp zurückfinden.

Nur die notwendigen Links – Bei unmoderierten Usability-Tests gibt es niemanden, der die Nutzer wieder auf den richtigen Weg leitet, wenn sie sich in der Linkstruktur verlaufen. Deshalb sollte der Prototyp bei dieser Art von Tests im Idealfall nur Links beinhalten, die für den Test auch wirklich benötigt werden. Die Verlinkung von noch nicht funktionierenden Elementen mit Overlays wie etwa „Diese Funktion ist leider noch nicht implementiert“ sollte vermieden werden, da sie für den Nutzer nur zu unnötiger Frustration führt.

 

Die Nutzer richtig instruieren

Ggf. auf technische Einschränkungen hinweisen – Funktioniert der Prototyp nur auf bestimmten Geräten oder mit einem bestimmten Browser oder Bildschirmauflösungen? (Invision unterstützt beispielsweise nicht Microsoft Edge.) Dann weise die Tester in dem Feld „Weitere Interessen oder Eigenschaften“ darauf hin.

Den Nutzern Zugangsdaten zur Verfügung stellen – Oft ist es sinnvoll, Prototypen im Web mit einem Passwortschutz zu versehen. Gib den Testern im Einstiegsszenario Zugangsdaten, um auf den Prototyp zugreifen zu können.

Beispiel: Bitte notiere dir vor Aufnahmebeginn diese Zugangsdaten: Benutzername: XXX / Passwort: XXX

Fragen, was die Nutzer hinter nicht-klickbaren Links erwarten würden – Auch wenn in einem Prototyp noch nicht alle Links funktionieren, können Sie die Nutzer fragen, was sie hinter diesen Links erwarten würden. So testen Sie, ob die Erwartung/das Verständnis mit Ihrer Absicht übereinstimmt.

Auf unfertige Website/App hinweisen – Die Nutzer sollten auf jeden Fall zu Beginn des Tests instruiert werden, dass es sich um eine unfertige Website/App handelt. Das Wort ‚Prototyp‘ könnte dabei zu unklar sein. Ohne diesen Hinweis behandeln die Nutzer die Website/App wie ein fertiges Produkt.

Fokus der Nutzer steuern – Instruiere die Nutzer, worauf sie achten sollen und was sie missachten können. Geht es in dem Test z.B. um die Navigation, sollten die Tester wissen, dass sie ihr Hauptaugenmerk darauf legen sollen und das Design noch vernachlässigen können.

Ladezeiten kommunizieren – Falls der Prototyp trotz komprimierter Bilder längere Ladezeiten vorweist, weise den Nutzer darauf hin, so dass er nicht vorzeitig den Test abbricht.

Beispiel: Es handelt sich noch um eine unfertige Version der Website/App, d.h. es kann sein, dass noch nicht alles funktioniert bzw. klickbar ist. Bitte erzähle uns trotzdem immer, wo du etwas vermutest und was du (wenn der Klick nicht funktioniert) dort erwartet hättest!

Prototypen mobiler Websites und Apps testen

Einsatz auf möglichst vielen Geräten ermöglichen – Bei RapidUsertests testen die Nutzer von zu Hause auf ihren eigenen Geräten, was die Tests besonders realistisch macht. Das bedeutet aber auch, dass sie auf einer Vielzahl verschiedener Geräte durchgeführt werden. Wenn dein Prototyp nur auf bestimmten Geräten funktioniert, kontaktiere uns bitte vorher.
Der Prototyp sollte auf jeden Fall auf weit verbreiteten Geräten funktionieren, um unser Panel nicht zu stark einzuschränken.

Voraussetzungen für unveröffentlichte Apps – Apps, die unveröffentlicht sind, müssen für iOS über eine Testplattform (z. B. Testflight) bereitgestellt werden. Für unveröffentlichte Android-Apps reicht es, die App online zugänglich zu machen. Sie sollte allerdings einen vertrauenswürdigen Dateinamen haben, um die Tester nicht skeptisch zu machen.

Add to Homescreen – Du testest eine zukünftige App, die aktuell aber nur mit einer URL zu erreichen ist? Damit die Testsituation für die Tester trotzdem so realistisch wie möglich ist, sollten sie den Link zu ihrem Homescreen hinzufügen.

Beispiel: Um den Prototyp nutzen zu können, füge bitte die aufgerufene Webseite als Lesezeichen zu deinem Homescreen hinzu. Dies funktioniert üblicherweise über die Optionen deines mobilen Browsers (z. B. "Zum Startbildschirm hinzufügen"). Öffne die Seite anschließend über dieses Lesezeichen auf deinem Homescreen. Gehe anschließend zur nächsten Aufgabe.

 

Usability-Tests mit Wireframes

Wireframes besser mit Moderator testen – Wireframes sind eine sehr rohe Form von Prototypen. Sie haben oft nur wenig Content und sehen ohne das Design sehr abstrakt aus. Dadurch sind sie oft nicht selbsterklärend und von den Nutzern wird ein hohes Abstraktionsvermögen verlangt. Es ist daher empfehlenswert einen Usability-Test mit einem Moderator im Labor durchzuführen, der bei Verständnisproblemen eingreifen kann.

Wireframe-Tests mit unmoderierten Tests – Entscheidest du dich doch für einen Wireframe-Test mit unmoderierten Tests, gilt es Folgendes zu beachten:

  • Selbsterklärende Gestaltung – Der Wireframe muss so selbsterklärend wie möglich sein, um die Nutzer auch ohne einen Moderator durch den Prototyp leiten zu können.

  • Sinnhaften Content liefern – Die Nutzer brauchen konkrete Inhalte, um sich im Prototyp zurechtzufinden. Lorem-Ipsum-Text und andere Platzhalter sollten vermieden werden. 

 Hier kannst du dir unser Wireframing-Kit herunterladen, mit dem du im Handumdrehen Wireframes für deinen nächsten Usability-Test erstellen kannst: Zum Wireframing-Kit

Besser keine RapidUsertests mit klickbaren PDFs

Von unmoderierten Tests klickbarer PDF-Prototypen raten wir aus folgenden Gründen ab:

PDF-Prototypen sind scrollbar – Dies kann den Nutzerfluss behindern und lässt den Test an Realitätsnähe verlieren.

PDF-Prototypen sind unberechenbar – Links in PDF-Prototypen sind unberechenbarer als bei anderen Prototyp-Arten. So passiert es zum Beispiel öfter, dass man zur Mitte der verlinkten Seite springt.

Tests, die von einem geschulten Moderator geleitet werden, können jedoch auch mit klickbaren PDFs durchgeführt werden.

Mit unserer Usability-Agentur Userlutions kannst du sowohl Tests von klickbaren PDFs als auch Prototypen in noch früheren Stadien testen, z.B. auch Papier-Prototypen. Außerdem konzipieren unsere UX-Experten bei Bedarf den Prototyp oder einzelne Seiten für Sie.

Bist du unsicher, ob wir die Vertraulichkeit und Geheimhaltung bei Usability-Tests von sensiblen Prototypen sicherstellen können? Hier findest du mehr Infos dazu.

Was du sonst noch alles testen kannst, erfährst du hier.