User research strategy, Part 1: planning and the Research Operations | by Jonathan Richardson | researchops-community

  • 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
ResearchOps is the mechanisms and strategies that set user research in motion. It provides the roles, tools and processes needed to support researchers in delivering and scaling the impact of the craft across an organisation
The ResearchOps community’s definition of what is ResearchOps
RAF Group Operations Room
Planning strategy as a team © Imperial War Museum
8 pillars of user research
  • 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
  • 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
Doing, Done, To Do notes on an arm
Projects are about getting things done and choosing when and how best to do them © Eden Constantino

Start with deskwork

  1. Looked in the Research Repository for past documents and spoke to others involved if they could find more.
  2. Spoke to delivery leads and development leads to find out what their key deadlines were.
  3. 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.
  4. Spoke to stakeholders — the heads of content, design, and other subject matter experts (SMEs) to get their perspectives.
Lean UX canvas v2
Lean UX canvas v2 by Jeff Gothelf
  • 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

Centralise thoughts

Notes on a whiteboard
© Jason Goodman
  • 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

Get a rough idea of all the projects

  • 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’
  • 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
What, Where, Why, When, Where and How
  • 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

  • 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?’
  • 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?
  • what are the main design problems?
  • which parts of the UI cause the main issues?
  • how can we answer these questions?
  • what previous research answers this (validation v seeking new data)?
Done stamp

Team and stakeholder validation part 1

  • 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)?
Getting team agreement on the plan © Imperial War Museum

Make the tickets

  • consent forms
  • discussion guides
  • how sessions will run
  • whiteboards, notebooks and other ways of capturing feedback
  • 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

Read the full article here

Total
0
Shares
Leave a Reply

Your email address will not be published.

Prev
Best Practices for Better Insights

Best Practices for Better Insights

Table of Contents Hide 11 tips for writing survey questionsSurvey tools to help

Next
Shhh: don’t tell anyone, Figma’s latest feature, Design in uncertain times

Shhh: don’t tell anyone, Figma’s latest feature, Design in uncertain times

Weekly curated resources for designers — thinkers and makers

You May Also Like