Während der Pandemie mussten wir unsere qualitative Forschung schnell auf einen Remote-Ansatz umstellen. Aber auch jenseits von Corona sind remote User Experience Labs relevant geblieben, denn nicht immer können alle Verantwortlichen an einem Ort sein. Außerdem verzichten viele Unternehmen auf Experience Labs, die persönlich vor Ort stattfinden, da sie vor allem bei dezentralen Teams zu hohen Kosten führen und durch zusätzliche Organisation und An- und Abreisen sehr viel Zeit in Anspruch nehmen können.
Wie aber gelingt das Testen eines Prototypen remote?
Hier sind unsere Learnings: Wenn wir neue und verbesserte Funktionen oder Produkte einführen, ist die Validierung durch Nutzer:innen entscheidend. On-Location-UX-Labs sind oder waren für viele die bevorzugte Methode, um intuitive und erfolgreiche Produkte für Kund:innen zu gewährleisten.
Durch COVID-19 mussten wir uns innerhalb kürzester Zeit auf einen Remote-Ansatz umstellen. Das erforderte die Anpassung unserer Methoden, Tools und Kommunikation. Es bedeutete auch, sich einer völlig neuen Reihe von Herausforderungen und Problemen zu stellen.
In diesem Artikel möchten wir unsere Erfahrungen mit Remote UX Labs, unseren Ansatz, die Probleme, denen wir begegnet sind, und das, was wir bisher gelernt haben, teilen.
Unsere Erfahrungen basieren auf unzähligen Testfällen, die wir seit 2020 durchgeführt haben - alle in Form von UX Labs. Trotz unterschiedlicher Zielsetzung der Tests, waren die Herausforderungen für die Teams oftmals dieselben.
Die DSGVO (Datenschutz-Grundverordnung) hat klare Regeln in Bezug auf den Schutz personenbezogener Daten von Testpersonen. Alle, die mit den persönlichen Daten der Tester:innen in Kontakt kommen, unterliegen den DSGVO-Richtlinien. Das betrifft nicht nur die Menschen, die am UX Lab beteiligt sind, sondern auch die Tools, Kund:innen und Dienstleistende.
Wir haben darauf geachtet, unsere:n Datenschutzbeauftragte:n frühzeitig in die Planung unserer UX Labore einzubeziehen. Es wurden Auftragsverarbeitungsverträge erstellt, um sicherzustellen, dass unser Setup DSGVO-konform ist. Darüber hinaus haben wir wiederverwendbare rechtliche Vorlagen für verschiedene Szenarien der Datenverarbeitung entwickelt, um Zeit und Geld bei zukünftigen UX Labs zu sparen.
Aber nur auf dem Papier DSGVO-konform zu sein, reicht nicht aus: Wir haben gelernt lieber auf Nummer sicherzugehen, wenn es um die DSGVO geht. Das heißt sicherzustellen, dass alle beteiligten Stakeholder und Teammitglieder genau wissen, wie sie mit personenbezogenen Daten umgehen sollen.
Egal wie gut die Anreize oder die Vorbereitung der Testpersonen sind, es gibt immer unvorhergesehene Umstände, die dazu führen können, dass diese nicht erscheinen oder nicht geeignet sind. Deshalb planen wir normalerweise zusätzliche Interviews mit Ersatzkandidat:innen am späten Nachmittag des Testtages mit ein. Die Anzahl der Backup-Interviews hängt von der Gesamtzahl der Tests ab. Ein bewährtes Verhältnis für uns ist ein Backup-Interview für fünf reguläre Interviews.
Alles startklar und dann das: Veraltete Browser-Versionen, die aktualisiert werden müssen, um die erforderlichen Web-Apps zum Laufen zu bringen oder - noch schlimmer - Probleme mit einer langsamen Internetverbindung inklusive schlechte Audio- und Videoqualität. Solche Szenarien führen immer wieder dazu, dass wertvolle Interviewzeit verloren geht, oder aber, dass Interviews abgesagt werden müssen - was alle Parteien frustriert und verärgert. Oft sind diese Probleme aber durch etwas Vorbereitung vermeidbar.
Wir haben (auf die harte Tour) gelernt, uns Zeit und Nerven zu sparen, indem wir genauer auf die benötigte technische Einrichtung der Testperson achten. Egal, ob ihr die Tester:innen selbst rekrutieren oder eine Agentur beauftragt, stellt vorab sicher, dass die benötigten technischen Anforderungen für alle Beteiligten gegeben sind.
Um zusätzlich auf kleinere technische Probleme, wie Kamera- oder Mikrofonprobleme spontan reagieren zu können, ist es hilfreich, einen zeitlichen Puffer pro Interview einzuplanen. Es schadet außerdem nicht, eine Person in den ersten Minuten des Anrufs dabei zu haben, die als Technikexpert:in fungiert und kleinere Probleme direkt lösen kann und bei der Einrichtung hilft.
Das Tool, das verwendet wird, um remote mit der Testperson zu kommunizieren, muss verschiedene Kriterien erfüllen.
Für die Testperson:
Ein weiteres Learning für uns ist, dass die datenschutzkonformen Tools leider nicht immer die benutzerfreundlichsten für die Testerpersonen sind. Uns hat es geholfen eine Schritt-für-Schritt-Anleitung im Voraus zu senden, wie beispielsweise das Videoanruf-Tool in verschiedenen Browsern eingerichtet werden kann. Die technische Einrichtung mit den Expert:innen zu Beginn des Remote-Anrufs hilft auch in diesen Situationen.
Es gibt verschiedene Möglichkeiten, Smartphone-Apps remote zu testen.
In vielen unserer UX Tests haben wir die erste Option gewählt und ein Smartphone-Mock-up auf einer Website getestet. Trotz einfacher Einrichtung haben wir festgestellt, dass sich das Scrollverhalten in einem Mock-up für die Nutzer:innen nicht natürlich anfühlt. Der Effekt ist, dass die Nutzer:innen die Bildschirme unterhalb des ersten Viewports nicht wirklich erkunden.
Für unsere regelmäßig stattfindenden Telekom UX Labs wählen wir häufiger Option 3, mit der wir für das Szenario gute Erfahrungen gemacht haben. Der Prototyp wird dann direkt in Figma erstellt und durch Screensharing geteilt. Das funktioniert im Falle der Telekom UX Labs gut, da wir hier überwiegend Wordings von Dialogen oder einzelne Buttons testen.
In der Vergangenheit haben wir UX Labs vor Ort durchgeführt. Die Teammitglieder oder Kund:innen, die die UX Labore beobachteten, waren normalerweise im nächsten Raum und machten Notizen auf verschiedenfarbigen Post-its. Am Ende des Tages hatten wir eine Wand voller Erkenntnisse. Wir würden sie alle zusammen besprechen, die Schlüsselerkenntnisse extrahieren und die nächsten Schritte gemeinsam entscheiden. Das ist offensichtlich bei remote Labs keine Option. Leider hatten wir das Problem dabei anfangs nicht erkannt. Wir hatten in einem der ersten Remote UX Labs nicht geklärt, wo und wie während der Interviews Notizen gemacht werden sollten. Wir haben auch nicht darüber gesprochen, wie wir die Ergebnisse dokumentieren wollten, um sie mit unseren Kund:innen und Teammitgliedern zu teilen. Das Ergebnis war, dass jede:r ein anderes Tool verwendet hat und die Notizen selbst stark voneinander abwichen und schwer zu vergleichen waren. Das hat viel zusätzliche Arbeit und Aufwand verursacht.
Aus diesem Fehler haben wir gelernt und eine Vorlage für ein gemeinsames Notizdokument erstellt. Jede:r, der am UX Lab teilnimmt, kann gleichzeitig seine Beobachtungen aufschreiben. Die Schlüsselfragen stehen oben auf dem Dokument, damit alle wissen, nach welchen Erkenntnissen sie Ausschau halten sollen. Wir haben auch gute Erfahrungen mit dem "Rainbow Spreadsheet"-Format gemacht. Es erleichtert die Auswertung und Extrahierung von Schlüsselerkenntnissen erheblich.
Wir wissen, dass Design-Sprints normalerweise freitags Nutzertests durchführen. Wenn aber nicht nur die Testperson remote interviewt wird, sondern auch das gesamte Team remote arbeitet, ist die Aufschlüsselung aller Notizen, die Analyse und die Dokumentation komplexer und dauert etwas länger. Der Versuch, alles an einem Interviewtag zu erledigen, führte nicht wirklich zu den besten Ergebnissen.
Deshalb stellen wir grundsätzlich sicher, dass wir den Morgen des folgenden Tages blocken. Auf diese Weise sind alle ausgeruht, während die Erkenntnisse noch frisch sind. Wir nutzen diese Zeit, um die Analyse vom Vortag zu überprüfen, die wichtigsten Erkenntnisse zu extrahieren, die nächsten Schritte zu formulieren und die Erkenntnisse zu dokumentieren.
Wir haben festgestellt, dass es schwieriger ist, sich an die Testpersonen und die Dinge, die sie gesagt oder getan haben, zu erinnern, wenn zwischen den Interviews und der abschließenden Bewertung ein Wochenende liegt.
Das sind die Haupterkenntnisse, die uns bei DAYONE geholfen haben, unsere Remote-Nutzerinterviews bisher zu optimieren und unsere Vorgehensweisen kontinuierlich zu verfeinern. Wir sind sicher, dass es noch viele weitere Tipps und Tricks gibt. Mit jedem neuen Remote UX Labor und jedem unterschiedlichen Testziel erweitern wir unser Wissen und verbessern unseren Prozess ein Stück mehr.
Teilt gerne eure Erfahrungen mit Remote UX Labs mit uns. Habt ihr weitere Tipps oder Insights, die wir noch nicht aufgelistet haben?
Artikel teilen:
Helena ist seit 2017 Teil des Teams und als Lead-UX-Designerin für den B2C-Bereich von KIND verantwortlich. Mit ihrem Hintergrund als Produkt-Designerin verfügt sie über ein breites Wissen an Design Thinking und Lean-Innovation-Methoden. Diese setzt sie nicht nur für ihre Kund:innen lösungsorientiert ein, sondern auch für die Weiterentwicklung des DAYONE-DIaaS-Frameworks. Ihr Ziel dabei ist es, durch die Vermittlung und den Einsatz von DIaaS die Design Maturity der co-kreativen Kundenteams kontinuierlich zu steigern.
