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

  • 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
World War 2 British army planning
Planning at Tobruk in World War 2. Official British Army photo No. BO 773 [BM 7241]

Fitting projects and tickets in to a timeline

  • 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
  • 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)
Users grouped by repetition, as are Research Questions, with questions 6 and 7 reviewed and merged into 6B

Team and stakeholder validation part 2

2 ladies running relay racing in 1939
A relay approach of research-design is more traditional. Wikimedia Commons
Traditional sprint management

Marathon approach

  • 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
Loneliness of the long distance runner
It can be tough on a long run © British Lion Films

Planning the rounds

  • getting just enough feedback from users to answer the prime question
  • you need to focus and iterate on a particular feature, problem or topic
  • 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

  • covers more user groups
  • fewer opportunities to test iterations
  • low design or dev capacity to make iterations
  • 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

Marathon approach sprints
  • 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
  1. Captured and summarised the findings.
  2. Prioritised the proposed changes.
Caffeine is no substitute for rest and a good work-life balance. Via Nathan Dumlao
  • 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

Read the full article here

Leave a Reply

Your email address will not be published.

User Interviews Release Notes 2022

User Interviews Release Notes 2022

Table of Contents Hide With this integration, we’re making user testing even

Product design and information security

Product design and information security

Table of Contents Hide Example 1SolutionDataExample 2Solution Have you ever

You May Also Like