Table of Contents Hide
A user research strategy has to be flexible, realistic and achievable to succeed. And the best way to do this is to focus on the key research questions, the outcomes, outputs and ways of measuring this.
As a freelance user researcher I recently completed a user research strategy for the release of multiple products working with the Llibertat UX agency for the University of Southampton digital team.
Taking this case study I’ve created some general principles and strategies for efficiency. This approach offered flexibility; interviews could combine multiple projects’ research questions and so make the review and iteration more efficient.
This article is split in 2 parts:
- part 1 (this one) deals with the planning, which is a key part of research operations or ResearchOps
- part 2 deals with how to gather research questions to make efficient use of researchers’ time
This post will focus on ResearchOps. Broadly speaking this involves setting the frameworks, management and processes to enable user researchers to get on with the job of research.
You can find out more in this post, where I also borrowed this definition from:
To be efficient.
User research is vital but it takes resources — primarily in time, but there are other costs, from incentive payments to subscriptions. You cannot research everything or else you will never finish. Instead you have to pick an area and proceed.
This applies whether you are managing multiple user researchers or just yourself as a team of one.
User research is also expansionary — existing teams need current products reviewed and upcoming products tested; other teams realise what it can do and want in on the action.
As stated in the ResearchOps post, there are 8 key areas ResearchOps cover (NielsenNorman list it as 6) and all 8should ideally be included in a a user research strategy.
To summarise how my posts on user research strategy relate to this ResearchOps process:
- environment: how the organisation treats user research, whether it is still fairly new or mature in carrying it out, and the thoughts of key leaders helps frame any strategy
- scope: the how, when, process and methods of the research (is it a team, what cadence do you expect)
- recruitment and admin: create a central of users you can draw from with enough information to enable you to not have to recruit for each project
- data and knowledge management: make sure the teams know the process for reviewing previous knowledge and sharing and centralising any project findings (ideally in a repository)
- people: this strategy assumed that the team were competent in user research and that all would play a part in carrying out research but this is not a given
- organisational context: engagement with stakeholders, both those involved with individual projects and the main strategy, is a vital part of this strategy both to keep these stakeholders informed and to get their feedback
- governance: create the processes and policies for consent and data storage and make sure you follow GDPR and other legal and ethical requirements or policies
- tools and infrastructure: if you don’t already have the required tools (software, subscriptions) in place get them before you start — if your strategy uncovers that you may need more tools, get them
Creating a user research strategy is not something you go down the 8 pillars and tick off when complete. It is a range of steps, often backtracking or reviewing, as I bounced between scope, governance, tools and so on. As such my posts will follow the approximate timeline I experienced.
But the aim was consistent — to amplify the value and impact of research at scale. And to quote a researcher from the Nielsen Norman article:
“The value ResearchOps can bring is not just calling and getting a participant but building a programme and establishing consistent quality for communications and research methods.”
The strategy I worked on then was both a way to build a programme of consistent quality research that supports and aligns with other team members and their goals to produce an optimal user experience.
The teams I worked with needed a user research strategy because:
- multiple, distinct projects all had the same deadline
- these projects were officially in Beta but had varying depths of research beneath them
- developers and delivery managers had their own goals and while they wanted to be research led, they had deadlines and priorities the user research had to fit around
- everyone wanted to know what was feasible in the time allotted
I’ve always said that user research requires a great deal of project management skills and good organisation.
User researchers needed a strategy so that a good framework was in place to allow the researchers to crack on with the jobs they needed to do without worrying about how to plan and resource it.
Before you do anything make sure you know what’s passed and what the team needs (not just wants) to happen and when. Then get the team — including key stakeholders — to review and agree on the main tickets of work.
Start with deskwork
Before I did anything, I did deskwork and spoke to key people, such that I:
- Looked in the Research Repository for past documents and spoke to others involved if they could find more.
- Spoke to delivery leads and development leads to find out what their key deadlines were.
- Asked what was absolutely needed for that date, what the minimal viable product (MVP) was, and what would be an absolute blocker to achieving this.
- Spoke to stakeholders — the heads of content, design, and other subject matter experts (SMEs) to get their perspectives.
In a way this is much like typical project management. Similar to my Coda project management toolbox or the Lean UX canvas.
In doing so I took the attitude of:
- I wasn’t afraid to have lots of questions and was clear on what I did not know
- I was there to listen and ask follow up questions
- I returned to the team once I digested the information and combined it with other sources to produce follow up questions
- I always asked who else I should speak to
Notes need to be managed and centralised to allow you record, spot gaps, and to play around. To do this I created an online whiteboard (Miro in my case) to centralise information and included:
- summaries of key documents
- notes from my conversations with delivery leads and SMEs
- groupings of notes and then summarised them to get what they related to
- the questions that arose from this summarisation and analysis
When I felt confident with the background it was time to move onto a standard template of things that each project had to answer.
Get a rough idea of all the projects
To me, the main things that must be answered at a high level for a project in order to proceed are:
- what is its purpose and why does this project have to be done now
- conversely, why could this project be delayed or be deprioritised (the devil’s advocate)
- who are the key users (and non-users) to engage, including stakeholders that must be kept happy
- when would the research count as ‘Done’
As mentioned though you can also go through the Lean UX canvas to get a more thorough overview. Whichever process you use, you are effectively seeking to go through the Five Ws:
- why this project needs to go ahead
- when it needs to be done
- who the key people are — both stakeholders and team working on the project
- how we think it can be completed
- where in the organisation the project sits and under whom
- what the key things researchers and the project team need to know and what will it look like when done
As stated, you also need a definition of done for when you feel you know enough about each project. For me it was when I could answer:
- the size of the project (T-shirt sizes)
- the number of rounds needed
- key user groups to speak to
- when the project would be done
- how to prioritise each project relative to each other
Time to start on the research questions
Once those rough answers were there it was time to finally start thinking about the research questions, as you now have enough information to start thinking about:
- what is the main question — Must answer
- What are the secondary research questions — Must answer
- What other questions can we answer — Should answer
- The main question we must answer could be ‘Can the product go live without major blockers?’
If for the main question we need the answer to be able to say “yes” or “no”, the secondary questions can be broader:
- what are the main blockers and why are they blockers?
- can we demonstrate through measurements that the new design/service is better than what it’ll replace?
- what changes must be made from the Alpha?
- which changes must be made before go-live, and which can be made after?
Other questions to answer can include:
- what are the main design problems?
- which parts of the UI cause the main issues?
Then go through and work out:
- how can we answer these questions?
- what previous research answers this (validation v seeking new data)?
Again this is all very similar to planning for an individual User Research project but the difference here is that you are doing this for multiple projects.
Team and stakeholder validation part 1
You should be engaging SMEs/project leads and then higher stakeholders (such as product owners) along with the wider team as you go along. But when you’re ready to go you must be able to confirm with them:
- does the user research focus on the most important research questions?
- can they do anything practical with the answers to the research questions (eg make a go/no go decision, go to the board and say that the system is better)?
- if we only focus on certain user groups will we get valid feedback in order to launch?
- are they happy with the potential outcomes (eg potential design changes, potential recommendations to move or even cancel a project)?
Once validated, I also took the teams through the plan so that all knew what was coming.
Make the tickets
By now you should have enough information to be able to make a start on creating tickets from your research questions.
Do this in your favoured format, whether in Jira tickets, Trello or physical notes. You may need to break down the research questions.
To save time during the sessions aim to create as many templates as possible. In some cases such as discussion guides you will want to use different questions.
However you can still create guides that do a lot of the heavy lifting (introductions, background questions) so that you don’t have to spend too long updating them.
Things you could prepare before you start include:
- consent forms
- discussion guides
- how sessions will run
- whiteboards, notebooks and other ways of capturing feedback
Part 2 will look at how best to plan your research questions and methods so as to make the most out of the time available.
In summary we’ve covered:
- why a research strategy is needed
- why it’s important to gather relevant information and documents of previous work
- why you need to review and centralise your thoughts on the previous work
- interrogate your notes with the journalistic Five Ws approach of who, where, what, why, when, who and how
- why it’s important to build templates to make your team’s work efficient
- start your research questions but first validate your work with your team, SMEs and stakeholders
Jonathan is on LinkedIn.
Read the full article here