Digital Tourism Blog

„Ein Design ist erst fertig, wenn es verwendet wird.“
Wie wahr. Und doch. Wie oft werden digitale Anwendungen entwickelt, bei denen man später anhand der Analytics-Zahlen feststellen muss: Wird gar nicht genutzt.

Und hier stellt sich die Frage: wurden denn diejenigen, die die Anwendung nutzen sollen, mal irgendwie eingebunden?
Es gibt zahlreiche gute Gründe, warum Sie digitale Anwendungen testen sollten, bevor sie in die Umsetzung gehen. Warum? Ganz einfach. Sie sparen sich eine Menge Zeit, Ärger und auch Stolperfallen in der technischen Umsetzung, wenn Sie das Konzept auf diese Weise weiter feinschleifen. Und Sie stellen sicher, dass Sie das Ganze nicht für sich und Ihr Team machen, sondern für den Nutzer. Denn am Ende muss es für sie passen. 

Mindestens einmal vor einem größeren (Re)Launch sollten Sie getestet haben. Mit Nutzern versteht sich. Oder zumindest mit Personen, die nicht am Konzept, an der Redaktion, an der Umsetzung oder sonst als Stakeholder beteiligt sind.

Reiner Selbstzweck sollte es am Ende aber auch nicht sein. Natürlich muss eine konkrete Fragestellung klar definiert sein oder im Raum stehen. Und davon abhängig ist es auch, zu welchem Zeitpunkt im Projekt Sie das Testing am besten einplanen. Je nach Fragestellung oder Fokus macht es einen Unterschied, ob sie sehr früh testen – dann meist auf Basis von Wireframes – oder eher zu einem späteren Zeitpunkt, wenn bereits ästhetische Aspekte und konkretere Contents inkl. Wording berücksichtigt werden können.
In ihrem Blogbeitrag zum Thema „Prototyping“ zeigt UX-Designerin Sina Lange auf, welche Detailgrade an Prototypen es gibt und wann welcher davon beim Testing am besten zum Einsatz kommt.

In jedem Fall sollte das Testing – mit wenigen Ausnahmen (siehe unten) – aber vor der technischen Umsetzung passieren. Spätere Anpassungen am Aufbau, Struktur oder einzelnen Modulen der Anwendung werden immer aufwändiger, umso später sie im Projekt passieren. Ganz zu schweigen davon, dass Sie dann möglicherweise den Nutzer schon verloren haben.

Mich wundert, wie häufig wir in Projekten immer noch hören: „Das können wir dann ja auch nach dem Onlinestart testen.“ (häufig bedingt durch eine straffe Zeitschiene im Projekt). Natürlich geht das grundsätzlich. Aber sinnvolle Maßnahmen bei gefundenen Optimierungsbedarfen einzuarbeiten, ist dann um ein Mehrfaches teurer und dadurch häufig aufwändiger und schwerer durchzusetzen. Ein Grund, warum wir bei infomax nun in frühen Phasen intern testen.

Und wenn man dann testet und eigentlich nur eine Bestätigung dessen bekommt, was man als Hypothese hatte? Auch nicht schlimm. Zumal sie meistens noch was anderes von den Nutzern erfahren haben – auch wenn es ursprünglich nicht die Fragestellung war, mit der Sie in den Test gegangen sind. Zu einem Beispiel berichten wir in Kürze hier in unserem Blog: „Einen Nutzertest bereut man nie! Wenn Erkenntnisse überraschen.“

Bei manchen Funktionalitäten kann es aber tatsächlich schwer werden, vor der technischen Umsetzung zu testen. Ein Routing, (Push) Notifications oder auch eine Offline-Fähigkeit ist erst mit einer Lokalisierung vor Ort wirklich spannend. Wann und wo wir Tests im Feld machen, berichten wir in Kürze hier im Blog: „Routing, Notifications und Offline-Fähigkeit – wie testet man das überhaupt?“

Aber auch nach einem Launch ohne Testing gibt es noch viele Optionen, Nutzerinsights zu generieren. Beispielsweise dann, wenn man verschiedene Varianten einer Funktion oder eines Moduls hat. Dann kann beispielsweise AB-Testing Sinn machen. Vorteil: die Anwendung ist bereits umgesetzt und online und sie können mittels Tools (bei uns kommt in der Regel Optimize von Google zum Einsatz) die Nutzer entscheiden lassen, welche Variante eher zum Ziel führt.
Interessant ist diese Methode vor allem dann, wenn Sie sicherstellen möchten, dass ihre Conversions durch eine Anpassung oder Weiterentwicklung der Anwendung nicht abfällt. Umso näher Sie also an einer buchbaren Leistung sind, desto genauer sollten Sie sich überlegen, Änderungen ohne ein Testing bereitzustellen.

AB-Tests können aber auch wertvoll sein, um Präferenzen der Nutzer einschätzen zu können. Gerade wenn im Team keine eindeutige Entscheidung getroffen werden kann, was die bessere Option ist. Vor diesem Hintergrund haben wir beispielsweise auch einen AB-Test im Rahmen einer Labstudie aus unserem Digital Tourism Lab angesetzt. An einer Stelle fragten wir uns: Können wir mittels Tooltip auf eine für die Studie zentrale Funktion (Standortlokalisierung) stärker aufmerksam machen? Beeinflusst ein Tooltip, der auf den Mehrwert hinweist, die Rate derer, die der Lokalisierung zustimmen?

Sie sehen: es gibt nicht das EINE Testing, sondern verschiedene Anlässe, Formen und Zeitpunkte, an denen es Sinn macht, Nutzer zu involvieren.

Und wann testen Sie nun das nächste Mal?

Schnellfassung
Warum Prototyping und Testing dazu beitragen können, dass es gar nicht erst soweit kommt – das möchten wir Ihnen in dieser Blog-Reihe vermitteln. Die Beiträge geben Einblick in verschiedene Projekte, bei denen Testing und Prototyping das Endprodukt besser gemacht haben. Sie sollen auch aufzeigen, warum es nicht DAS eine Testing gibt und auch, welche Vorüberlegungen und Vorbereitungen schon zu Beginn eines Projekts gemacht werden sollten.

• „Show, don’t tell.“ Das frühe Visualisieren ermöglicht Feedback. Warum Prototypen im Projekt nicht nur fürs Testing gut sind.
• ….und plötzlich war es rund! Wie ein Hallway-Test den Durchbruch ermöglichte. (in Kürze)
• Mit oder ohne Tooltip? Eine Studie dazu, wie und wann Nutzer ihren Standort freigeben. (in Kürze)
• Einen Nutzertest bereut man nie! Wenn Erkenntnisse überraschen. (in Kürze)
• Routing, Notifications und Offline-Fähigkeit – wie testet man das überhaupt? (in Kürze)