General Usability Research Process
Most of my workload consists of user testing new and existing designs within each sprint cycle, which typically lasts 3-4 weeks depending on the size of the projects being released. As the only UX Researcher on my team and person who pioneered our process, I've structured my research periods to overlap these sprint cycles so that we are consistently able to implement key findings.
General Research Process
01
Product Team Planning
Working within a small and close-knit product team, my first step is usually to meet with them to discuss which project in development is most important for me to focus on for the research period. This can be anything from:
-
A new feature that requires a prototype
-
An existing feature we are looking to improve
-
General usability testing of the current product version
-
Contextual Interviews/Inquiries with customers
-
Survey studies
02
Research Outline
Once my team and I have determined what I should focus on for the research period, I create a research outline to review with them. This outline usually includes:
-
Overview of project
-
Problem or project context
-
Participant Archetypes
-
Research Goals
-
Research methods:
-
Tasks​ the participant will perform
-
Platforms we will be testing on (prototypes, QA environments, etc)
-
Features to focus on during the sessions
-
_svg.png){kind=icon}
03
Recruiting and Scheduling
After creating the research plan, the next step is for me to recruit participants for the project. Depending on the kind of research I'm working on, I'll send Calendly links through the following channels:
-
Existing customers:
-
Google Forms​
-
Email outreach
-
-
External participants:
-
Respondent.io
-
UserTesting.com
-
Craigslist
-
Linked in
-
04
User Feedback Sessions
Depending on the kind of research I'm working on, I'll utilize different methods for gathering data (although this outline translates to both in-person and moderated usability or feedback sessions). Generally I follow this structure to guide me through my sessions, although depending on the context of the research the questions may get more specific. Some sessions also utilize different traveler personas or archetypes, examples of which I have included below that I created for past sessions:
Introduction
Quick summary of our product, what to expect during the session, provide instructions, and allow them to ask questions.
Warm-UP Questions
Ask user the questions about themselves to help them get in the headspace for thinking about travel. Examples include:
-
Who are you?
-
What do you do for work?
-
How does travel fit into that role?
-
What was the last trip you took for work?
-
Do you have any budget restrictions?
-
What are your most important considerations when booking travel?
Access Test Environment
Depending on the kind of test being run, we will utilize one of the following platforms to test out our designs:
-
QA Test environment
-
Live sites with current content
-
Invision Prototypes
Prompt Tasks
During usability testing, I will usually follow one of the following methods:
-
​Ask users to think back to the last trip they booked and show me how they would recreate it.
-
Ask user to pretend they are a traveler who needs to book a specific trip, then have them show me how they would book it.
Take Notes
As users perform tasks, I will generally be taking notes as we go along. I will also be prompting the user to clarify any vague phrases or statements they make.
If I am leading a session by myself, I will instead record the session and transcribe notes after, so that I can give full attention to the participant.
Final Thoughts
Once all tasks are completed from our session, I generally ask the user for any final thoughts or feedback they would like to share. This gives them a chance to emphasize anything they felt stood out to them while using the product. As a thank you for their time, I compensate them with a $25 Amazon gift card.
05
Key Findings Summary
Once all sessions in the research period have concluded, I write up a Key Findings Summary report. This report highlights the most important bits of user feedback gleaned from our sessions, links to any spreadsheets I've created to cross-analyze responses (for Quantitative Research), and provides access to individual notes and recordings.
​
This report is generally structured in the following way:
-
Project Overview
-
Participant Information
-
Participant Data
-
Key Findings
-
Shared feedback​
-
Any feedback that was expressed by more than one individual across sessions. This feedback is usually the most robust since it highlights common perceptions of using our product. ​
-
ie. If more than one user is unable to find a specific setting.
-
-
-
Individual feedback
-
Any feedback that was expressed by one participant, but was still noteworthy to run by the team.​
-
ie. A user noticed a checkbox wasn't checked by default when it should have been. ​
-
-
-
Bugs
-
Any bugs, glitches, or issues that were encountered during the session (generally that I was able to recreate). ​
-
-
Main Takeaways
-
The top 10 or so takeaways from the session, generally helpful to pass onto stakeholders outside of the immediate product team. ​
-
-
06
Ticketing Improvements
Once my product team has been presented with the data, we comb through the findings determine which items:
-
Are currently in development
-
Are pending release
-
Require ticketing and PRD's
-
Should be marked as a Feature Request and tracked for future consideration.
-
Aren't feasible/marketable
​
Once tickets are written, I create an Epic Link for the project in Jira and link all of my research documents in the Epic so that engineers and other stakeholders can access my research as needed.
I typically work closely with the UX designers and will create wireframes for any preliminary design concepts they require.
​
This marks the end of my research project for the sprint cycle.
