Kein UX-Designer im Team? Mit diesen 3 einfachen Techniken kann dein Scrum Team noch heute mit UX-Research beginnen
Müssen Scrum Teams wirklich Schritt für Schritt alle Stadien im UX-Reifegrad-Modell durchlaufen oder gibt es auch eine Abkürzung?
Im Jahr 1939 kam der Mathematikstudent George Dantzig zu spät zur Vorlesung, was ihm zu weltweitem Ruhm verhalf.
Sein Professor Jerzy Neyman und alle Mitstudierenden waren bereits gegangen. Deshalb schrieb er von der Tafel ab, was er für Hausaufgaben hielt. Da er länger als gewöhnlich benötigte, um die Aufgaben zu lösen, entschuldigte er sich bei seinem Professor für die verspätete Abgabe. Sechs Wochen später klopfte sein Professor an seine Haustür und bat ihn, die Einleitung zu lesen, die er für seine Arbeit geschrieben hatte. Was Dantzig gelöst hatte, waren keine Hausaufgaben gewesen, sondern zwei berühmte ungelöste Statistikprobleme!
Seither fügen Professoren gerne ungelöste Probleme zu Aufnahmetests hinzu, um zu sehen, ob ein brillanter junger Student, der noch nichts von dem ungelösten Problem gehört hat, eine Lösung findet, an die niemand sonst gedacht hat.
Die Abkürzung besteht darin, nicht zu warten.
George Dantzigs Geschichte soll dich und dein Team ermutigen, nicht zu warten, bis ihr Hilfe von einem UX-Experten bekommt, sondern mit den Mitteln zu starten, die euch jetzt zur Verfügung stehen. Mit einem UX-Experten im Team wäre natürlich alles einfacher, allerdings sollte euch das nicht aufhalten, denn häufig reichen nur 20 % Fachwissen aus, um 80 % der möglichen Resultate zu erzielen.
Im Folgenden findest du drei Techniken, welche einen Großteil dieser 20 % bereits ausmachen. Alle drei Techniken vereint eines: Sie sind einfach. So kannst du sie mit deinem Team sofort anwenden und noch heute mit der Produktentdeckung starten.
Die Erkenntnisse, die ihr mit diesen Research-Techniken über eure Nutzer erhaltet, werden dir und deinem Team bei folgenden Aufgaben helfen:
- User Storys schreiben, die wirklich auf wahren „Geschichten“ eurer Nutzer basieren.
- Endlose Diskussionen im Sprint-Review mit den Stakeholdern abkürzen. Jetzt könnt ihr objektiv begründen, warum das Feature so designt wurde, da nur so die Nutzer bei ihrer täglichen Arbeit entlastet werden.
- Im Product Backlog für mehr Übersichtlichkeit sorgen, da ihr die Einträge nach Nutzergruppen bündeln könnt.
Technik #1: Interviews mit Nutzern
Interviews sind keine offenen Gespräche, sie bedürfen einer gründlichen Vorbereitung.
Wenn ich UX-Experten beim Interview beobachte, dann sieht es mühelos aus. Die Abfolge von Fragen und Antworten gleicht fast einem Gespräch. Allerdings sollten wir uns hier nicht täuschen lassen, denn es braucht Jahre, um die Fähigkeit zu erlangen, Interviews ohne sichtbare Vorbereitung durchzuführen. Für alle anderen gilt deshalb: Wenn wir Interviews durchführen, müssen wir uns gut vorbereiten.
Als Erstes sollten wir deshalb den Rahmen für die Befragung definieren.
Wer soll befragt werden? Zu welcher Fragestellung oder welchem Thema wollen wir diese Person interviewen? Wer stellt die Fragen und wer protokolliert die Antworten? Wie halten wir die Fragen und Antworten fest? Wenn der grobe Rahmen steht, können wir einen Leitfaden mit den wichtigsten Fragen erstellen.
Hier eine Liste von Fragen, um das Interview zu strukturieren:
Es gibt verschiedene Fragen, um das Interview zu beginnen, die Aufgabe zu verstehen, die Aufgabe zu absolvieren und Verbesserungspotenziale in Erfahrung zu bringen:
- Können Sie mir beschreiben, wie Sie .../Ihre Erfahrungen mit ...?
- Können Sie beschreiben, wie Sie [Aufgabe] …?
- Sequenz: Führen Sie mich durch [Aufgabe] – wie würden Sie vorgehen?
- Vergleich: Was ist der Unterschied zwischen [Aufgabe 1] und [andere Aufgabe]?
- Nehmen wir an, ich bin ein Kollege, der keine Ahnung davon hat. Können Sie mich anleiten, damit ich es nachher selbst machen kann?
- Können Sie sich an eine Situation erinnern, in der Sie ..., was haben Sie getan?
- Was glauben Sie, wie wird Ihnen ... helfen?
- Könnten Sie das ideale Produkt/die ideale Erfahrung beschreiben ...?
- Was gefällt oder missfällt Ihnen an ...?
- Wie wirkt sich dieses Problem auf Sie aus?
- Wie haben Sie dieses Problem gelöst?
- Was ist das Schwierigste/Frustrierendste an ...?
Diese Vorbereitung ermöglicht es uns, im Interview auch von den vorbereiteten Themen abzuweichen und aufkommende Fragen oder Probleme zu ergründen. Wenn dies geschieht, dann fühlt es sich mehr wie ein Gespräch und weniger wie ein strukturiertes Interview an.
Ich bezeichne deshalb diese Art des Interviews als ein halbstrukturiertes Interview.
Technik #2: Nutzer-Beobachtungen
Die Entwicklung erfolgreicher Features beginnt nicht im Büro, sondern vor Ort beim Nutzer.
Wirklich erfolgreiche Features lösen wahre Probleme von Kunden. Wir müssen den ganzen Kontext, in dem er arbeitet oder lebt, miteinbeziehen. Und dieses Verstehen beginnt damit, die Nutzer bei der Lösung ihres Problems in ihrer gewohnten Umgebung zu beobachten. Wie verwenden sie das Produkt? Was ist ihr Ziel dabei? Was hält sie von der Erreichung ihres Ziels ab? Welchen Ablenkungen und Störfaktoren sind sie ausgesetzt?
All diese Fragen könnten ohne Nutzer-Beobachtung nur schwer beantwortet werden.
Eine Warnung vorweg: Die häufigste Fehlerquelle bei der Nutzer-Beobachtung ist, dass wir nicht beobachten, sondern den Nutzer eine vorgegebene Aufgabe absolvieren lassen, wie es etwa in einem Usability-Test der Fall ist. Es geht aber ausschließlich darum, zu sehen, wie die Nutzer ihre Arbeit wirklich erledigen.
Da Vor-Ort-Besuche aktuell wohl für die wenigsten Teams möglich sind, hier noch einige Tipps, wie Nutzer-Beobachtungen auch virtuell erfolgreich sind:
- Der Nutzer sollte euch vorab Bilder von seiner Umgebung zusenden. So bekommt ihr einen Eindruck von der Umgebung, in der sich der Nutzer befindet, welche ihr im Video-Call nicht sehen könnt.
- Informiert den Nutzer darüber, wie ihr die Beobachtung aufzeichnet und wer Zugriff auf die Daten erhält.
- Plant am Anfang der Sitzung Zeit ein, um eventuelle Technikprobleme gemeinsam zu lösen.
- Der Nutzer sollte sowohl mit dem Computer als auch mit seinem Smartphone am Video-Call teilnehmen. Mittels der Kamera am Smartphone habt ihr nun die Möglichkeit, ihn bei der Arbeit zu beobachten.
- Stellt bei der Beobachtung eure eigene Kamera aus. So ist der Nutzer nicht durch eure Anwesenheit abgelenkt.
Zum Schluss noch ein Geheimtipp, welcher unter erfahrenen UX-Experten sehr kontrovers diskutiert wird, da wir hier von der klassischen Nutzer-Beobachtung erheblich abweichen:
- Haltet den Nutzer dazu an, laut zu denken.
- Und fragt zur Not nach, wenn euch etwas entgangen ist.
Natürlich ist das Wichtigste, genau zu beobachten. Allerdings können euch bei einer virtuellen Nutzer-Beobachtung leicht Dinge entgehen. Bevor ihr diese verpasst, nehmt lieber in Kauf, dass ihr den Nutzer in seinem Arbeitsfluss unterbrecht, und fragt nach, ob er die Aktion wiederholen kann.
Technik #3: Proto-Persona-Workshop
Proto-Personas bilden ab, wie wir uns unsere Nutzer vorstellen.
Wir sollten Proto-Personas als die aktuell beste Vermutung darüber verstehen, wer das Produkt nutzt oder nutzen wird und wozu. Im Gegensatz zur Standard-Persona basieren Proto-Personas auf unseren Annahmen und werden anhand tatsächlicher Daten überprüft. Sie stellen eine Sammlung unserer Interviewauswertungen, Nutzer-Beobachtungen, Heuristiken, Marktforschung, aber auch Intuition dar. Damit ermöglichen sie unserer Zielgruppe, ihre Bedürfnisse und Verhaltensweisen zu artikulieren.
Damit helfen sie dir und deinem Team ein gleiches Verständnis über unsere Nutzer und Kunden bei Stakeholdern herzustellen.
Proto-Personas lassen sich am besten in einem Workshop mit dem ganzen Scrum Team und den Stakeholdern, die die Nutzer kennen, erstellen. Zum Beispiel als Teil des Product Backlog Refinement.
Einen solchen Workshop kannst du ganz einfach in drei Schritten durchführen. Jeder der einzelnen Schritte sollte mit einer Brainstorming-Phase eingeleitet werden und erst dann sollten die Ergebnisse zusammengetragen und gebündelt werden.
Schritt 1: Nutzer identifizieren
Beantwortet zuerst die Fragen:
- Wer verwendet unser Produkt?
- Welche Arten oder Typen von Menschen sind das?
- Wie verwenden diese Personen das Produkt?
Schritt 2: Merkmale der Nutzer ermitteln
Nun identifiziert die gemeinsamen Merkmale dieser Personen. Wie sollten wir diese Menschen in Gruppen einteilen? Wodurch unterscheiden sie sich von den anderen?
Es hat sich bewährt, die Nutzer nach folgenden Merkmalen einzuteilen:
- Demografische Merkmale (Alter, Geschlecht, Rolle)
- Verhaltensinformationen, die sich auf die Art und Weise auswirken, wie sie das Produkt verwenden
- Bedürfnisse, Wünsche und Ziele, die mit dem Verwenden des Produkts befriedigt werden sollen
- Schmerzpunkte, die bei der Verwendung des Produkts auftreten
Schritt 3: Personifizierung der Personengruppen
Zum Schluss solltet ihr jede Persona-Gruppe zu einem konkreten, greifbaren Beispiel zusammenfassen. Dies umfasst auch einen Namen und ein Profilbild.
Hier ein Beispiel einer fertigen Proto-Persona, wie sie die Teilnehmenden in meinem Professional Scrum mit UX-Training erstellt haben.
Dir hat dieser Beitrag gefallen, aber beim Lesen haben sich noch viele weitere Fragen ergeben, wie Scrum und UX vereint werden kann? Dann melde zur „Ask a PST German Edition“ an. Dort beantworten Boris und ich dir all deine Fragen. Die Fragestunde beginnt um 17:00.
Interessiert? Großartig! Dann vergiss nicht dich anzumelden.