In 5 Schritten zum richtigen UX-Research Repository [mit Vorlage von Condens]

Ein Research Repository ist eine Wissensdatenbank, die Nutzerdaten, Erkenntnisse und Forschungsergebnisse speichert und organisiert, um Feedback umzusetzen, Teams bei der effektiven Analyse von Informationen zu unterstützen und die Zusammenarbeit zur Verbesserung des Produkterlebnisses (PX) zu fördern.

Der 5-stufige Evaluierungsprozess in diesem Artikel bietet dir eine strukturierte Vorgehensweise, um das passende digitale Tool für dein Team zu finden. Diese kostenlose Vorlage von Condens zur Dokumentation der Ziele und zur Bewertung der Tools erleichtert dir diese Aufgabe.

Wie umfangreich der Bewertungsprozess für dein Produktteam ist, hängt von der Größe deines Unternehmens und der Anzahl der beteiligten Personen ab. Bei einem Forschungsteam mit nur einer Person kann die Entscheidungsfindung an einem Tag abgeschlossen sein, in einem großen Unternehmen kann sie jedoch mehrere Wochen in Anspruch nehmen.

Fangen wir also an!

Ein Hinweis: Wir empfehlen dir, die fünf Schritte des folgenden Prozesses chronologisch zu befolgen, aber in manchen Fällen musst du auch hin- und herspringen. Wenn du z. B. während einer Demo einen interessanten Aspekt eines Repositorys entdeckst, an den du vorher nicht gedacht hast (in Schritt 4), solltest du ihn in deine Anforderungsliste aufnehmen (zurück in Schritt 2). Eine gewisse Flexibilität ist hier also hilfreich.

1. Lege Ziele fest und setze Prioritäten

Viele machen bei der Auswahl eines Research Repositorys den Fehler, direkt nach Tools zu suchen und diese zu vergleichen. Der Vergleich von Repository-Tools ist jedoch schwierig, wenn man sich nicht im Klaren darüber ist, worauf man überhaupt schauen soll.

Idealerweise legst du also stattdessen zunächst fest, was du mit dem Repository erreichen willst. Strategische Ziele sind ein wichtiger Schritt in der Produktentwicklung. Sie helfen deinem Team, die Funktionen und Vorteile eines UX-Research Repositorys zu erfassen.

Halte dann deine Ziele in einem Dokument schriftlich fest. Hier findest du eine Vorlage zur Dokumentation der Ziele und zur Bewertung der Tools mit den häufigsten Zielen für ein Repository. Kopiere die Vorlage und trage die Informationen, die du im Laufe des Prozesses sammelst, ein:

Spalten A–C: vorläufige Ziele

Ein Schlüsselelement der Vorlage ist Spalte B, in der die Ziele aufgeführt sind, denen das Repository dienen soll. Ein Ziel besteht aus: 

1. dem gewünschten Ergebnis, z. B. die Zentralisierung vorhandener Forschungsdaten;

2. dem Nutzen für das finale Ziel, z. B. um Fragen von anderen Teammitgliedern schneller zu beantworten.

Lösche einfach alle Zeile mit Zielen, die für dich nicht relevant sind, und ergänze deine eigenen Ziele.

In Spalte A steht jeweils die übergeordnete Funktion, zu der ein Ziel gehört. So weist du deine Ziele direkt bestimmten Kategorien zu und kannst sie leichter finden und nach Priorität ordnen.

Beschreibe dann in Spalte C die erwarteten Änderungen und gewünschten Ergebnisse anhand konkreter Beispiele, wobei du dich ggf. auf konkrete Funktionen oder Szenarien in deinem Unternehmen beziehen kannst. Die Vorlage enthält einige Beispiele, die du leicht an dein Produkt und deinen Markt anpassen kannst.

Spalte D: Einbeziehung von Team und Stakeholdern

Sprich als Nächstes mit den Stakeholdern, die du in Spalte D eingetragen hast, und frage sie nach ihren Pain Points, Erfahrungen und Zielen mit der UX-Forschung. Auch eine Stakeholder-Analyse könnte hilfreich sein, um die Zustimmung und Unterstützung von Führungskräften und Investor:innen sicherzustellen. Die Einbeziehung der Stakeholder hilft dir, Dinge zu erkennen, die du möglicherweise übersehen hast, und erhöht die Akzeptanz nach der Implementierung des Repositorys.

Wenn du dein Team und die Stakeholder in dieser Phase einbeziehst, sei am besten so detailgenau wie möglich. Willst du den Stakeholdern zum Beispiel die Suche nach vorhandenen Forschungsergebnissen erleichtern, frage sie, wann sie das letzte Mal versucht haben, etwas aus vorhandenen Forschungsergebnissen zu lernen und welche Forschungsmethoden sie verwendet haben. Versuche herauszufinden, was ein Repository bieten muss, damit alle Beteiligten es nutzen können, um ihre Produkt- und Geschäftsziele zu erreichen.

Passe die Tabelle kontinuierlich an und verfeinere sie entsprechend der Angaben der Stakeholder. Du kannst die Liste auch als Prioritätenliste nutzen, indem du die wichtigen Ziele ganz oben und die weniger wichtigen Ziele weiter unten aufführst.

2. Ermittle die Anforderungen deines Teams

Da du nun eine Vorstellung davon hast, was das Repository für dich tun soll und wer in den Prozess einbezogen werden sollte, ist der nächste Schritt, darüber nachzudenken, wie die Bedürfnisse des Teams erfüllt werden können. Führe eine Lückenanalyse durch, um Folgendes abzuwägen: 

1. das Repository-Tool selbst und die Funktionen, die die Software bieten muss.

2. die Änderungen der Arbeitsabläufe und Gewohnheiten der beteiligten Personen. Je größer deine Organisation, desto wichtiger wird dieser Aspekt.

Verwende in der Vorlage die Spalten E und F für die beiden verschiedenen Arten von Anforderungen:

Spalten E und F: Anforderungen ermitteln

Spalte E betrifft die Fähigkeiten des Tools selbst – welche Funktionen muss das Tool haben? Auch hier solltest du so detailliert wie möglich sein und Dinge wie die Zugriffsmöglichkeiten für die Stakeholder und eine einfache Weitergabe von Ergebnissen berücksichtigen.

Spalte F beschreibt die Änderungen im Arbeitsablauf: Was muss sich im Vergleich zum aktuellen Prozess ändern? Welche neuen Aufgaben musst du einplanen, welche Verfahren werden sich ändern und welche Aufgaben werden wegfallen? Hier ist es hilfreich, die Herausforderungen des Produktmanagements im Hinterkopf zu haben.

Die Vorlage enthält für die Spalten E und F Beispiele. Das korrekte Ausfüllen dieser Spalten – zusammen mit den Stakeholdern – ermöglicht es deinem Team, potenzielle Blocker oder Hindernisse frühzeitig zu erkennen.

3. Erstelle eine Liste mit möglichen Tools

Nachdem du nun eine gute Grundlage für die Bedürfnisse deines Teams geschaffen hast, kannst du mit der Suche nach Research Repository-Tools beginnen.

Fange am besten damit an, Listen beliebter und geprüfter Tools von Websites wie G2 durchzusehen. Diese quantitative Forschung gibt dir verschiedene Einblicke von UX-Design- und Produktteams. So kannst du eine lange Liste möglicher Tools erstellen und diese dann eingrenzen, indem du sie auf die in Spalte E aufgeführten nicht verhandelbaren oder entscheidenden Kriterien abklopfst. 

Versuche so weit auszusortieren, dass du nur noch zwei oder drei Software-as-a-Service (SaaS)-Anbieter zur Auswahl hast, und bewerte diese dann eingehender (wie du das machst, erfährst du gleich).

4. Nutze Demos und Testversionen

Mit den zwei oder drei Anbietern auf deiner Auswahlliste kannst du nun weitere Informationen sammeln. Die jeweiligen Websites und Help Center der Tools sollten einen guten Überblick darüber geben, was die Tools leisten können. Um deine Suche jedoch noch gezielter zu gestalten, setzt du dich optimalerweise mit den Sales Teams der jeweiligen Anbieter in Verbindung. Teile ihnen deine spezifischen Ziele mit, um zu erfahren, wie ihr Tool deinen Produkt- und Nutzeranforderungen gerecht wird. Führe in diesem Schritt auch Usability-Tests durch, um festzustellen, ob das Tool für dein Team geeignet ist.

Verwende Seite zwei der Vorlage zur Dokumentation der Ziele und zur Bewertung der Tools, um deine Bewertung zu strukturieren.

In der ersten Zeile wird der Name des jeweiligen Anbieters eingetragen. Dann hat die Vorlage zwei Hauptkategorien: 

1. Nutzererlebnis, bei dem bewertet wird, wie einfach und unterhaltsam das Tool zu benutzen ist

2. Funktionalität, bei der bewertet wird, ob das Tool die Funktionen bietet, die du zum Erreichen deiner Ziele benötigst

Neben den Noten (1 ist die schlechteste, 5 die beste) solltest du auch den Kommentarbereich nutzen, um die qualitativen Aspekte der einzelnen Tools zu erfassen.

Wir empfehlen dir, die Tools als Team zu bewerten, da Mitarbeiterfeedback dir hilft, eine Entscheidung zu treffen, die für alle die beste ist. Ihr könnt die Tabelle entweder gemeinsam ausfüllen, indem du in deinen Kalendern etwas Zeit für die Vorführung des Tools im Team einplanst, oder du lässt die einzelnen Teammitglieder und Stakeholder die Tools asynchron bewerten. In jedem Fall sollte jede Person ihre Eindrücke in die Bewertungsvorlage eintragen, damit du das Feedback aller Beteiligten an einem Ort hast.

Hier finden du drei weitere Kategorien zur Bewertung: 

1. Sicherheit und Datenschutz sind in der Regel eine Frage von „OK“  oder  „nicht OK“ und erfordern die Expertise deines Sicherheits- oder Rechtsteams. 

2. Support & Onboarding berücksichtigt mehrere Aspekte, wie den Umfang der Support- und Onboarding-Dienste, die in den jeweiligen Plänen enthalten sind, verfügbare Kanäle für die Kommunikation mit dem Anbieter oder auch Zeitzonenunterschiede, um eine ausreichende Überschneidung während eines Arbeitstages zu gewährleisten.

3. Bei der Preisgestaltung geht es (Surprise, surprise!) um die Kosten des Tools für dein Team.

Die meisten Tools bieten eine Live-Demo, damit du dir ein Bild davon machen kannst, inwiefern das Tool deine Produktanforderungen erfüllt und es zum Erreichen deiner Geschäftsziele beiträgt. Wir empfehlen außerdem, die kostenlosen Testversionen der Tools zu nutzen. Idealerweise solltest du beim Ausprobieren einer kostenlosen Testversion mit echten Forschungsdaten arbeiten (sofern dein Rechtsteam dies zulässt). So kannst du am besten beurteilen, ob das Tool für dein Team geeignet ist.

5. Verteile Zuständigkeiten und plane das Onboarding

Nachdem du dich durch Demos und Testversionen gearbeitet hast, steht nun eine Entscheidung an. Vielleicht willst du eine kurze Besprechung mit dem Team, deinen Vorgesetzten und anderen wichtigen Stakeholdern einberufen, um deren Feedback zu diskutieren und die endgültige Entscheidung gemeinsam zu treffen. Cross-funktionale Zusammenarbeit trägt dazu bei, dass sich die Teams während des gesamten Prozesses besser miteinander abstimmen.

Sobald du dich für ein Tool entschieden hast, solltest du jemanden mit der Implementierung beauftragen. Dazu gehört der Kauf des Tools, das Festlegen der Datenstrukturen im Repository, die Koordinierung der Migration des vorhandenen Forschungsmaterials, die Bereitstellung des Zugangs für alle Nutzenden, die Kommunikation des neuen Repositorys innerhalb der Organisation und die ordnungsgemäße Einbindung aller Beteiligten. Klare Zuständigkeiten sind für das Onboarding und die Arbeit in dezentralen Teams von ganz besonderer Bedeutung.

Denke daran, dass die Einführung eines Research Respositorys Zeit braucht und dass ein guter Plan für die Implementierung entscheidend für den Erfolg ist. Du musst nicht jedes Ziel von Anfang an umsetzen – behalte die Priorisierung der Ziele (aus Schritt 1) im Auge und konzentriere dich zunächst auf die wichtigsten Ziele. So machst du die Einführung des Research Respositorys zu einer überschaubaren Aufgabe und bringst eine gewisse Dynamik in die Sache.

Beurteile schließlich nach einer gewissen Zeit den Nutzen des Repositorys, indem du das Erreichte mit deinen ursprünglichen Zielen abgleichst. Idealerweise hast du im Vorhinein Erfolgskennzahlen und Metriken festgelegt (siehe Spalte G in der Vorlage). Jetzt kannst du Daten zu diesen Metriken sammeln, feststellen, wo du die Ziele erreicht hast, und ermitteln, wo noch Verbesserungsbedarf besteht.