Topics
June 26, 2023
.avif)
June 26, 2023
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.
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?
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:
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.
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!
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:
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:
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!
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:
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.
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:
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!
Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs.
To get even more UXR nuggets, check out her user research membership, follow her on LinkedIn, or subscribe to her Substack.
