If you’re starting out in a new role in research ops, design ops or any other kind of team operations, then this blog might be for you. It will show you the ins and outs of creating a flexible how-to guide database that will stand the test of time as you scale.
When I joined the research team at Monzo six months ago as their research ops lead, one of the first things I tackled was our research guidelines. Research ops is about scaling research by setting up systems that allow researchers to be exponentially more impactful. It’s not doing admin or logistics on behalf of researchers, but transforming how things are done so the team is more effective as a whole. Creating practical how-to guides is a really impactful way of scaling research ops as a practice:
The guides help people self-serve and move fast themselves
There’s one clear source of truth to update when processes change
Added benefit: producing the guides is essentially a crash course in how things work, making you an expert in your team’s needs and processes in short order - which is so valuable when you’re new to the team
But before you dive into the guidelines, it’s worth thinking about how they will be structured. People have different mental models when it comes to finding information.
Some people think about the stage the project is in (planning, then recruiting the users, then running the sessions, then analysing the results, etc).
Others think about methodology: this is how you do surveys, this is how you run interviews, etc.
And at other times it might be more useful to find a guide that outlines how to use a specific research tool: this is how you use SurveyMonkey, this is how you use Calendly, etc.
These are quite different ways to slice the info, and each has its own benefits. If you’re an experienced researcher, in the weeds of a project, you just want to know the ins and outs of an unfamiliar tool - you don’t need someone to take you through the whole lifecycle of a research project, or to explain how surveys work. But if you’re not a full-time researcher, but need to run a survey, you might benefit from in-depth step-by-step guidance on how to do so in the best way. So this question of how to structure the guidelines becomes a bit of a tricky one to resolve.
You might then decide to just pick one of these formats and stick with it. But what you will likely notice is it leads to people creating their own version of the guidelines in a way that makes sense for them. At first, this might seem like a good thing - “They’re really internalising it and using the content! Great!” But what happens when the guidance in the original guideline changes? That’s right - the many versions out there still contain the old info. Which means that these people keep using an outdated process...
Keen not to repeat past mistakes like these, I was grappling with the question of how to structure the excellent and extensive how-to guidance that existed at Monzo. And then it struck me.
Why not do both?
Why not do all of the above but in a scaleable way? Could we somehow create a how-to guide system, with smaller standalone guides that each describe a discrete process in the overall research lifecycle, but that can then be put together in different combinations depending on your need, to give you the full guideline? A bit like a design system, in fact - breaking the content up into the smallest standalone “chunks”, and then combining these into sets that are then used together to become full guidelines for specific needs.
Brad Frost’s illustration of how atomic design works - ie a design system
If this approach worked, it would mean we wouldn’t be limited by tool, or methodology, or stage: people could find a set of guides that combines all the relevant information for their situation and mental model, whatever that may be.
Databases FTW
Luckily for me, the research team were already heavy users of Notion, and I realised that Notion databases are basically designed for this scenario. With some guidance from our technical knowledge manager and Notion account manager, I decided to go for it. Here’s how I did it:
I moved all the existing content from all over Notion into one database
Merged duplicates and removed any overlaps
Deleted outdated information and replaced as needed with new guidance
Broke the content up: finding the smallest standalone chunk of content, and making that its own page in the database. For example, I broke the “how to run interviews” guide up into these smaller standalone guides (not an exhaustive list):
Finding participants
How to schedule participants
Using Google Calendar
Sending out an email campaign
Setting up note-taking templates
Writing a discussion guide
Sending out incentives
Editing and storing your recordings
How to use Google Meet
Tagged these standalone mini guides so they can be surfaced in related sets.
This last step was the most complex: the structure had to be clear enough that others could use it, and comprehensive enough to allow for all the combinations we needed. But it also had to be simple to maintain. In the end, I found that the following four categories gave enough detail and flexibility to group the content in ways that matched the most common mental models:
Research phase: Plan, Recruit, Conduct, etc
Target audience: Researchers, Ops, People who do research, etc.
Method: Usability, Interviews, Surveys, etc.
Type of guide: Overview, theory, how-to, tool, template, etc.
For example, the guides shown here, the first few are all tagged with “1:1 interviews” but not all have “Recruit” in the phase category. And “Finding participants” and “Sending out an email campaign” are both also tagged with “Surveys” in the method category, as these methods contain those steps too.
The last step was to set up landing pages in Notion to point people to collections of these guides based on some groups and filters I’d already set up - like “Surveys” - and we were off!
And it’s paying off
It seems to be working. Everyone can quickly find what they need in one place. When researchers figure out a new way to edit videos, for example, it’s super easy for them to add a new guide and tag it so that it is immediately available to everyone. Everyone can create their own views of the database content, filtered the way they like to suit their mental model (which one of our analysts promptly did, to my delight). The number of ad hoc “how do I do x” requests in our Slack channel has gone down, and when we do get them, it’s so easy to point people to information we’re all confident is up to date and relevant. An additional bonus is how easy it is to track all of this content - I don’t need a separate tracker or project list, I just look at the “last updated” dates and status fields right in the database. All the information I need is in one place, too.
So, if you’re starting out in a new role in research ops, design ops or any other kind of team operations, you might also benefit from developing a how-to guide database rather than a more “complete” (but ultimately less flexible) playbook of guidelines. And if you’re a researcher, take a look at the roles we’ve got open - we’d love to include your knowledge and expertise in our guidance!
If you're interested in finding out more about design ops and research ops, join me at DesignOps London on 10 March. I'll be speaking about my experience in setting design and research ops up for success