Test. Learn. Adapt. Repeat. – Ein Aufruf zum iterativen Testen

Wir UX-Designer und Produktmanager wissen alle, wie es geht. Das sollten wir zumindest, und falls nicht, können wir es überall im Netz nachlesen: Nutzertests gehören als fester Bestandteil in jede Phase der Produktentwicklung.

Doch damit nicht genug, sage ich, und springe zumindest zum Teil auf den Zug von Jeff Gotthelf (Lean UX) auf. Jeff findet, man sollte am Ende jeder Iteration, also jedes Sprints, eine UX Research Technik einsetzen

Theorie und Praxis

Das klingt sehr theoretisch und sehr idealistisch und das ist es auch. Ich zumindest habe bisher noch in keinem Team gearbeitet, in dem Lean UX Prinzipien auf diese Weise angewandt wurden.

Tatsächlich ist es in der digitalen Produktentwicklung häufig so, dass einmal am Anfang und einmal am Ende getestet wird – wenn überhaupt.

Die Begründungen dafür sind mannigfaltig, lassen sich aber mit “wir haben doch keine Zeit” zusammenfassen.

Warum man sich die Zeit nehmen sollte, häufiger zu testen, möchte ich an einem Beispiel zeigen.

Das Vorzeigeprojekt

Bei einem meiner Kunden unterstützte ich vor Kurzem ein kleines Team, das für die Entwicklung von Apps zuständig ist. Wir arbeiteten an einem sogenannten One-Trick Pony, einer App die auf einen einzigen Anwendungsfall zugeschnitten ist.

Die Philosophie des Teams ist, die eigenen Arbeitsweisen regelmäßig zu überprüfen und immer wieder neue Methoden auszuprobieren, um für die Nutzer das beste Produkt mit der besten User Experience zu bauen.

So haben sie sich zum Beispiel für dieses Projekt von strengen Scrum Prozessen mit festen Iterationen losgesagt und arbeiten dadurch flexibler und schneller. Es wurden aber auch Nutzertests fest in die Produktentwicklung eingeplant und zuletzt führten wir sogar alle drei Wochen einen Test durch.

Fast die ganze Zeit haben wir am tatsächlichen Objekt getestet. Unser Prototyp ist schon die richtige, von unseren Entwicklern programmierte App und wird stetig weiterentwickelt.

Lernen und Anpassen

Screen mit sticky Footer

In einem der Nutzertests fanden wir ein schwerwiegendes Problem: auf einem der wichtigsten Screens scrollten die Testteilnehmer nicht. Der Screen hat einen sticky Footer – also ein am unteren Screenrand fixiertes Panel – mit dem Call To Action, dem Button der den Nutzer einen Schritt weiterbringt. Dass man den oberen Teil des Screens scrollen kann, fanden die Testteilnehmer gar nicht oder nur mit Hilfestellung heraus.

Wir setzten uns also nach dem Test alle zusammen und diskutierten verschiedene Lösungen für dieses Problem. Ein Entwickler schlug vor, dass wir mit einer Animation arbeiten könnten. Die Idee war, den Screen zu Beginn automatisch von unten nach oben scrollen zu lassen, um dem Nutzer zu verdeutlichen, dass es nach unten hin weiter geht.

Das ganze Team war von der Idee begeistert. Wir waren sicher, dass das Problem gelöst ist.

Wiederholen

Und nun tat das Team etwas, das viele andere Teams nicht getan hätten: Die Entwickler bauten die Animation ein und wir gingen damit in den nächsten Test.

Nach dem Test jedoch waren alle ein wenig enttäuscht und ernüchtert, denn es hatte wieder keiner der Testteilnehmer ohne Hilfe gescrollt. Die Animation hatte keiner von ihnen wargenommen. Vermutlich waren sie viel zu sehr damit beschäftigt, den Screen zu untersuchen.

Die Erkenntnis

Screen mit angeschnittenem Content hinter dem sticky Footer

Wahrscheinlich war ich die Einzige, die nach diesem Test geradezu euphorisches Bauchkribbeln verspürte. Hatte er doch bewiesen, dass es nicht ausreicht, ein gefundenes Problem mit einer neuen Hypothese zu beseitigen und es darauf beruhen zu lassen.

Wir setzten uns natürlich erneut als Team zusammen und entschieden uns dafür eine der anderen Ideen umzusetzen: Teile des Screens hinter dem sticky Footer wurden in den Anschnitt gelegt, um dem Nutzer anzudeuten, dass es nach unten weitergeht.

Selbstverständlich haben wir auch diese Hypothese wieder getestet und tatsächlich hat es diesmal funktioniert. Sechs von sechs Testteilnehmern haben auf Anhieb auf dem Screen gescrollt. Teilweise sogar noch bevor sie sich den Screen genauer angesehen haben, so als wäre der Anschnitt an sich schon ein Trigger zum Scrollen.

Die Schwierigkeiten

Wie zu erwarten sind diese Tests alle drei Wochen nicht ohne Probleme vonstattengegangen und schon regen sich Widerstände im Team. Man sollte nur testen, wenn es wirklich etwas herauszufinden gäbe, heißt es da. Oder: “Wir entwickeln nur noch für den nächsten Test und arbeiten nicht mehr an unseren Stories.”

Ein Teil der Probleme könnte daraus resultieren, dass wir einen neuen iterativen Prozess (alle drei Wochen ein Nutzertest) an einer Stelle eingeführt haben, an der strenge Iterationen gerade abgeschafft wurden.

Weitere Schwierigkeiten sind z.B. Ressourcenengpässe oder Blocker die sich in anderen Projekten des Teams ergeben. Drei Wochen sind nicht lang und schon sieht es tatsächlich so aus als würde das ganze Team nur damit beschäftigt sein, den Prototypen für den nächsten Nutzertest fertig zu machen.

Und jetzt?

Dieses Beispiel veranschaulicht sehr schön, wie fatal es sein kann, die vermeintlichen Lösungen von gefundenen Usability Problemen nicht erneut zu testen. Aber zeigen die erwähnten Schwierigkeiten nicht, dass iteratives Testen auf Dauer kaum durchfürbar ist?

Meine Annahme ist, und hier bin ich wieder ganz nah bei Jeff Gotthelf, dass sich schlanke UX Research Methoden in agilen Prozessen durchaus in jeder Iteration oder zumindest sehr regelmäßig einsetzen lassen. Dadurch sollte aber der normale Fortlauf der Produktentwicklung nicht gestört werden.

Und wenn die Produktentwicklung gar nicht in Iterationen stattfindet, sollten natürlich auch die Termine für die Tests flexibler geplant werden.

Mehr darüber, welche Methoden sich anbieten und wieviel Aufwand sie jeweils erzeugen könnt Ihr in dem wunderbaren Artikel “Never Show A Design You Haven’t Tested On Users” von Ida Aalen nachlesen.

Über Mimi Scheibe

Miriam „Mimi“ Scheibe ist selbständige UX Coach & Facilitator und eine der beiden Chapter Leads von Ladies that UX Hamburg. Mit ihren über zwei Jahrzehnten Erfahrung in der digitalen Branche auf dem Buckel bietet sie heute 1:1- und Gruppen-Coachings für Einzelpersonen sowie praxisnahe Trainings und Workshops für Unternehmen im Bereich UX an. In ihrer Arbeit legt sie Wert auf ein wertschätzendes und unterstützendes Umfeld, das Raum für persönliches Wachstum und Entwicklung bietet, fernab von Druck und Zwang.

10 Kommentare

  1. Atanas

    Hey Miriam, vielen Dank fürs Sharen Deiner Erfahrung! Paar Fragen:
    1/ wie viele Testuser hattet Ihr pro Test? Du schreibst von 6 bei dem einen Test…
    2/ waren das immer dieselben Kunden?
    3/ nach welchem Prinzip habt Ihr die Testuser ausgewählt?
    4/ habe Ihr denen die gesamte App zum Testen gegeben oder nur spezifische Interaktionen?
    5/ habt Ihr mit click-baren Mockups/Designs gearbeitet oder mit fertig programmierter App? Die Frage ist bezogen auf die negative Folge, dass sich das Team nur auf die Tests und nicht auf die Stories fokussiert.

    Freue mich auf Dein Feedback!

    Vielen Dank


  2. Miriam Scheibe Artikelautor

    Hallo Atanas,

    vielen Dank für Dein Feedback :)
    Zu Deinen Fragen: wir hatten jeweils sechs Testpersonen und zwar immer neue. Es handelte sich dabei auch nicht um Bestandskunden. Wir haben Sie aus unserer Wunschzielgruppe für das neue Produkt rekrutiert. Es ist schwierig hierauf näher einzugehen, ohne das Produkt zu nennen oder den Rahmen zu sprengen.
    Die Testuser haben dann jeweils Aufgaben bekommen mit denen sie einmal den Hauptflow durch die App durchgespielt haben (Ist ja wie gesagt ein One-Trick-Pony) und der Testleitfaden war im großen und ganzen bei allen Tests gleich.
    Wir haben auf der richtigen, vom Entwickler programmierten App getestet. Das ist sicherlich der Hauptgrund für die erwähnten Einwände. Wir hatten aber natürlich Gründe dafür es so zu machen. Unter anderem z.B., nicht noch extra Aufwand in einen z.B. Axure-Prototypen zu stecken.

    Beantwortet das Deine Fragen?
    LG
    Mimi


  3. Wolf Brüning

    Wäre ein Axure-Prototyp wirklich Mehraufwand? Wenn im Test herauskommt, dass das Konzept eine Niete ist, hat man die Erkenntnis mit einem Axure-Prototypen deutlich günstiger gewonnen als mit dem programmierten Produkt…

    Andererseits lässt sich mit einem Axure-Prototypen nie eine freie Nutzung testen. Das ist natürlich ein Nachteil.


  4. Miriam Scheibe Artikelautor

    Zugegeben: in diesem speziellen Fall war es so, dass es schon den vom Entwickler programmierten Prototypen in einer LoFi-Version gab, als ich in das Team kam. Die Entscheidung, ihn zu verwenden und daran weiterzuarbeiten war schon gefallen. Ein gewisser, sehr entscheidender Teil der App wäre in Auxre sehr schwer abzubilden gewesen, ohne dem Ganzen das ‘Freie’ zu nehmen (hatte ich tatsächlich für einen zwischengeschobenen Remote-Test gemacht).


  5. Atanas Zaprianov

    Hi Miriam,

    herzlichen Dank für die schnelle & ausführliche Antwort!

    Ich hätte, wie Wolf, eher für ein klickbares Prototyp genommen. Muss nicht unbedingt Axure sein :D Aber man kennt ja die Path Dependancies in manchen Teams.

    Eine weitere Frage:
    1/ Wieso 6 Kunden?
    2/ Hattet Ihr sie gleichzeitig in einem Raum? Oder haben sie die Tests alleine gemacht? Wie ist Deine Erfahrung hierzu grundsätzlich?
    3/ Wie habt Ihr deren Feedback aufgenommen?

    Es geht ein bisschen mehr ins Detail. Ich will jedoch meine Vorgehensweise überprüfen … Ich hoffe, dass dies ok für Dich ist!

    Herzliche Grüße
    atanas


  6. Miriam Scheibe Artikelautor

    Hi Atanas,

    aus meiner Sicht ist es sehr wichtig, bei jedem Projekt genau abzuwägen, wie man den Testgegenstand aufbaut. Das hängt z.B. davon ab wie weit das Projekt fortgeschritten ist, was genau man herausfinden möchte und von noch einigen weiteren Faktoren. Jenachdem eignet sich vielleich ein Papierprototyp, ein auf MockUps basierender Klickdummy, ein Axure-Prototyp oder etwas richtig programmiertes.

    Wir haben klassische Usability Studien im UX Labor durchgeführt. Auf der Website der Nielsen Norman Group findest du sehr viele hilfreiche Artikel zu dem Thema. Z.B. auch darüber wie viele Testpersonen man auswählen sollte und warum.
    In so einem Nutzertest werden die Teilnehmer alle nacheinander eingeladen. Unsere ersten Tests dauerten eine halbe Stunde, später haben wir auf eine dreiviertel Stunde erhöht. Die Teilnehmer wurden in einem speziell ausgestatteten Raum von einem Moderator interviewt, der von einem Beobachter unterstütz wurde. Zudem wurden die Sitzungen mit einer speziellen Software auf Video aufgezeichnet und in einen weiteren Beobachtungsraum übertragen.
    Alle Beobachter machen sich wärend des Tests Notizen, die wir dann gemeinsam nach allen Sitzungen ausgewertet haben.

    Mit z.B. Fokusgruppen, bei denen man mehrere Teilnehmer gleichzeitig in einem Raum hat, habe ich noch keine Erfahrungen. Meiner Meinung nach eignen sie sich aber nicht, um die Benutzbarkeit von Produkten zu überprüfen. Aber auch hierzu habe ich einen interessanten Artikel bei der Nielsen Norman Group gefunden.

    Hilft dir das weiter?
    LG
    Mimi


  7. Wolf Brüning

    Was die Anzahl der Testpersonen angeht, gibt es die Daumenregel, dass 4-5 Testpersonen ausreichen, um nahezu alle Probleme eines Interfaces aufzudecken. Mit 6 Testpersonen ist man also sehr gut unterwegs. Wir bei OTTO machen unsere Nutzertests regulär mit 8 Personen, so lassen sich auch unterschiedliche Varianten oder ein und dieselbe Variante auf unterschiedlichen Devices sehr gut testen.


  8. Atanas Zaprianov

    Hi Miriam,

    herzlichen Dank für Deine Antwort!

    Beste Grüße
    atanas


  9. Thorsten Wilhelm

    Spannend.
    2-3 ergänzende Gedanken noch:
    Ich denke es ist durchaus hilfreich sich von dem Versuch zu lösen Iterationen klar abzugrenzen und auf einen Anzahl x festzulegen. Besser ist es, wenn ein Prototyp fortlaufend angepasst wird – wenn ein Problem erkannt ist, Lösungen da sind, die dann umgesetzt werden – und dann schnell getestet wird. So kann die Problemlösung – oft auch eine “Kleinigkeit” – wirklich evaluiert werden. Ich beobachte oft, dass zwischen Testschleifen viel zu viel angepasst wird. Wie will man dann die einzelnen Anpassung bewerten? Das geht meist nicht und ist damit auch nicht effektiv (siehe dazu auch unter dem Stichwort: RITE Methode).
    Bei der Anzahl an nötigen Testpersonen sollten ggf. vorhandenen Personas, Nutzertypen und Segmente beachtet werden. 5-8, das reicht sicher nicht, wenn die Zielgruppe breit definiert ist. Ein guter Artikel dazu sei noch erwähnt:
    http://www.eresult.de/ux-wissen/forschungsbeitraege/einzelansicht/news/stichprobengroesse-bei-usability-tests-im-labor-wie-viele-testpersonen-sind-wirklich-noetig/



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →