User research methods and practices fall on a spectrum, like a lot of things in life. I’ve found most user research studies are based on time restraints and budget restraints. So the spectrum sort of looks like this:
In-depth studies are characterized by:
Long deadlines
Vague requirements
Big fuzzy problems
Flexible budget
Not enough user information
Complex project with many moving pieces
Heuristic updates and best practices are characterized by:
Short deadlines
Clear requirements
Specific problems
Inflexible budget
Some user information
Smaller projects (often within a larger scope)
Looking at your project and the limitations or allowances you’re aware of, decide where on the spectrum you’re trending. If you’ve got a lot of unanswered questions, you’ll lean towards in-depth research. If you are making mid to high value, low effort changes, you can follow industry standard and best practices and lean towards heuristic research.
From there, make a map of what you know:
What are your technical requirements? (ie: what kind of functions will the system support? what are your developers capable of or limited by?)
Does this line up with the roadmap? (ie: is it something users have been asking for or that is already in the works? does it drive toward the business goals and product goals too?)
Have you done competitive research? (are others doing this? like us? better than us? what does it look like?)
Do you have industry research? (what is the standard right now? what patterns are common?)
Run a heuristics assessment. (where is our platform today? where are the obvious holes? what can be done easily?)
As you outline what you do know, what you don’t know will quickly come to light. That’s your research gold. Keep going through the mapping process until you’re sure of what you need to research and where on the spectrum your work will fall. Then document your research plan. (This feels tedious, but trust me: it saves you time later when you have to do a second study; it saves you headaches when everyone asks, “what’re we doing again?”)
Elements of a Research Plan
Timebox your study. Even if you’re not 100% sure, try to estimate how long it might go.
Scope it out. What steps will you take? What resources do you have and what resources do you need? Where does this study end and a new study begin?
Determine your methods. Now that you know where this project falls on the research spectrum, what specific methods and user research practices will you employ?
State your measurements. How will you validate your findings? Build-to-learn? In small chunks as you go? With live users or a lookalike audience? Once or several times?
Set expectations. List the deliverables from this study. (*Note: they may not always be tangible assets! Maybe it’s a presentation or a list of recommendations or an actionable next step… whatever it is you’re searching for, name it and shape what others will see when you’re done.)
Document how your tests went and what you discovered. I use a super simple one page template that gives others a high level overview of the study. And then that artifact can be tied to notes, recommendations, tickets, design initiatives… or it can be neatly filed in a research repository for posterity.
Here’s the thing about research studies that you don’t often hear: they involve a lot of people time. You might interview internal stakeholders; you will probably consult with product, development, design, the guy who buys software licenses, delivery, and compliance; you then spend time talking to the test participants -- a lot of time; and you have to socialize your findings. Most of us end up playing content strategist, trying to write our results in a couple different ways so the findings and recommendations land nicely for the executive team, for the product owners, for the development team. If you’re lucky, other people in your company are stoked on research and know the value it brings to moving a product or service forward -- find your allies and enlist their help sharing your insights.
Photo courtesy of Sebastian Hietsch on Unsplash
Comments