My team is responsible for developing a diverse array of integrations into other products. We don't use most of these products and lack the intuition to figure out how to connect them with our products in a helpful way. For that reason, user research has become indispensable to help us learn what integrations to develop and what shape they should take.
At the same time, our company as a whole is vision-led, without dedicated user research resources. If you want to make user research happen, you have to do a lot of the leg work, with only occasional help.
And that's exactly what we've been doing over the past few months. In this post, I'll share a few tidbits that I've learned that help with running lightweight user research efficiently on the side.
The below ideas assume that you want to do user research but don't have much experience and need the process to be dirt cheap, as you need to take care of your other responsibilities.
User research can be intimidating to start with if you don't have prior experience. There is a large body of theory on meticulously planning your research - calculating sample sizes, thinking about different kinds of interviewer bias, sending out screening surveys, etc. I'd recommend that you hold off on the planning a bit.
Instead of jumping straight into planning, conduct a few semi-structured user interviews first. It doesn't matter where you find the users; internal users work as well. Prepare a couple of questions, but let the discussion descend into chaos if the interviewee feels like sharing. Look for similarities between what interviewees care about.
Once you have a couple of interviews under your belt, you will be in a much better place to decide on the exact goals of your research and what questions to put into the screening survey. Talking to users gives you a better sense of which direction you want the research to take. It'll also whet your appetite for more opinions, which is crucial for grinding through dozens of interviews with a smile.
If you're alone for the interviews, writing coherent meeting notes is a critical skill for executing user interviews.
There are two main ways you can record the contents of a user interview.
First, recording the audio/video of the meeting. This approach gives you a carbon copy of the meeting for posterity. Nothing else beats it in terms of completeness. It doesn't come without downsides, though. Unless you combine it with an outstanding transcription tool, reviewing the interviews is very time-consuming. And no matter what the interviewee says, knowing you're being recorded makes many people uncomfortable and alters their behavior, making them less willing to share.
Second, typing up meeting minutes as the interview is happening. You can opt for having a colleague in the meeting to type up the meeting notes. This is great but also risks that the interview will start feeling more formal, making the interviewee less comfortable sharing.
Personally, I enjoy typing up the meeting notes myself as they are happening, for a few reasons:
This said, making meeting notes of a user research interview is hard. You need to keep typing and thinking at the same time. You are not used to the particular person's accent and way of speaking yet. And sometimes, you just don't get what the interviewee is trying to say, so you're not even sure what you should be writing down.
If you're not strong at doing this kind of note-taking, I recommend you volunteer to be the meeting notes taker for as many work meetings as you can, even if no one reads them. This helps you improve your speed and notes coherency over time, making you a stronger interviewer in the process.
This bit of advice only applies if you work on something that is or interacts with a consumer-facing service, it might not work as well for business-to-business offerings.
Sourcing people for research on Reddit is a slam dunk.
Compared to any other potential source of interviewees I've tried (Twitter, emailing existing users), Reddit is an excellent source of candidates for users research, for a couple of reasons:
I'm not arguing that Reddit should be your sole source of interviewees, but that it's a great start. If you can, pad your sample with different kinds of users. Namely, users that just entered your product category or are trying out your product will provide a great counter-balance to the Reddit crowd. This combination, in turn, gives you a stellar overview of the field, from rookies trying to figure things out to "wow, I didn't even know you could make that work in my app" kinds of users.
At some point, you will want to show the interviewees mocks of your ideas. If your company has designers, asking for a little bit of help can take you far.
I got very fortunate to get help from one of our stellar designers when thinking about the first batch of mocks that I'd like to show to the users in the interviews. He prepared a few mocks and shared them in Figma, which allowed me to reshuffle and iterated on them quickly without depending on someone having time to help me.
If your company already uses a tool for mocking, learn at least the basics. Ask around about where do designers store mocks and if you can use them. If you can find a cache of pre-existing mocks, you've hit gold. Adopting existing mocks is much easier than making new ones from scratch; reuse saves you a lot of time.
Hopefully, the tips above will help you kick-start your guerilla user research, generate great ideas, and fine-tune them while also having a ton of fun!
Cover photo by David Travis via Unsplash