Tanja Yeh
Zurück zu allen Projekten

User Research Developer Experience Mixed Methods Interview Analysis & Synthesis


Developer Experience Research


Kunde: ANWB (Abk. für Algemene Nederlandse Wielrijdersbond)



🎯 Problem


ANWB ist ein niederländischer Verkehrsbund (ähnlich wie ADAC in Deutschland). Um ihre Produkte rund um Pannenhilfe, Versicherungen und anderen Mobilitätsservices optimal anzubieten, wollen sie im IT-Bereich für ihre Engineers und Developers die bestmögliche Umgebung gewährleisten. Daher waren sie an deren Developer Experience (DX) interessiert: Was sind ihre Pain Points und Needs? Was brauchen sie, um produktiv ihre Arbeit verrichten zu können? Thoughtworks wurde beauftragt, eine Developer Experience Research durchzuführen, mit dem Ziel, eine Datenlage über den Status Quo der DX bei ANWB zu erhalten, sowie abgeleitete Handlungsempfehlungen auszusprechen.


👩🏻‍💻 Rolle


Das Team bestand aus einem DX-Experten (beratend am Anfang), einem Product Manager, einem Technical Lead für technische Fragen, sowie zwei Experience Designern (inkl. mir). Auf Kundenseite waren zwei Stakeholder involviert, aus dem DevOps-Team und dem DX Tribe.

Meine Verantwortung: Planung und Durchführung von Interviews, Erfassen und Taggen der Transkription, Clustern der Insights, Planung der Umfrage, Synthese und Bewertung der Erkenntnisse, Kreation des Reports; alles in Kollaboration mit dem Team.


⚡ Prozess


Am Anfang führten wir mehrere Workshops mit dem Kunden durch, die folgende Aspekte beinhalteten: Erarbeiten von übergeordneten Visionen und Business Goals, Definition von Fokusthemen und dem geeigneten “Flight Level” (gesamtorganisatorisches Level Domain-Ebene Produktebene), Erfassen des Umfangs (was gehört dazu, was liegt darüber hinaus?), Ermitteln der zu befragenden Rollen, etc.

Weitere Aktivitäten bestanden aus:
  1. Erstellung eines semi-strukturierten Interviewleitfadens
  2. Durchführung und Transkription der Interviews
  3. Tagging in Dovetail
  4. Clustern und Ableitung von Themen
  5. Bildung von Hypothesen, Erstellung der Umfrage
  6. Analyse der Umfrage
  7. Erstellung eines umfassenden Issue Trees
  8. Workshops zu Handlungen und Roadmap

Mit diesem Prozess folgten wir einem Mixed-Methods-Approach, bei dem wir erste Erkenntnisse in qualitativen Interviews erlangten und daraus Hypothesen erstellten, um diese dann in Form einer mehr quantitativen Umfrage zu überprüfen. 


Developer Interview Skript


Erstellung des Interviewleitfadens: Unser Ziel mit dem Interviewleitfaden war es, Problemfelder zu finden, auch über die bereits vermuteten hinaus, und auch ein Verständnis zu schaffen zu dem aktuellen Status von DX in ANWB, und womit sich Developer beschäftigen. Die Fragen waren semi-strukturiert, d.h. es wurde auch Raum gelassen für Themen, die von den Interviewten hervorgebracht wurden. Das Interview startete mehr explorativ und breit gefächert, mit offenen Fragen zu allgemeiner Zufriedenheit, Problemen, aber auch Erfolgen. Dann bewegten wir uns in Fokusbereiche, die wir zuvor mit den Stakeholdern festgelegt hatten, darunter Path to Production und Ownership and Responsibilites. Dann wurden wir noch spezifischer, indem in einem Schnelldurchlauf der Impact von bestimmten DX-Faktoren (u.a. Confidence of Release, Test Efficiency, Balancing Tech Debt, etc.) auf einer Likert-Skala von 1 bis 5 bewertet wurde.

Transkription und Tagging der Interviews: Insgesamt befragten wir 28 Personen in Interviews, von denen ich über die Hälfte als Hauptinterviewer führte. Nach jeder Sitzung wurde ein Transkript des Interviews auf Dovetail automatisiert erstellt, das wir auch nochmal geprüft haben. Dann wurde das Transkript getaggt und Key Takeaways wurden zusammengefasst. Da wir ein kleines Team waren, erwies es sich als recht einfach, sich regelmäßig auf den Stand zu bringen und Wissen auszutauschen. Nach ein paar Interviews fing ich auch an, die getaggten Aussagen visuell zu clustern und Gemeinsamkeiten aufzuzeigen.  

Beispielhafte Key Takeaways zu einem Interview (in Dovetail)

Topic Mapping in Dovetail: Sortierung und Clustern von Aussagen

Hypothesenbildung und Umfrage: Sobald sich erste Problemfelder aus Interviews wiederholten, konnten wir auf Basis dessen Hypothesen bilden. Gemeinsam mit den Stakeholdern übersetzten wir diese dann in eine quantitative Umfrage, die an alle Developer in ANWB verschickt wurde. Dies hatte den Zweck, die Aussagen zu validieren und auch eine Hausnummer zur Schwere eines Problems zu erhalten. Auch ohne umfassende Einzelinterviews haben die Developer dadurch die Möglichkeit, ihre Pain Points zu kommunizieren. Die Mixed Methods stellen also verschiedene Zugangspunkte dar für ein besseres Verständnis der DX. Eine Beispielhypothese zu Verantwortungen wäre: “It is clear to me where responsibilities of my team start and end”, welche in der Umfrage auf einer nummerierten Skala von “trifft gar nicht zu” bis “trifft voll zu” bewertet werden konnte.

Erste Themencluster mit Zitaten für die Umfragevorbereitung

Hypotheses to question Mapping: In Vorbereitung für die Umfrage wurden Hypothesen zu den Themenclustern aufgestellt.

Auswertung der Umfrage und Zusammenführung der Ergebnisse: Die Umfrage wurde im Anschluss ausgewertet, hauptsächlich in Balkendiagrammen. Diese Grafiken kombiniert mit den Interviewaussagen stellten die Grundlage dar, um mögliche Lösungen zu erörtern. In anschließenden Workshops wurden diese mit den Stakeholdern diskutiert.

Issue / Solution Clusters: High-level-Sortierung nach Themen und möglichen Lösungen


🏔️ Herausforderungen


Um effizient die Interviews zu führen, ist ein gewisses technisches Verständnis notwendig. Meistens hatten wir einen Technical Lead dabei, der mit seiner Expertise helfen konnte. Trotzdem war es in manchen Fällen – vor allem als nicht-technischer Designer – komplizierter, das Ausmaß von Problemen zu verstehen, eben aufgrund von technischer Komplexität; z.B. mit Data Engineers, die sich um Dateninfrastruktur kümmern. 

Weiterhin ist immer die Frage, in welchem Kontext man als externes Consulting-Team in das Projekt kommt. Gibt es breite Akzeptanz für das Thema DX in der Organisation? Haben Menschen Zeit oder Interview/Survey-Fatigue? Darüber hinaus hatten wir das Gefühl, dass nicht wirklich “neue” Insights gefunden werden, sondern eher Annahmen nochmal bestätigt wurden. Es gab auf der Stakeholder-Seite bereits viele Spekulationen im Vorfeld dazu, was nicht funktionieren könnte. Wir verstanden unsere Aufgabe aber darin, eine Datengrundlage zu liefern und damit den Weg für Handlungsmaßnahmen zu bereiten.


🏆 Ergebnisse


Als finale Deliverables erstellten wir einen umfangreichen Report mit all unseren Ergebnissen und Empfehlungen, aus denen wir die wichtigsten Teile in einem finalen Showcase vor Stakeholdern präsentierten. Darin waren Übersichten über die verschiedenen Themenfeldern vorhanden, und Aspekte wurden hervorgehoben durch Zitate aus Interviews und Diagrammen aus der Umfrage. Anschließend wurden auch Lösungsschritte und Empfehlungen ausgesprochen. Für unsere Arbeit erhielten wir vom Kunden Lob, und weitere Engagements wurden nicht ausgeschlossen.




💡 Learnings


Es war interessant für mich in die Komplexität von Developer Experience einzusteigen und die vielen Facetten, die die Produktivität und das Arbeiten beeinflussen. Ebenso konnte ich meine Fähigkeiten zu User Research vertiefen, diesmal auf einer Ebene, die nicht nur auf ein digitales Produkt begrenzt ist, sondern auch gesamtorganisatorische und strukturelle Probleme beinhaltet. 

Außerdem habe ich mich sehr gefreut, mit einer anderen Designerin zu kollaborieren, uns dabei über Methodik und Prozesse auszutauschen und Aufgaben aufzuteilen. In diesem Projekt war ich eher fokussiert auf die Details, z.B. die Tags, Aussagen und Themencluster, während sie eher strategischer und übergeordneter beigetragen hat; somit ergänzten wir uns sehr.






Kontakt