Building a user research repository is useful, satisfying, and a tool for uncovering insights. I know because I built one last month.
I‚Äôm not the first to do so and the best publicly available one I‚Äôve found has to be the one¬†Hackney Council in London¬†created.
As a freelance user researcher, my client asked me¬†to build a repository.¬†It was needed because¬†knowledge was being lost, work was being¬†duplicated and time being wasted repeating existing work.
My process to create the repository was:
Locate¬†all documentation and resources and either note their location or centralise in one place. Sift¬†to remove duplicates and irrelevant information then¬†tag¬†with relevant categories and information. Group¬†by your categories and tags to¬†review and refine¬†to make categories and user needs¬†consistent¬†‚Äî grouping makes it easier to spot patterns and duplicates. Have a policy, either an existing one or one you create, on dealing with old information such as contact lists, personal details, photos, and videos ‚Äìand act on it. Get the process of reviewing and updating the repository into your organisation‚Äôs¬†workflow and processes. Edit: My client has since been in touch to say they‚Äôre happy to be linked. So a big shout out to the¬†, which is making a more user centred experience for its users. It‚Äôs produced a lot of outputs, which is why it needed the repository and update to its needs.
There are two things to consider here:
What do you count as relevant files? Where can these files be found?
When it came to what counted as a relevant file I took the approach:
‚ÄúWhat would I want to know as a user researcher coming in blind to this project?‚Äù
It‚Äôs generally dangerous as a user researcher to put yourself into the mind of your user, but as the prime (but not exclusive) audience is user researchers it seemed fair. If you do want full proper user research, the Hackney page has this.
Typical relevant files include user stories, personas, final reports and outputs, research plans, discussion guides, user panel lists, photos, and videos from sessions, amongst others.
As for where these files will be located, that is a headache.¬†Every organisation I‚Äôve worked at has varied its storage medium depending on the main software in use at the time, team preferences, and individual use (such as someone has a subscription to software that they declare is ‚Äòthe best‚Äô solution that no other team ever uses). Teams are often broken up after a project, its members scattered and files lost or deleted.
So while there may be an obvious central location, such as SharePoint, you will be asking around and following old links to files on old PCs, personal Google Drives, DropBox, Miro, Optimal Workshop‚Ä¶ you get the picture.
So¬†ask, ask and ask again¬†anyone who has been on a project, get on Linkedin and trace former team members and ask them to go down memory lane for what files there may be.
Once you have all the files you need (or think you have them), perform a triage.¬†In broad strokes identify:
essential documents¬†‚Äî final reports, key findings, segmentations, and personas and the like folders of¬†fairly¬†useful documents¬†‚Äî e.g. very old reports, individual rounds of research are handy to have but unlikely to be read. Ideally, summarise what‚Äôs in each folder irrelevant documents¬†‚Äî e.g. business plans or documents that don‚Äôt belong there
From there create your links in a central location.¬†I highly recommend a¬†database over a spreadsheet¬†(such as Excel or Google Docs) due to version control and ease of searching and updating.
In a database, there is one source of truth for each record and updating it will update everything linked to it.¬†In a spreadsheet, there‚Äôs a tendency to copy sheets, rows, and columns and it‚Äôs easy to get lost.
There are a range of database options but research your pricing first. Some organisations use SharePoint, others¬†¬†or¬†* (I went with the latter as best value and it allows for text to explain contents ).
In both, you can make it open for others to view but restrict who can make changes.¬†I avoided more ‚Äòtechy‚Äô databases such as MySQL for while they are more powerful they can be confusing for the average user.
It doesn‚Äôt matter which database you use or if you change your mind as most databases allow export as a CSV file so that you can import it to use elsewhere.
This is where using a database shows its worth.¬†Ideally, you have a series of possible tags ‚Äî project name, type of artefact (persona/report, etc.), project stage ‚Äî to tag items.
But this can change and it is only obvious once you can group by tags.¬†Having a database means that updating the name of a tag will update the name across all records.
So don‚Äôt worry about having your tags right to start with, you can edit and merge later on.
Example: Tags and groupings for user needs
The most menial part of this¬†is finding the files and uploading them.¬†It‚Äôs not the most fun but if you like organisation, it‚Äôs satisfying. If you don‚Äôt like organisation, well, it‚Äôs an essential task.
Grouping is where you start to have to think. Using your tags you can now group documents¬†going by their name, project, stage, and other categories to help winnow out any documentation or crossover.
Refine user needs and make consistent
This¬†section became so long due to the examples and importance that¬†I‚Äôve split this into a separate post on refining user needs.
Sorry, a jump mid-way is not the ideal user experience but nor is a very long single post.
Make research and review part of the process
Once you‚Äôve created your repositories you must make it clear that these are living documents to be consulted, reviewed, and updated.¬†You‚Äôve created a repository, but to make it the sole source of truth others must be invested.
The most important points to include in the process are:
desktop research of existing research from the repository at the start of the project updating the repository at the end of a research phase
You also need to explain and evangelise to your key users¬†‚Äî user researchers, project managers, team leaders ‚Äî¬†that the repository exists for their benefit and why it‚Äôs a benefit.
This includes running show and tells, doing talks, writing blog posts, updating others.
I also recommend, that in addition to making it a key part in the project workflow process, appointing someone to help you oversee it so that experience is shared.
How long did everything take?
For a mature organisation with several research projects floating around its system I‚Äôd allow a month for someone working full time on this to create both a document records and update the user needs:
Locate ‚Äî takes around a week Sift and tag ‚Äî takes around half a week Group, review, refine, and make consistent ‚Äî less than a week for project files, at least a week for user needs, especially as you‚Äôll want to get a team or someone‚Äôs input as a two-eye review at the very least Create a policy and act on it and Share findings and evangelise‚Äî about a week but these are also ongoing tasks
It looks like a lot of work, and it was, to do it properly.¬†The benefits are only just starting to be realised but it should save time.
For example, I tend to ask around when starting a new project but responses would be patchy.¬†I may not have reached the right people, or they may not have thought their work was relevant, or they lacked time to respond.
As such I could start a project missing essential files that could have helped my planning.
Instead,¬†having key information documented in one place where I can access it as needed saves time and effort to get the information.
I like to think that¬†the¬†time invested in creating this will be repaid many times in the time saved by others in searching for this information, reducing the rate of repeating work, and the fresh insights that will be gathered.
I identified gaps for the client to search for and this should be seen as just the first review.
As¬†more user researchers and teams use it the more others will connect user needs together, find existing research that can help them and ultimately make life better for themselves and the users at large.
Don‚Äôt forget to read the companion¬†. You can also¬†.
*this link is a referral link to which I and any who click on it would get credit