User research strategy, Part 2: setting up your team to answer the right research questions | by Jonathan Richardson | researchops-community

In research operations if you want to make your research team efficient and Agile and allow them to make best use of your time then planning the research questions is a good way to do so.

Using the research question approach I’m going to lay out here means you can make the most efficient use of researchers’ time. I’m also going to describe what I call the ‘marathon approach’ to research questions to boost your research team’s efficiency.

This is an article in 2 parts:

• part 1 deals with the planning, often known as research operations or ResearchOps
• part 2 (this one) deals with how to gather research questions to make efficient use of researchers’ time

If you haven’t read part 1 already I strongly recommend that you do as it lays out how to get to the exciting stuff — planning the research.

In part 1 we ended by getting to a point where we had reviewed past work and come up with a series of research questions that had been validated by the team and been put into tickets (such as in Trello or Jira, or even good old fashioned sticky notes).

Once you have enough information to get going then start planning how the work will run. Use the tickets to plan the work, breaking the tickets down as necessary.

Fitting projects and tickets in to a timeline

Here’s where User Research Strategy planning differs from planning for a single user research project, and where the Research Question Method comes into its own.

Say you have 3 projects. For each project assign a colour code (eg orange stickies for project 1, green for project 2 and blue for project 3) and take a whiteboard (online or offline) and on it list the:

• users or user types you need to interview
• prime, main and secondary questions you need to answer
• methods you can use to answer the questions

Now that you have your projects in one place look at these users, questions and methods and identify:

• repetition of questions
• similarities in questions (can you refine the questions and make them the same)
• repetition of users
• if there is potential to ask your users for one project questions for a different project
• repetition of methods (eg do you plan to send a survey out to different groups)

For methods this is particularly useful with surveys or A/B tests which can target a lot of users can you do this just the once rathe than repeat. It is also useful to consider if you have a small pool of users that means you are limited on how often you can reasonably contact them.

From this you should be able to group your questions and users and should have more of a mosaic of colours rather than the single coloured plans you had before.

So while you had 13 questions you have reduced this to 12. And while you had to answer 18 total questions (6 questions for 3 projects) this is now 12 overall.

Team and stakeholder validation part 2

Some researchers prefer to co-design research questions with stakeholders or SMEs. This method is researcher led.

Either way the questions should be validated by others. As in part 1 it should be with your teams and the stakeholders you’ll deliver to in order to ensure that you are answering questions that are most important. Be prepared to explain your questions or to update them or even bin them.

By the end of this you should have a list of valid research questions.

Still this can lead to several months worth of research. What if there was a different way?

Here is something that is contrary to user research — if you’re going to take the breadth approach then you may not need the test/iterate sprint cycle. This is the orthodox way of user research.

However, sometimes, when you have a lot to do, you need to go in for a little heresy of thought against tradition research thinking:

Don’t plan to iterate and refine in regular cycles. Instead answer as many research questions as you can and combine your knowledge into a large iteration and design session

Marathon approach

This is the marathon approach. If conventional user research is like a relay race of research-design-research then the Marathon approach is research-research-design.

In this method you cover as much ground as you can as long as these assumptions are true:

• you know enough about what you’re testing that there should be no big surprises
• you have a very clear goal you need to test — a pass/fail for product launch, for example
• there is a crossover in user groups, product/service or goal

Otherwise you will still need the traditional approach.

Planning the rounds

Don’t go in assuming you will carry run a Marathon Approach. As with most things in UX, think about what needs are to be met.

How many rounds do you need? Is your focus on:

• getting just enough feedback from users to answer the prime question
• you need to focus and iterate on a particular feature, problem or topic

Basically are you going for breadth or depth of research? This will be down to your individual project but in general:

• Discovery stage — breadth with a plan to add some depth towards end of project
• Alpha — depth in the areas you are testing
• Private Beta — breadth of issues that will prevent a launch, with some depth if held over from Alpha, or if things have changed since the Alpha ended

Breadth v depth

In general breadth:

• covers more user groups
• fewer opportunities to test iterations
• low design or dev capacity to make iterations

In general depth:

• covers fewer user groups but focuses on a core group or cohort
• requires designers and/or developers to be more involved and produce iterations
• allows more ideas to be tested

Setting up a marathon research plan

Planning for the Marathon approach has differences to normal planning.

First, there was less time for design or development. Rather than a roughly 1:1 time of research:design it was more like 3:1 or even 4:1.

But just because there may be more rounds of research before design work is needed does not mean that designers and developers need not be consulted. It is vital that they are just as engaged as is traditional — invites to interviews, planning and, most importantly, debriefs.

Once you have your plan now it’s time to get ready. But don’t dive into research just yet as there are a few things to do:

• review your templates we created in part 1 — eg consent forms, discussion guides, how sessions will be run
• capturing feedback — how will you do this, particularly if there will be gaps between the research and thinking about changes
• are the team mentally prepared — with a lot of research this can be demanding. Are they ready and what contingencies do you need, such as firebreaks or UX team members who can help
• build a user panel — if you don’t have one and you now know how many users you will need then now is the time to recruit

Research is only one part of the research-design cycle.

Time must still be allocated for design and development and it’s vital that designers and developers know this.

I ran a test found first and worked with designers and developers on ways that worked best for them. In some cases it was visual, having screenshots on Miro with notes, and each time we agreed something we did two things as a team:

1. Captured and summarised the findings.
2. Prioritised the proposed changes.

Thee proposed changes were collated with each round’s findings and proposed changes then as a UX team reviewed and re-prioritised changes as a group. Then we got devs and managers in to review, give feedback and ensure it was practical.

There is no one way to do this, the best way is to run through (and ideally test) with those who will be acting on the findings and working with whatever is best.

That is plan all your testing for your research questions and have regular breaks for iteration.

Then think about what is realistic. If you are facing a few solid weeks of interviews then plan in breaks. How dependent is the plan on the research team (whether it is just you or multiple researchers) — does it take account of holidays, illness or being pulled into emergencies?

I included firebreaks (a week or sprint with no tickets allocated — GOV.UK has a great post explaining the why and how of firebreaks) and planning time, along with a buffer towards the project deadline to account for last minute changes.

So ensure that designers, researchers and developers know when they will be expected to contribute. Of course make it inclusive rather than coercive but don’t forget to keep an eye on this in sprint planning and backlog planning sessions!

Go out and start doing it. Enjoy it and focus on answering those questions — though make sure you have regular retrospectives to ensure that the approach is working for you.

The beauty is that as you are looking at questions with definitions of done you have flexibility — if you answer one sooner than expected you can pick up the next one.

You are freer to do research at your pace rather than be constrained by design and development.

It will be tough but it allowed for efficiencies and planning for more research in than we initially thought while making changes efficient.

Good luck and comment below on how your strategies have worked, if you have questions, or if this has been useful.

This article covered:

• take you validated research questions as tickets and gather them as tickets along with tickets for the expected work (time, users and methods involved)
• play around with the tickets to see commonalities, duplication or similarities
• review which tickets can be combined and get a final validation
• decide if you need to go for breadth or depth of research
• decide the appropriate research-design pace and ensure that research is captured in a way that will enable designers to work efficiently
• test, review and monitor (thought retrospectives or otherwise) to ensure that work is going to plan and adapt as needed
• don’t neglect your team’s health — ensure that the pace is appropriate for the team

Good luck!

Jonathan is on LinkedIn.