Inhaltsverzeichnis
1. Produktentwicklung mit User Research nach Scrum
1.1 Von Wayfinder über Product Researcher zum Product Owner
1.2 Befähigung von anderen Teams
2. Einstieg in den Forschungsbetrieb (Research Ops)
2.1 Discovery-Forschung und Usability Testing
2.2 Nutzung verschiedener Ressourcen
2.3 Präsentation der Studienerkenntnisse
3. Passende und unvoreingenommene Testpersonen
3.1 Herausforderung: No-Shows und Misfits
3.2 Lösung: Unkomplizierte Rekrutierung
3.3 Transparente Kommunikation und stetige Weiterentwicklung
4. Ausschnitte des Interviews als Video
1. Produktentwicklung mit User Research nach Scrum
sipgate hat seinen Sitz in Düsseldorf, wo mittlerweile 250 Mitarbeitende beschäftigt sind. Diese entwickeln innovative Festnetz- und Mobilfunkprodukte für Unternehmen und Privatpersonen. Dabei bauen sie die Schnittstellen zwischen Internet und Telefonie.
Bei der Produktentwicklung wird nach dem Scrum-Prinzip in 2-Wochen-Sprints gearbeitet. Das Scrum-Team besteht immer aus einem Product Owner, einem Scrum-Master und einem Entwicklungsteam (Dev-Team). In Davids Fall besteht das Dev-Team aus vier Researcherinnen und David selbst ist Product Owner des Research-Teams. Als solcher hat er die Hauptverantwortung der Forschungsarbeiten des Teams. Er ist derjenige, der entscheidet, welche Fragen beantwortet werden und verantwortet das Backlog-Refinement.
Zu Beginn jedes Sprints setzen sie sich alle gemeinsam hin und planen diesen (Planning). Dabei versucht das Team so viele Aufgaben zu ziehen, wie realistisch schiffbar sind. Die Researcherinnen sind für die Umsetzung verantwortlich. Sie definieren, wie sie die Fragestellungen beantworten wollen und welches die sinnvollsten Methoden zur Beantwortung dieser sind. Am Ende jedes Sprints gibt es eine Sprint-Review und eine Retrospektive darauf. Darin diskutieren sie, wie es gelaufen ist und was sie beim nächsten mal anders machen wollen.
1.1 Von Wayfinder über Product Researcher zum Product Owner
Gestartet hat David als Wayfinder bei sipgate. Wie der Jobtitel es schon vermuten lässt, musste er seinen Weg bei sipgate noch finden – ganz ergebnisoffen. Zuvor hat er sich an der Universität intensiv mit Design Thinking auseinandergesetzt und Kommunikationswissenschaft studiert. Die ganzen Methoden, die ein Researcher beherrschen muss, waren ihm daher aus einer akademischen Perspektive bestens bekannt. Zusätzlich zum Studium hatte er bereits Start-up-Erfahrung im digitalen Produktbereich gesammelt.
Zu sipgate ist er gestossen, da er sowie das Unternehmen fanden, dass sie zueinander passen. Lediglich die perfekte Rolle musste noch gefunden werden. Diese hatte sich im Wayfinder-Programm innerhalb eines Jahres herauskristallisiert. Bei diesem Programm finden beide Seiten, Arbeitnehmer und der Arbeitgeber, innerhalb eines Jahres heraus, welcher Job am meisten Sinn macht. Bei David war er schlussendlich die neu geschaffene Researcher-Rolle.
Im Anschluss an das Programm war David ein halbes Jahr als Product Researcher in verschiedenen Teams tätig. Später wurden vier weitere Leute eingestellt und heute sind sie als ein eigenständiges Research-Team unterwegs.
1.2 Befähigung von anderen Teams
Von den 250 Leuten, die bei sipgate arbeiten, sind ca. 20 bis 25 Personen als UX Designer angestellt und fünf davon sind Researcher. Wenn man das mit anderen Unternehmen vergleicht, ist das verhältnismässig sehr viel.
Doch bei sipgate sind sehr viele Abteilungen und Rollen an der Nutzerforschung interessiert. Vor allem die Designer, welche regelmässig Usability Tests durchführen. Oder auch Product Owner, die die Nutzung ihrer Produkte besser verstehen und neueste Entwicklungen testen möchten. Sie alle kommen mit diversen Fragen auf das UX-Research-Team zu. Dieses muss dann abwägen, was sie selbst durchführen können und wo sie die anderen Kolleginnen und Kollegen allenfalls befähigen müssen, selbst Forschung zu betreiben. Sie unterstützen sie dann darin, die richtige Methode zu wählen, geben Inputs zu Fragestellungen und mehr.
2. Einstieg in den Forschungsbetrieb (Research Ops)
Bevor David bei sipgate gestartet hat, wurde teilweise schon Forschung betrieben. Jedoch war die Praxis damals sehr unstrukturiert. Mit Davids Rolle als UX Researcher kam definitiv mehr Methodik in das Unternehmen. Davor gab es keine dedizierten Personen, die den Bereich UX Research verantworteten. Am ehesten waren es noch die UX Designer, die sich für diesen Bereich verantwortlich gefühlt haben. Diese mussten sich aber zugleich auf das Designen der Produkte fokussieren und konnten sich nicht noch um das Operationalisieren der Research-Arbeiten kümmern.
Davids erste Aufgaben war daher klar: Strategien definieren, Strukturen und Prozesse aufbauen, die richtigen Tools auswählen. Halt alles was zu Research Ops gehört und was erforderlich ist, um Forscher bei der Bereitstellung und Skalierung in einer Organisation zu unterstützen. Wenn man diese Basis nicht hat, ist es schwierig gute Forschung zu betreiben.
2.1 Discovery-Forschung und Usability Testing
Das Research-Team betreibt bei grösseren Fragestellungen zwei bis drei Monate explorative Forschung. Explorative Forschung dient zur Untersuchung eines nicht klar definierten Problems. Bei einer solchen Forschung beginnt das Team mit einer allgemeinen Idee und identifiziert Themen, die den Schwerpunkt für zukünftige Forschung bilden.
Ein wichtiger Aspekt dabei ist, dass das Research-Team bereit ist, seine Richtung zu ändern, wenn neue Daten oder Erkenntnisse auftauchen. Das funktioniert bei David und seinem Team sehr gut. Sie strukturieren ihre Arbeit in einem Discovery Canvas und bearbeiten dieses, bevor es an das Produktteam für die Umsetzung geht.
Diese ganze Forschungsarbeit beinhaltet wöchentlich sechs bis sieben User-Interviews. Und das dann gerne mal vier bis fünf Wochen lang. Das ist für das Team eine sehr intensive, aber auch aufschlussreiche Zeit. Bei den User-Interviews bauen sie gerne noch einen Twist ein. Das Research-Team lässt Nutzer*innen auf einem Miro-Board Dinge anordnen, um zu sehen, wie sie sich die Struktur vorstellen. Neu möchten sie Mentimeter für eine Skalen-Abbildung nutzen.
In jedem Produktteam sind jeweils ein bis zwei UX Designer*innen dabei, die danach noch Usability Tests durchführen. Während diesem Prozess ist das Research-Team unterstützend mit dabei. Sie stellen alles Nötige zur Verfügung und sorgen dafür, dass die UX Designer*innen mit geeigneten Personen testen können. Zudem prüfen sie ab und zu, ob Usability-Aufgaben sinnvoll gestellt sind und optimieren diese, wenn nicht.
2.2 Nutzung verschiedener Ressourcen
Die Researcher bei sipgate nutzen diverse Tools und Services für ihre Nutzerforschung. Für moderierte Studien wird Lookback eingesetzt und für unmoderierte RapidUsertests. Miro kommt zum Einsatz, wenn es etwas interaktiver wird und Figma wird für Prototypen genutzt. sipgate nutzt TestingTimes Rekrutierungsplattform, um die passenden Studienteilnehmer zu finden. Bei Umfragen greifen sie auf SurveyMonkey zurück.
David und sein Team führen die meisten Aufgaben zu zweit durch. Es spielt keine Rolle, ob das die Erstellung von Interviewleitfaden, die Durchführung von Interviews oder die Studienauswertung ist. Sie sehen den grössten Vorteil darin, dass die Qualität ihrer Forschung bedeutend höher ist. Ausserdem ist es noch nie vorgekommen, dass das Research-Team nicht weiterarbeiten konnte, weil irgendwelche Informationen fehlen. Das kann sonst schnell passieren, wenn man z.B. beim Interview allein für einen kurzen Moment nicht aufmerksam war oder jemand im Urlaub ist.
2.3 Präsentation der Studienerkenntnisse
Während Sprint-Reviews hält das Research-Team Präsentationen zu den Studien-Erkenntnissen. Nach diesen wird entschieden, welches die nächsten Schritte sind. Um die Erkenntnisse zu dokumentieren, haben David und sein Team ein Research-Repository in einem Google Sheet erstellt. Das Research-Repository ist eine gemeinsame Übersicht aller vergangenen Studien mit Hinweis auf die Insights. So können alle Teams die Erkenntnisse aus der Vergangenheit gut wiederfinden.
In ihrer Sammlung beschreibt das Team die Zielgruppe, mit welcher getestet wurde. Sie fassen die drei wichtigsten Erkenntnisse zusammen. Weiter geben sie an, für welches Team diese Forschung betrieben wurde. Oftmals erstellen sie Zusammenfassungs-Videos, da diese eher angeschaut werden als ein klassischer Research Report. Darin sind auch Verlinkungen zu den weiteren Details enthalten. Aus Datenschutzgründen nehmen sie sich in der Regel selbst auf und erzählen von den Erkenntnissen anstatt die Nutzer*innen zu zeigen.
Bei TestingTime können im Bestellprozess jegliche Dokumente vor der Studienteilnahme von den Testpersonen unterzeichnet werden. Zum Beispiel eine Geheimhaltungsvereinbarung, oder eine Einwilligung zur Aufzeichnung des Tests. Wir binden das zu unterzeichnende Dokument direkt in unseren Rekrutierungsprozess ein. Jedes Dokument wird rechtskräftig unterschrieben und enthält das Datum, den vollständigen Namen der Testperson, sowie deren elektronische Unterschrift. Vor Beginn der Studie hat man Zugriff auf alle signierten Dokumente in der Auftragsübersicht.
3. Passende und unvoreingenommene Testpersonen
Früher hat man bei sipgate über Facebook sowie Familie und Freunde Studienteilnehmer rekrutiert. Zu Beginn hat das mit Ach und Krach funktioniert, aber nach einer Weile lag das nicht mehr drin. Es war zu viel Aufwand und in 2-Wochen-Sprints muss schnell rekrutiert werden können. Zudem waren die Personen selten Teil der eigentlichen Zielgruppe und voreingenommen, da es mit der Zeit immer wieder dieselben Teilnehmer waren.
3.1 Herausforderung: No-Shows und Misfits
Die grösste Herausforderung von sipgate bei der Research-Arbeit waren sogenannte “No-Shows”. D.h. Personen, die überhaupt nicht zur Studie auftauchen. Weiter waren da noch die “Misfits”, wenn das Profil nicht passte oder der/die Teilnehmer*in technische Probleme bei Online-Studien hatte. Es kam vor, dass ein Mikrofon nicht funktionierte oder der Browser nicht aktualisiert wurde. Aus diesem Grund macht sipgate vorab Technik-Checks oder stellt den Testern vorgängig Goodie-Pakete zu, damit diese sicher zum Test erscheinen.
3.2 Lösung: Unkomplizierte Rekrutierung
Bevor sipgate die Plattform von TestingTime für die Rekrutierung genutzt hat, haben sie mit einer Rekrutierungsagentur zusammengearbeitet. Leider waren sie nicht ganz so zufrieden mit dem Service und es gab oftmals ein grosses Hin und Her. Der Prozess bis zur Bestellbestätigung dauerte viel zu lange und war zu komplex. David schätzt es sehr, dass bei TestingTime viele Fragestellungen gleich über das Bestellformular abgewickelt werden. Es müssen keine unnötigen E-Mail-Runden gedreht werden bis man zu den gewünschten Testern kommt.
Einen der grossen Vorteile TestingTime zu nutzen, sieht sipgate darin, dass man Leute rekrutieren kann, die das Unternehmen noch nicht kennen. An diese Zielgruppe würden sie sonst nicht so einfach rankommen bzw. müssten viel zu viele finanzielle und personelle Ressourcen investieren wie in ihren ursprünglichen Versuchen. Vor allem wollen sie nicht selbst über Facebook & Co. rekrutieren, da sie weder gut darin sind noch gehört dies zu ihrem Kerngeschäft. David ist der Meinung, dass sie niemals mit der Erfahrung von TestingTime mithalten könnten und Einbussen bei der Qualität machen müssten.
sipgate managed trotzdem ein eigenes Testpersonen-Panel mit ca. 1000 Personen – alles sipgate Kunden. Die Personen im eigenen Panel sind Fans von sipgate und haben sich auch aus diesem Grund für das Panel gemeldet. Bei gewissen Studien kann das ein Nachteil sein und für neue Produkte macht es Sinn, auch mit potentiellen neuen Nutzer*innen zu testen. Für etwa 50% ihrer Studien nutzt sipgate daher das öffentliche Panel von TestingTime.
3.3 Transparente Kommunikation und stetige Weiterentwicklung
David schätzt bei TestingTime besonders die Transparenz. In seinem Kunden-Dashboard ist er bestens über den Status der Rekrutierung informiert. Zudem ist er als Tester bei TestingTime registriert und weiss, wie der ganze Prozess auf der anderen Seite funktioniert.
Genauso wie sipgate seine Produkte laufend weiterentwickelt, macht dies auch TestingTime. Wir führen regelmässig Nutzerforschung zu eigenen Produkten durch, um die bestmögliche User Experience zu gewährleisten. Das ist ein weiterer Punkt, den David so toll findet. Er hat kürzlich mitgekriegt, dass man neu selber Screener-Fragen erstellen kann. Dieses Produkt-Feature schätzt er sehr, denn manchmal braucht es die Telefoniemarkt-Expertise, um gewisse Screener-Fragen für die Studien zu erstellen. Er und sein Team sind froh, dass sie hier selbst übernehmen können, wenn sie wollen.
Als Tester in unserem Kunden-Pool hat er vor kurzer Zeit an einer TestingTime-Studie teilgenommen. Dabei wurde ein neues Feature getestet, von dem er sehr begeistert war und welches ihm und vielen anderen das Leben als Researcher einfacher machen wird (hier registrieren, um mehr darüber zu erfahren).
David ist neugierig und rät auch seinen UX-Kolleginnen und -Kollegen diesen Ansatz zu verfolgen. Sein Tipp ist es, täglich Research zu betreiben. Auch im privaten Leben. Sei dies bloss kurz den Uber-Fahrer zu fragen, warum er denn bei Uber registriert ist und nicht bei einem anderen Anbieter. Oder im Kino beim Popcorn-Kauf nachfragen, was denn mehr verkauft wird: süsses oder salziges Popcorn? Übung macht schlussendlich den Meister.