How many times have you asked a colleague for a deadline for a research project, and they responded—with a small chuckle—"I wish we had the research done yesterday."
There is a need for speed in the industry.
For a long time, project timelines constantly stressed me out. It felt like no matter what I did, I couldn't keep my head above the water. I wasn't doing research quickly enough, wasn't analyzing data fast enough, and wasn't delivering reports "yesterday."
And, I must admit, there were times that I violated my own boundaries around research to get stuff done more quickly. Conducting generative research with only seven people? Yup. Running a usability test with three participants? Done it. Creating a deliverable based on 10 people? Been there.
The trouble with rushing studies
I've broken the rules we preach and try to abide by because sometimes the pressure is exceptionally high. I wanted people to see the value I could bring, so I twisted and molded user research into what my colleagues and timelines needed.
Now, this wasn't a practical or sustainable approach.
Not only was I still exhausted, but I felt guilty. I felt like I failed as a user researcher by not making this work and by diluting the quality of my research. But I was stuck.
If I didn't keep running and stretching user research, people might ignore me—or worse, find me completely useless.
I got mad at the situation for a while, but as I grew in my career, I saw many other user researchers in the same circumstances. So instead of fighting against reality, I asked myself, how might we find ways to work within our constraints?
How to speed up without sacrificing quality
Every user researcher wishes they knew the magic answer to speed up the user research process without sacrificing the rigor and quality of our insights.
It's a conundrum that has plagued us for years, and is something we must continue experimenting with. I've tried some pretty creative (and terrible) ways of doing this:
- Fewer users in tests have led to unactionable or scattered insights
- Speeding up analysis has led to missing key points and biased results
- Omitting parts of the process has led to misalignment and disappointing outcomes
- Skipping user research has led to costly mistakes down the line
I played with these rules and felt like I kept banging my head against the same wall, hoping for a different result. I wanted to shape user research to be something that it wasn't and that would never work.
Instead, I had to acknowledge that sometimes user research was slow, but I could lean it out in some situations. There are a few steps I take now when I have tight deadlines or need to move faster with my user research process.
✔ Know your options
The biggest game changer in speeding up my process was having a wide range of methods and understanding all my different options. I operated under the interviews or moderated usability testing model in the first few years of my career. I didn't venture out to explore other methods. Surveys scared me beyond belief, and I scoffed at unmoderated testing.
This meant that when stakeholders came to me with a request, I defaulted to either interviews or usability testing. Not only was this detrimental to the study results, but it left very little space for flexibility.
Exploring other methods and approaches to problems opened my eyes to a new world of possibilities. Instead of just using these two methods, I could reduce the scope of a usability test and run it unmoderated. I could do a diary study that collected data more passively or run a survey if the questions made sense.
Over time, I thought through different ways of approaching a problem based on the scope and had backup plans if deadlines were tight. For example, if we had to do generative research but didn't have enough time to explore all the different segments, we would have to prioritize one segment to look into now.
Knowing all the options and paths you can take for a particular project is hugely helpful in determining how to reduce the scope while still getting valuable results for your team. Check out this article to understand more about your process and how to do this!
✔ Determine levels of support
Depending on your organization's user research maturity, you can offer different levels of support on projects. If you have empowered and interested colleagues who can plan and run basic user research (think: unmoderated usability tests and surveys), you don't have to be 100% dedicated to these projects.
Instead, audit your projects and see where you can offer more limited support to have a higher capacity for other, more complex research needs. Here are how I categorize levels of support for my teams:
- Support areas: Methodology consultation, recruitment, interview guide review, tech set-up
- When I offer this: I have low to no capacity for other research projects, and the team feels comfortable running the research project
- Support areas: Methodology consultation, recruitment, interview guide writing, running 30-50% of the sessions (in case of moderated studies), tech set-up
- When I offer this: I have a small amount of capacity for research projects, and some of the team feel comfortable running parts of the research project; others can also learn how to research by shadowing
- Support areas: Methodology consultation, recruitment, interview guide writing, running 50%+ of the sessions (in case of moderated studies), analysis and synthesis, tech set-up
- When we offer this: I have the capacity for more research projects. The requesting team does not have user research experience and needs overarching support throughout the research process, from recruitment to learning delivery
✔ Remove cognitive load wherever possible
I used to take forever trying to prioritize user research projects. Once I realized I couldn't do every project under the sun, I agonized over picking which projects to do.
It took up so much mental space to prioritize these projects and write to my colleagues about why I chose one project over the other. I hated the feeling of disappointing people.
After a while, I learned about different project prioritization techniques and decided to have a go at creating a framework for prioritizing research projects. Once I did this, I could plug in the answers to critical questions and get a prioritization score. This removed the objectivity and stress of prioritizing projects and helped colleagues understand why specific projects had higher priority.
Additionally, I was taking a lot of time to answer the same questions. I would get messages like:
- Where do I find X persona?
- Where can I find the reports again?
- Where is the request form?
Now, I almost dove into a repository, but after being burned by them, I created a user research FAQ sheet. This FAQ compiled the most common questions colleagues asked me with the respective answers and resources. Then, instead of crafting the same message, I sent them this FAQ. I also posted and pinned the FAQ in Slack channels and had it in my email signature.
Wherever you can, remove cognitive load from your daily work and decisions!
✔ Automate as much as you can
One of my best exercises was to audit all the places I was doing slow manual work. I asked myself, where in my process was it taking me forever to do specific tasks?
With this, I quickly found my manual process was slowest with:
- Emailing and scheduling users for sessions
- Getting stakeholders to sign-up for research sessions
- Translating stakeholder research requests to real projects
When I identified these as the slowest parts of my process, I solved them as efficiently and effectively as possible. For example, I asked for tools (such as Calendly and Zapier) to help me automate certain tasks, created templates for recruitment emails and sign-up sheets, and put an intake process in place. This reduced meetings and the back-and-forth that came from one- or two-lined research requests.
I worked hard to automate as many manual processes as possible to give me more capacity for other critical parts of the research process.
✔ Work ahead as much as you can
Many companies work within an agile environment, using two-week sprints as a timeframe. User research can be incredibly effective if you work within this timeframe. The number one thing when working within an agile framework is that user research has to be working two to four weeks ahead of a given sprint.
The most effective research for an agile environment is usability and concept testing since they have timeframes that generally work within agile. If you want to plan and work ahead of schedule as much as possible, you must have frequent touchpoints with colleagues.
Here are the steps that I take when planning evaluative research within an agile environment:
- Review the team's backlog at the beginning of each quarter to see viable projects for evaluative research. Put these projects in your roadmap and backlog, and make sure to start research two to four weeks before the sprint
- Meet with your designer(s) weekly to see upcoming work they need to have tested. Align this with the projects you identified at the beginning of the quarter and put it into your backlog
- Meet weekly with your product manager (it can be the same meeting) to discuss any changes or upcoming projects that need evaluative research
- If presented with last-minute evaluative research, consider an unmoderated approach that can run over a weekend and deliver faster results
It's not worth it to sacrifice quality
While these are great options for speeding up research, quality is never worth sacrificing. Shoddy insights can point teams in the wrong direction and, overall, question the value of user research.
Before running headfirst with all the above strategies, I created boundaries for myself that I refuse to violate. I am always willing to be flexible to a degree. But I need to know and understand my boundaries, such as no fewer than 12 participants per segment for a generative research project. If we don't have time for 12, we need to reduce the scope or save the project for later.
Get comfortable with your boundaries, so you know when to say no to sacrificing quality for speed!