Im heutigen Experience Campfire haben wir gemeinsam mit Frederik Bader über Research Repositories gesprochen. Dabei ging es weniger um die konkreten Tools, sondern vielmehr darum, was Research Repositories leisten sollen und worauf man bei der Einführung achten sollte.
Frederik leitet als UXR-Manager den Bereich UX-Research bei Heidelberg Materials, einem der größten Baustoffunternehmen der Welt. Er hat mit operativem UX-Research begonnen und sich später vollumfänglich mit der Etablierung von UX-Research in Unternehmen beschäftigt. Nebenbei ist er Board Member der globalen ResearchOps Community mit über 17.000 Mitgliedern.
Research Repositories sind der Ort, an dem Research stirbt.
Frederik Bader
Mit diesem prägnanten Satz eröffnete Frederik das Campfire. Ein Research Repository kann der Ort sein, an dem das Wissen über Kund:innen und Anwender:innen den Mitarbeiter:innen im Unternehmen zugänglich gemacht wird. Es sind Orte, an denen das Wissen über Kund:innen und Anwender:innen gesammelt wird. Dabei sollte es sich nicht nur auf Erkenntnisse aus der UX-Forschung beschränken. Research Repositories können auch Erkenntnisse beispielsweise aus dem Kundenkontakt im Call Center oder aus Marktbeobachtungsstudien enthalten. Sie sollten alles umfassen, was den Mitarbeitenden hilft, ihre Kund:innen und Anwender:innen besser zu verstehen.
Damit das gut gelingt und die Erkenntnisse zum Leben erweckt werden, ist die Datenqualität von entscheidender Bedeutung. Idealerweise beinhalten Research Repositories kleinteilige und zusammenhängende Erkenntnisse. Mit der Zeit sammelt sich so ein Wissensschatz an, der dabei helfen kann, Fragen zu Kund:innen und Anwender:innen aktuell und auf Basis der Erkenntnisse der zurückliegenden Jahre zu beantworten.
Eine hohe Datenqualität bedeutet aber auch, dass die Analysephase in Research-Projekten deutlich aufwändiger wird. Die Fakten und Insights müssen in eine sinnvolle und zielführende Struktur bzw. Taxonomie eingefügt werden. Ein Ansatz dafür ist „Atomic UX Research“. Dieser unterscheidet zwischen Facts, Findings und Insights. Facts können beispielsweise Zitate oder Beobachtungen sein. Findings sind Thesen und Annahmen, die durch die durch Facts gestützt werden. Insight beschreiben, was dies für das Unternehmen bedeutet und welche Handlungsempfehlungen sich daraus ergeben.
Die Strukturierung der Daten in Research Repositories sollte von Anfang an klar definiert und erläutert werden. Die zielgerichtete Dokumentation von Erkenntnissen in solchen Systemen ist Übungssache. Frederik hat gute Erfahrungen mit Kuratierungssessions gemacht. In diesen Sessions werden neue Einträge auf Basis der angestrebten Struktur und durch das UXR-Team begutachtet. Es wird geprüft, in welcher Form Erkenntnisse wertvoll dokumentiert und selbsterklärend dokumentiert werden.
Wenn man ein Research Repository einführen möchte, sollte man sich zunächst fragen, was der konkrete Bedarf ist und welche Anforderungen das Tool erfüllen soll. Im Kern geht es dabei um die Frage, was gebraucht wird, damit die Mitarbeiter:innen mehr und einfacher Wissen über Kund:innen und Anwender:innen nutzen können. Es ist sinnvoll, sich die Prozesse rund um diese Frage anzuschauen. Die Schmerzpunkte oder Brüche, die man dabei findet, sind wichtige Auswahlkriterien für ein Research Repository.
Es ist gut, klein anzufangen und Schritt für Schritt zu lernen, was man wirklich braucht. Die meisten Research Repository-Tools können sehr viel, was am Ende nicht immer benötigt wird. Frederik rät, mit den Bedürfnissen der UX-Researcher:innen zu beginnen und zu ergründen, was diese als Anwender:innen des Tools benötigen bzw. wie sie arbeiten. Dies ist die Grundlage für den Aufbau der Struktur bzw. Taxonomie. Auch hier gilt: Lieber mit weniger anfangen und später erweitern. Bei der Strukturierung sollte gut überlegt werden, wie viele verbindliche Regeln es für die Dokumentation geben soll. Zu viele Regeln können die Motivation der Kolleg:innen schnell in den Keller drücken. Zu wenige Regeln können schnell in Chaos und mangelndem Nutzen enden.
Man sollte sich von Anfang an darüber im Klaren sein, dass der Nutzen eines Research Repositories nur mit erheblichem Aufwand für Aufbau und Pflege erreicht werden kann. Zudem stiftet ein Research Repository in der Regel erst nach 1-2 Jahren einen nennenswerten Nutzen für die Stakeholder im Unternehmen, wenn genügend Daten enthalten sind. Deshalb ist es sinnvoll, die Nutzung des Research Repository erst später auf andere Stakeholder wie Product Owner:innen oder Anforderungsmanager:innen auszuweiten.
Der Aufbau eines Research Repository erfordert viel Wissen über die internen Prozesse. Für eine erfolgreiche Einführung ist ein gutes Verständnis der internen Abläufe erforderlich. Externe Unterstützung kann hilfreich sein. Da es aber einige Zeit dauert, bis der Nutzen spürbar wird, ist sie nur sinnvoll, wenn sie langfristig zur Verfügung steht und über das notwendige interne Wissen verfügt.
Der Aufbau eines Research Repository bedeutet nicht immer, dass ein dediziertes Tool benötigt wird. Wissensmanagement- oder Notiz-Tools können manchmal sogar besser geeignet sein, weil sie gerade die Freiheit bieten, die man braucht, um das Wissen effektiv an die Mitarbeiter:innen zu vermitteln. Wichtiger als das Tool sind der Research-Prozess und die Struktur, die Erkenntnisse für die Wissensvermittlung im Unternehmen haben müssen. Bei der Tool-Auswahl trennt sich die Spreu vom Weizen mit den Suchfähigkeiten. Die Suchfunktion ist für den Erfolg essentiell. Es muss darauf geachtet werden, dass die Suche auch die vorhandenen Dokumente durchsuchen kann. Außerdem ist eine gute Verschlagwortung (Tagging) wichtig.
Eine wesentliche Frage der Diskussion war, wie man die Kolleg:innen aus den Entwicklungsteams dazu bringen kann, ein Research Repository eigenständig zu nutzen. Dazu muss das Research Repository zunächst intern frei zugänglich sein. Mitarbeiter:innen, die Wissen über Anwender:innen und Kund:innen benötigen, sollten Zugang haben.
Frederik hat die Erfahrung gemacht, dass die eigenständige Nutzung vom UX-Reifegrad des Unternehmens und des Teams abhängt. In einem Unternehmen mit einem geringen UX-Reifegrad werden Product Owner:innen vermutlich eher ihre UXler:innen fragen, als selbst in einem System nach Erkenntnissen zu suchen. In diesen Unternehmen bieten Research Repositories vor allem eine Effizienzsteigerung für UX-Researcher:innen.
Damit sich die Nutzung verbreiten kann, sollte man die Frage beantworten, was es den Kolleg:innen aus den Entwicklungsteams bringt, wenn sie das Research Repository nutzen. Wenn es für diese Kolleg:innen keinen Nutzen hat, braucht man auch keine Werbekampagne aufzusetzen, um die Nutzung zu fördern. Um mögliche Mehrwerte und Nutzen zu identifizieren, ist es hilfreich, intern UX-Research bei den Kolleg:innen zu betreiben. Die Zusammenarbeit mit ScrumMastern oder Führungskräften mit Prozessfokus kann hierbei hilfreich sein.
Ein Research Repository sollte nicht als einzige Schnittstelle zwischen Entwicklung und UX-Research verstanden werden. Es ist kein gutes Kommunikationsmedium. Am wichtigsten ist nach wie vor die direkte Kommunikation aller Beteiligten über Erkenntnisse aus dem UX-Research. Das schafft Empathie und Interesse.
Einige Research Repositories bieten Funktionen zur Datenanalyse an. Aber nur wenige sind heute dafür richtig geeignet. Die Verdichtung und Bewertung von Einzelergebnissen zu einem Gesamtbild erfordert viel Wissen und Erfahrung, über die solche Werkzeuge nicht verfügen. Künstliche Intelligenz könnte dies in Zukunft ändern. Wenn solche Tools in der Lage sind, Fakten und Erkenntnisse über Anwender:innen und Kund:innen zusammenzufassen und Fragen eigenständig zu beantworten, ohne dabei zu halluzinieren, würde das die Effizienz des Research-Prozesses deutlich erhöhen.
Zum Abschluss habe ich Frederik gefragt: “Was würdest Du den UXler:innen mit auf den Weg geben, die heute über die Einführung eines Research Repositories nachdenken?”
Seine Antwort: Das Thema ist aktuell wirklich trendy. Frag Dich aber zuerst, ob Du es wirklich brauchst und was Du Dir davon erwartest. Oft wird ein Research Repository mit hohen Erwartungen verknüpft. Du solltest Dir bewusst sein, dass das dann auch sehr viel Arbeit bei den UX-Researcher:innen erzeugt. Das bindet zu Beginn viel Kapazität. Es ist sinnvoll sowas zu haben. Aber es dauert und ist aufwändig.
Vielen Dank, Frederik, dass Du Deine Erkenntnisse geteilt und uns inspiriert hast. Vielen Dank an alle Teilnehmenden für die spannende Diskussion. Und ein dickes Dankeschön an unsere Sponsoren cxomni, Ergosign und UX&I für die Unterstützung.
Siehe auch
• Research repository: How to fail (a guide)
• Glean.ly – Knowledge repository
