At my last job, the company didn't have a consistent process for user research. I believed in the power of research, but the time needed to recruit users and talk to them was hard to come by. I performed sets of one-off interviews depending on project needs.
At the start of one of our biggest projects, I requested time to dedicate towards user research and learn about our customers’ goals and needs.
The attention towards user research attracted two of my colleagues from Marketing and Quality Assurance. They did not have much user research under their belts; however, they had two crucial qualities needed for a healthy team: excitement and a willingness to learn.
We love lists, so here are the biggest takeaways we learned as a team throughout our journey in list form. Checking off the following items will smooth out your team’s workflow, and allow you to focus on the actual research. Keep in mind that our team’s productivity was built around a 33% time commitment to user research.
One of the most important things in any team is making sure everyone is aligned on the goals. Being aligned builds trust and allows for autonomy within the team. If you’re not on the same page, your team will waste time and resources, leaving you better off not doing any research at all.
What helped us was coming up with OKRs (Objectives and Key Results) that aligned with our company’s OKRs. And to ensure we stayed on the path, we read off our team quarterly OKRs in every weekly meeting. And yes, this could get as tedious as you might imagine, but it also proved useful in the moments when we strayed too far, or chased down endless rabbit holes. Your OKRs will act as your true north.
The key to a successful project is consistency. So checking in on our to-do’s and forming weekly goals was important. Doing so helped to ensure the team completed their research insights before the end of the quarter.
For us, a weekly meeting was also a good way to keep each other accountable, and it provided a safe place to give feedback to each other. We used a running shared doc, recited our OKRs, retro’d the past week, checked off our goals, and talked about the projects or anything research related. A less obvious but critically important reason to keep your weekly meetings is because repetition breeds familiarity, and with familiarity comes trust.
After 2 months of weekly meetings, the team was not only in alignment with our goals, but we were operating like a well-oiled machine, and our weekly meetings served as our anchor.
Something I learned very early on when doing research was to make sure you’re talking to the right people. If you aren’t, then your data will be more biased than it has to be. If you are querying customers from your database, you’ll have to be specific about what types of buckets you’re using to qualify. You may also have to define what each bucket is and whether you’re filtering them out or just labeling.
As I’m sure many of us have experienced, I learned this the hard way when I had a list of customers I was talking to and realized that my set of interviewees leaned more heavily towards a certain persona, skewing my results.
This is why I advocate checking your buckets and challenging the definitions that you initially set. It’s easy to fall into the trap of using our data to validate our hypothesis, and we only notice this when something seems really off. But doing your due diligence from the beginning will pay off in the long-term.
The customers at my last job have seasons of when they are very active with our product, and when they are not. It’s much harder to do research during off-peak times because the customers we reach out to are less likely to help us in a timely manner.
If you know your customers’ schedule, use that to your advantage and plan interviews around it, while using off-peak times to prepare follow-ups.
How often do you check your email and see a survey or interview request? How often do you respond to those? Your customers are often providing your team a favor by filling out a survey or chatting with you. Aside from giving them incentives, make it easy for them when they are speaking with you. In every piece of communication, let users know what to expect, whether it’s goals, timelines, and even the platform you’re using to chat with them.
Keep in mind that customers won’t necessarily be in the same mental headspace as you and they certainly won’t have the same context or agenda that you have. Some of them have never done a user interview before, so this could be a totally new environment for them.
To illustrate, one time I interviewed a customer, only to realize later that I needed to dive deeper on a certain topic. The customer graciously agreed to a follow-up interview, but halfway into the interview he became quite frustrated. He had thought he had answered these questions before and was expecting a totally different sort of interview. This led to him being more closed off for the rest of our conversation, and I ultimately wasn’t able to get the information I needed. Had I set some expectations in my email communication with him, the outcome may have been different.
At about our third quarterly research project, we were feeling confident in our abilities, and our team aimed to validate a hard, company aligned problem. Fast forward to delivering our report. Our stakeholders were hoping for big insights that would help them make some critical decisions. Long story short, we had to deliver research insights that the stakeholders already knew.
Once your team starts picking up speed and producing results, people will notice. It’s important to manage everyone’s expectations at this point, your team and stakeholders alike. Quality research means you’ll learn something, even if it’s not what the company wants to hear or if it’s validating research you already know. Sometimes it’s important to remember that validating what you already believed to be true is still learning. In times like these, don’t let your team lose momentum and encourage them to keep pushing forward.
In the end, the research team successfully completed five quarterly projects, in the form of OKRs. The company went from having no research team, to requesting research before developing major product updates.
Adding these guidelines to your process will give your team the best chance at consistent, quality research. I want to thank Poll Everywhere for giving me the space and trust to start and iterate on the research process.
And a huge thanks to my amazing team that made this possible: Maxwell, Janaki, and Janet.
Participating in a competitionCase study
Scaling through SharingProduct Design
Join instructionsCase study (WIP)
UI RefreshProject type