5 baby steps on the path towards a research repository
TL;DR: Do you manage your research content properly? Do you have years of great content all stored in different places that are difficult to access? Don’t worry — fixing it isn’t as daunting as you might think.
One of the hot topics in user research and the Research Ops Community at the moment is research repositories.
You might prefer terms such as research libraries, findings databases, research hubs; it all depends on what is best understood by your organisation and users. ‘Repository’ has simply become the term of the moment. When you get super-advanced you can even give your repository a brand of its own; Uber calls theirs Kaleidoscope, whilst at Microsoft it’s HITS. Whatever you call it, the simple-enough purpose of a research repository is to make the insights you’ve gathered findable — but getting from a state where your research is pretty unorganised to the implementation of a formal repository can be a daunting prospect!
To help you get started I’m sharing 5 simple steps you can take to improve your storage situation and set you on the path to implementing a repository in the future. All these ideas are things we actually did at Deliveroo, and all will quickly put you in a better place with no immediate financial outlay required.
Step 1 — Make a list!
Your first step on the journey to making all your lives easier can be as simple as this — make a list of all the research you’ve done!
This may sound silly and obvious, but ask yourself — do you actually have this list anywhere? If I wanted to know all the research your team has done in the last year would you be able to put a list in front of me? What if I wanted to know all the research relating to a specific topic?
At Deliveroo one of the earliest and easiest steps we took was to write research lists and group them into high-level themes. For example a list of research conducted with our restaurant partners was grouped into topics like ‘choosing a delivery partner’ and ‘experience with refunds’.
How much detail you include on this list is up to you. It can be as little as title, date, and hyperlink, or as fleshed out as a summary of the methodology, findings, and outcomes. The latter is far more useful for anyone browsing, and I strongly suggest that if you have the time you go for that.
Step 2 — Have a system for identifying research projects as unique
We don’t often give much thought to the titles of our research projects. Usually a descriptive working title is all we have the time for, and this can lead to some very similar and forgettably named documents. ‘Usability test 2’, anyone? Come on, own up, we’re all friends here.
This is totally fine and logical at the time, but it’s rubbish at a later date when you’re searching for relevant research — how on earth do you tell one set of ‘customer interviews about pricing’ from another in a year’s time if they’re both called the same or really similar things?
Whilst naming conventions are something you could, and probably should, look into, one of the easiest ways to differentiate between similar pieces of research is to give them all a unique identifier. In the same way that a published book has an ISBN, you need to have a unique identifier to be able to point to and know you’ve landed in the right place.
At Deliveroo we use a code which starts with the year and quarter the research was conducted, then adds a signifier of which area of the business the project refers to, and finishes with a sequential but meaningless number. So the first piece of research we conducted this year in the delivery space would be 2020-Q1-D001.
Adding this code to all the project documentation allows someone browsing the documents at a later date to understand what project an interview transcript or discussion guide belongs to, and gives them the ability to navigate easily to the parent project folder or overview.
You’ll find this especially useful if your research documentation lives in Google Drive where navigability is woeful. It’s super easy to search for a key phrase in your drive and quickly pull up a transcript that is totally on point, only to be baffled as to what project this transcript belongs to and therefore unable to find the context or conclusions that relate to it.
By using unique codes and adding them to all your files, it’s super easy to track this back and create the navigable hierarchy that G Drive sadly lacks.
Step 3 — Have one place where research is always shared
When your researchers are embedded in product teams they will almost certainly adapt to the communication preferences of that team. This is absolutely the right approach; the research will only have an impact if it forms part of the ongoing conversation the team is having, and teams are often different — some live in Slack, others rely on email.
There is a downside to this tailored communication style though. It leaves someone who wants to find all the research on a given topic having to search across multiple platforms or channels to be sure they’ve looked everywhere, eg. Slack, Workplace, Confluence, G Drive folder for team X, etc.!
The solution? Have one place where all you ask your researchers to always share their research by default, then allow and encourage them to cross-post it to whatever additional groups or channels they feel are appropriate to hit their stakeholder audience.
For us, at Deliveroo this looks like a User Research group in Workplace. All research is shared here as default, and so in a way, the group’s feed is a mini-research repo, but researchers also share to other WP groups, Slack, Confluence, or other locations as they see fit. Product teams get the research they want where they want it, but anyone looking for past findings needs only search our Workplace group to know they’ve got the full picture.
Step 4 — Utilise repo features in your existing software
It’s tempting to think you have to start by buying dedicated user research repository software, and there are some really fantastic systems out there from which you can derive an awful lot of value. But when you’re just getting started why not look at what you already have available and see how far you can get without too much effort?
I’ve seen research teams do great things by customising platforms they already had like SharePoint or Confluence, although this often involves building custom templates and using macros to make them helpful so it could be a time-consuming solution and we’re looking for baby steps here.
An easy halfway house for us at Deliveroo was to use some of the built-in features of Workplace since this didn’t require any customisation — it’s purely out-of-the-box functionality. One example was defining a list of tags we could use to categorise research posts. Workplace allows posters to use random hashtags on posts, but it also allows group admins to pre-define a library of tags, and by capitalising on this feature we were able to make our research posts far more easily navigable. User researchers can choose up to 5 tags from this library to add to their posts, keeping our tagging consistent and turning it into a really helpful way for users to browse by topic.
If you already use Notion to collaborate as a team you can take advantage of their database templates and import your existing research lists (see tip 1) to end up with a repo-lite like the one below in an afternoon with very little effort required. Playing around with taxonomies or tables in your existing software will also help clarify your thinking around how your repo should work and leave you in a much better place to have conversations with repo software vendors if you do decide that’s the next step.
Step 5 — Make it someone’s job to maintain this
Let’s be honest — we’re all busy, and adding a summary of your research findings to a list, or remembering to add a code to your project, is one of the easiest things to drop when the pressure is on. Whilst it’s important to make sure everyone takes responsibility for maintaining these systems as much as possible, it’s also important to be realistic and to acknowledge that things get overlooked. In order to stop those innocent omissions spiraling to a point where your processes become ineffectual it’s important that the buck stops with someone specific.
If you’re at this early stage in your repo journey then this can easily be a researcher or the team manager as a side task.
If you’re getting more serious about managing your insights then a digital librarian or dedicated knowledge manager can do wonders for your team’s efficiencies and the ROI of research. We all know conducting research is expensive; if past research findings are regularly revisited then the value derived from that investment continually increases. It’s also common to hear from teams without a repo who worry they are sometimes repeating research, because existing insights that answer their questions can’t be located. When someone who has a deep understanding of things like search behaviours and taxonomies is in charge of the way you store your findings you end up with a system that maximises the availability and visibility of your insights to the business, whilst requiring minimal researcher input. Let a specialist take on this work while your researchers focus on what they do best.
At a minimum what you need is someone to monitor and ‘police’ the application of the processes you’ve put in place. Onboard new researchers to these ways of working and offboard leavers to make sure all their research knowledge has been captured, and iterate on the processes you’ve developed when lessons are learned in practice.
Conclusions
There are tons of fantastic software options if you’re ready to invest in a full-scale repository for your user research. If you’re not at that stage yet you can still realise impressive business benefits, including time efficiencies and improved research ROI, by taking some of the steps above. Most of the steps described here are foundational rather than alternative, so the work you put into creating lists, or applying standardised tagging, can be transferred to a more advanced repo if and when you’re ready to move on.
For advice on how to get started with any of this try joining the conversation in the ResearchOps Slack community where there’s a friendly and welcoming #research_repositories channel.
