Scrappy UX Research
Spending 5 years at PayPal as a UX Researcher, talking to over 1000 users, at a place where research was a rich man’s problem, I found myself in a similar position. But at a startup, with no budget for research, no team and no direct access to users. It was time to get scrappy.
- Getting buy-in:
“No, we don’t want user feedback”, said no one ever. The problem isn’t getting feedback, it is more about time, effort and cost. Especially in startups, with agile and lean development, UX research can sometimes be seen as a distraction. And this is even more applicable in the B2B domain since your team also ends up being your first users. Then why still talk to users? Well, the classic “Malkovich bias”. Surprisingly most know about this, but forget to implement. On my end, I simply had to nudge the team with the below, inspired by Andres Glusman, and then I got a resounding yes.
To address the issue with time, effort and cost (discussed in 2), I shrunk the 4-step research process to 2, focusing mostly on research and impactful findings
I put together a research plan with the goal, methodology, users, metrics, discussion guide, and the overall timeline. This was a 1-week research sprint, with the last day for debrief and results.
2. Recruiting participants:
In the past, I’ve used recruiting agencies or Facebook and Craigslist ads to recruit participants. For these, you have to account for time to recruit, as well as cost, and I didn’t have either. So I had to look inward, well, within the company. Working with your network is pretty powerful, you at least get a response, and the chances of no-shows are negligible. And a SaaS, B2B domain helps as well. Your primary persona within your company will very likely know people in similar roles at other companies.
3. Incentives:
Recruiting participants from your network is personalized, yet you need to provide some incentive to thank them for their time. Giving a trial version of your product can work sometimes, but it’s highly dependent on the cost of implementation. I used the 5 why’s approach to distill on the participant’s ultimate drives and motivations for using the product. This helped me understand how to structure compensation. If I could solve a pain point that was low effort, high impact, it could be a win-win. I added questions in my screener that helped in distilling it. One of the themes that emerged from the screener that was high value was knowledge share and thought leadership on the domain. I used these to create an aggregate knowledge base and a monthly panel to connect with other users in similar roles.
4. Methodology:
Typically for faster results, remote usability studies can be pretty effective. However, since one of the goals of my research was understanding behaviors and validating personas, I used the ethnography method. Being in SF, with a high concentration of companies, worked in my favor. For recording the session, I was able to get a video camera from our Marketing team, along with a tripod. I scheduled the sessions to last no more than 45 mins, working around lunchtime or towards the end of the day. This flexibility also allowed my team to join me in the sessions.
5. Results:
Optimizing for time and effort, we wanted to get to the results pretty quickly. After each session, I did a quick debrief with the team member attending the session. The findings are fresh, you get to the crux quickly, you also get the watcher’s perspective which eliminates research bias, and they also become your referrer when you share the results with the rest of the team. The recordings are helpful when you want to go back and do a deeper analysis.
If there is one thing that is important in a research analysis is “why”. Understanding what users do and how they do is great, but ultimately what helps the product strategy is why they do it. So the report only focused on actionable insights which could be converted to solutions. The report was generated through a collective team effort, I used the sprint retro model and asked the team to come up with their 3 key takeaways. We reviewed these and saved them on our retro board. Being scrappy at its best.
Final thoughts
I firmly believe some research is better than none. Talking to internal users works, but sometimes you also need perspective from users who aren’t that close to your product and can give you an unbiased response. I would encourage you to look at this problem as a PM that you want to optimize. Identify the pain points of doing the research, and find solutions. You’ll be surprised by how creative you can get once you’ve settled on the goal.
