Skip to content
Gallery
Example user needs repository
Database of original and refined needs
Medium posts
Look up tables
More
Share
Explore
Medium posts

icon picker
I built a user research repository — you should do the same

⁠
https://medium.com/researchops-community/i-built-a-user-research-repository-you-should-do-the-same-df680e140df8?source=friends_link&sk=7d9a90ac3c4d928316f4e0f87f462960
⁠
⁠

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.
⁠
failed to upload
⁠
⁠
Photo by 
National Cancer Institute
⁠
 on 
Unsplash
⁠
⁠
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 
University of Southampton’s OneWeb project
⁠
, 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.

Locate

There are two things to consider here:
What do you count as relevant files?
Where can these files be found?
⁠
Finding a file in VR from Disclosure
⁠
⁠
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.

Sift

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 
AirTable
⁠
 or 
Coda.io
⁠
* (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.

Tag

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

Group documents

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.

Timings

How long did everything take?
⁠
⁠
⁠
Photo by 
Djim Loic
⁠
 on 
Unsplash
⁠
⁠
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

Repository value

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 
part of this 2-part post, this time on refining user needs
⁠
. You can also 
connect with me on LinkedIn
⁠
.
*this link is a referral link to which I and any who click on it would get credit
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.