Ich habe ein User Research Repository aufgebaut und hier ist Wieso du das auch tun solltest
Deutsche Übersetzung des Artikels “I built a user research repository — you should do the same” von Author Jonathan Richardson.
Ein User Research Repository (eine Sammlung von Studien Ergebnissen) aufzusetzen ist höchst nützlich, bereichernd und ein umfassendes Werkzeug zur Aufdeckung von Erkenntnissen. Ich weiß das, weil ich letzten Monat eins gebaut habe.
Ich bin nicht der Erste, der das tut, und das beste, öffentlich verfügbare Beispiel, das ich gefunden habe, ist das, dass der Hackney Council in London erstellt hat.
Als freiberuflicher Nutzerforscher wurde ich von meinem Kunden gebeten, ein Repository aufzubauen. Es wurde benötigt, weil Wissen verloren ging, Arbeit doppelt ausgeführt wurde und Zeit damit verschwendet wurde, bestehende Arbeit zu wiederholen.
Mein Prozess zur Erstellung des Repositorys war:
- Suche und sammle alle Dokumente und Ressourcen und notiere entweder ihren Ablageort oder lege sie an einem zentralen Ort ab.
- Sichte die Dokumente, um Duplikate und irrelevante Informationen zu entfernen, und tagge* diese dann mit relevanten Kategorien und Informationen.
- Gruppiere die Dokumente nach Ihren Kategorien und Tags*, um sie zu überprüfen und zu verfeinern, damit die Kategorien und Nutzerbedürfnisse konsistent sind — die Gruppierung macht es einfacher, Muster und Duplikate zu erkennen.
- Nutze ein Regelwerk, entweder ein bestehendes oder ein von dir erstelltes, für den Umgang mit alten Informationen wie Kontaktlisten, persönlichen Daten, Fotos und Videos — und handle danach.
- Integriere einen Prozess für Kontrolle und Aktualisierung dieses Repositorys in die Arbeitsabläufe und Prozesse deiner Organisation.
*Tagging bezeichnet die inhaltliche Kennzeichnung von aufgedeckten Metainformationen in der Nutzerforschung (auch User- oder UX Research genannt). Somit “Tags” oder alternativ auch “Codes” genannt (ohne Zusammenhang zu dem Kodieren mit Entwicklungssprachen).
Edit: Mein Kunde hat sich inzwischen gemeldet, um zu sagen, dass er glücklich ist, verlinkt zu werden. Also ein großes Lob an das OneWeb-Projekt der University of Southampton, das eine benutzerzentrierte Erfahrung für seine Nutzer schafft. Es hat eine Menge an Ergebnissen produziert, weshalb es das Repository und die Anpassung an seine Bedürfnisse brauchte.
Suchen & Sammeln
Hier gibt es zwei Dinge zu beachten:
- Was zählt zu den relevanten Dateien?
- Wo können diese Dateien gefunden werden?
Als es darum ging, was als relevante Datei zählt, half mir folgender Ansatz:
“Was würde ich als User Researcher wissen wollen, der blind in dieses Projekt kommt?”
Es ist generell gefährlich, sich als Nutzerforscher in die Gedanken des Nutzers hineinzuversetzen, aber da die primäre (aber nicht exklusive) Zielgruppe Nutzerforscher sind, schien es das Richtige. Wer vollständige, richtige Benutzerforschung sehen will, findet dies auf der Seite von Hackney.
Typische relevante Dateien sind u.a. User Stories, Personas, Abschlussberichte und Ergebnisse, Forschungspläne, Diskussionsleitfäden, Listen von Benutzerpanels, sowie Fotos und Videos aus Studien.
Die Frage, wo diese Dateien wohl zu finden sind, bereitet Kopfzerbrechen. Jede Organisation, in der ich gearbeitet habe, hat ihr Speichermedium variiert, abhängig von der jeweils verwendeten Hauptsoftware, den Vorlieben des Teams und der individuellen Nutzung (z. B. hat jemand ein Abonnement für eine Software, die er für die “beste” Lösung hält, die aber von keinem anderen Team verwendet wird). Teams werden oft nach einem Projekt aufgelöst, ihre Mitglieder verstreut und Dateien gehen verloren oder werden gelöscht.
Auch wenn es einen offensichtlichen zentralen Speicherort gibt, wie z. B. SharePoint, wirst du dich umhören und alte Links finden zu Dateien auf alten PCs, persönlichen Google Drives, DropBox, Miro, Optimal Workshop … du verstehst, was ich meine.
Frage also jeden, der an einem Projekt mitgewirkt hat, frage und frage noch einmal, gehe auf Linkedin und suche nach ehemaligen Teammitgliedern und bitte sie, in ihren Erinnerungen zu kramen, um herauszufinden, welche Dateien möglicherweise noch vorhanden sind.
Sichten
Sobald du alle benötigten Dateien hast (oder denkst, dass du sie hast), führe eine Bewertung durch. Identifiziere in groben Zügen:
- essentielle Dokumente — Abschlussberichte, Key findings, Segmentierungen, Personas und Ähnliches
- Ordner mit recht nützlichen Dokumenten — z. B. sehr alte Berichte, einzelne Forschungsrunden sind zwar praktisch, werden aber wahrscheinlich nicht gelesen. Fasse idealerweise zusammen, was sich in jedem Ordner befindet
- irrelevante Dokumente — z. B. Geschäftspläne oder Dokumente, die dort nicht hingehören
Erstelle nun von einem zentralen Ort aus Verknüpfungen dorthin. Ich empfehle dringend eine Datenbank gegenüber einer Tabellenkalkulation (wie Excel oder Google Docs) aufgrund der Versionskontrolle und der einfachen Suche und Aktualisierung.
In einer Datenbank gibt es eine single source of truth (z. DT. einzige Quelle der Wahrheit) für jeden Datensatz, und wenn du diese änderst, werden alle mit diesen verknüpften Daten aktualisiert. In einer Tabellenkalkulation besteht die Tendenz Blätter, Zeilen und Spalten zu kopieren, und man kann sich leicht verirren.
Es gibt eine Reihe von Datenbankoptionen, aber informiere dich zuerst über die Preise bevor du voll einsteigst. Einige Organisationen verwenden SharePoint, andere AirTable oder Coda.io** (ich habe mich für letzteres entschieden, da es am günstigsten ist und Annotationen zur Erklärung des Inhalts erlaubt).
Beide Optionen bieten die Möglichkeit die Lese- und Bearbeitungsrechte zu beschränken. Ich habe “technischere” Datenbanken wie MySQL vermieden, da sie zwar leistungsfähiger sind, aber für den durchschnittlichen Benutzer verwirrend sein können.
Es spielt keine Rolle, welche Datenbank verwendet wird oder ob du deine Meinung änderst, da die meisten Datenbanken den Export als CSV-Datei erlauben, so dass du sie an anderer Stelle importieren und verwenden kannst.
Tag
Hier erweist sich die Verwendung einer Datenbank als sinnvoll. Idealerweise hast du eine Reihe von möglichen Metainformationen — Projektname, Art des Artefakts (Persona/Bericht usw.), Projektphase — um Elemente mit diesen zu taggen.
Aber das kann sich ändern und ist erst dann offensichtlich, wenn man nach Tags suchen, filtern und gruppieren kann. Eine Datenbank zu haben bedeutet, dass das Aktualisieren des Namens eines Tags den Namen in allen Datensätzen aktualisiert.
Mach dir also keine Sorgen darüber deine Tags von Beginn an richtig zu setzen, du kannst sie später bearbeiten und zusammenführen.
Dokumente gruppieren
Der mühsamste Teil davon ist das Auffinden und Hochladen der Dateien. Es ist nicht der größte Spaß, aber wenn du Ordnung magst, ist es befriedigend. Wenn du allerdings Organisieren nicht magst… nun, es muss leider getan werden.
Das Gruppieren ist der Punkt, an dem du anfangen musst zu denken. Mit Hilfe deiner Tags kannst du nun Dokumente nach ihrem Namen, Projekt, Status und anderen Kategorien gruppieren, um Dokumentationen oder Überschneidungen auszusortieren.
Benutzeranforderungen verfeinern und Konsistenz schaffen
Dieser Abschnitt wurde aufgrund der Beispiele und der Wichtigkeit so lang, dass ich ihn in einen separaten Beitrag über die Verfeinerung der Benutzeranforderungen ausgelagert habe.
Entschuldigung, der Sprung in der Mitte dieses Artikels ist nicht die ideale Benutzererfahrung, aber ein sehr langer einzelner Beitrag wäre es auch nicht. Zudem ist dieser zweite Artikel noch nicht in die deutsche Sprache übersetzt.
Mache Forschung und Überprüfen zum Teil des Prozesses
Sobald du deine Repositories erstellt hast, musst du deutlich machen, dass es sich um lebende Dokumente handelt, die konsultiert, überprüft und aktualisiert werden können. Du hast ein Repository erstellt, aber um es zur single source of truth zu machen, müssen andere mit einbezogen werden.
Die wichtigsten Punkte, die in den Prozess einbezogen werden müssen, sind:
- Zu Beginn jedes Projekts eine Desktop-Recherche zu den bereits bestehenden Projekten welche im Repository hinterlegt sind
- Aktualisierung des Repository am Ende einer Forschungsphase/ eines Projekts
Du musst zudem deinen Hauptnutzern — Nutzerforschern, Projektmanagern, Teamleitern — erklären und sie mit dem Gedanken anstecken, dass das Repository zu ihrem Vorteil existiert und warum es ein Vorteil ist.
Dazu gehört es, Show and Tells zu veranstalten, Vorträge zu halten, Blog-Beiträge zu schreiben, und andere auf dem Laufenden zu halten.
Ich empfehle auch, zusätzlich dazu, dass du es zu einem wichtigen Teil des Projekt-Prozesses machst, jemanden zu ernennen, der:die dir hilft, das Ganze zu beaufsichtigen um einen Erfahrungsaustausch zu haben.
Aufwandsschätzung
Wie lange hat alles gedauert?
Für eine fortgeschrittene Organisation mit mehreren Forschungsprojekten, die in einem System herumschwirren, würde ich einen Monat einplanen, damit jemand, der Vollzeit daran arbeitet, sowohl einen Dokumentensatz erstellen als auch die Benutzeranforderungen aktualisieren kann:
- Auffinden — dauert etwa eine Woche
- Sichten und Kennzeichnen — dauert etwa eine halbe Woche
- Gruppieren, überprüfen, verfeinern und Konsistenz schaffen — weniger als eine Woche für Projektdateien, mindestens eine Woche für die Benutzerbedürfnisse, vor allem, da du den Input eines Teams oder von jemandem Feedback einholen willst
- Erstelle eine Richtlinie und handle danach und teile die Ergebnisse mit anderen — etwa eine Woche, aber auch das sind laufende Aufgaben
Mehrwert des Repository
Es sieht nach viel Arbeit aus, und das war es auch, um es richtig zu machen. Die Vorteile fangen gerade erst an, realisiert zu werden, aber es sollte Zeit sparen.
Zum Beispiel neige ich dazu, mich umzuhören, wenn ich ein neues Projekt beginne, aber die Antworten waren durchwachsen. Vielleicht habe ich nicht die richtigen Leute erreicht, oder sie hielten ihre Arbeit nicht für relevant, oder es fehlte ihnen die Zeit zu antworten.
So konnte es passieren, dass ich ein Projekt ohne wichtige (bereits existierende) Dateien begann, die mir bei der Planung hätten helfen können.
Wenn ich stattdessen wichtige Informationen an einem Ort dokumentiert habe, an dem ich bei Bedarf darauf zugreifen kann, spart das Zeit und Mühe, um die Informationen zu beschaffen.
Ich denke, dass die Zeit, die ich in die Erstellung dieses Dokuments investiert habe, durch die Zeit, die andere bei der Suche nach diesen Informationen einsparen, durch die Verringerung von Wiederholungen und durch die neuen Erkenntnisse, die gewonnen werden, um ein Vielfaches zurückgezahlt wird.
Ich habe Potentiale für unseren Kunden identifiziert, nach denen er schauen sollte, und dies war nur eine erster Test.
Je mehr User Researcher und Teams es nutzen, desto mehr werden andere die Bedürfnisse der Nutzer miteinander verbinden, vorhandene Forschungsergebnisse finden, die ihnen helfen können und letztendlich das Leben für sich selbst und die Nutzer im Allgemeinen besser machen.
Vergiss nicht, den zweiten Teil dieses zweiteiligen Beitrags zu lesen (englisches Original), dabei geht es um die Verfeinerung der Benutzeranforderungen. Du kannst dich auch mit mir auf LinkedIn verknüpfen.
**Dieser Link ist ein Empfehlungslink, den ich und jeder, der darauf klickt, gutgeschrieben bekommen würde.
Original Artikel von Jonathan Richardson:
Translation by the German-speaking ResearchOps community. Thanks to Brigette Metzler, Hugo Froes, Frederik Bader, Jan Seifert, Jonas Fuchs, & Dominic Staub.
#UXR #UX #ResearchOps #User Research #User ExperienceResearch #DesignOps
