How to Hack User Research

In this article, we’re sharing how we’re getting creative with conducting user research to show its value quickly and dispel notions that it’s an expensive bottleneck.

In theory, most of us in tech know that we need to listen to the user, understand their needs and test our products early and often. In practice, it’s hard to do when we’re running by the seat of our pants trying to launch features. User research is commonly associated with prolonged timelines, additional expenses, and results that are interesting, but hard to act on (e.g., “our users don’t immediately see the value of our product”).

Your colleagues may be tempted to skip research altogether and “learn and iterate after it’s live.” That approach can create the illusion of saving time in the short term, because the product is out sooner. However, in the long term, and I’ve seen it, it can lead to wastefulness. If you release a product whose most important hypotheses are not validated even a little, you may have to spend a lot of effort redesigning and rebuilding the product (potentially incurring tech and design debt in the process).

By working with several start-ups and now at Algolia, a hyper-growth, developer-led organization, I’ve learned that I can be creative and agile in order to balance research with moving quickly. It means spending less time on recruitment and picture-perfect deliverables. It means sometimes talking to a not-perfect-fit-target-user, but still getting extremely valuable information.

Every organization is different and sets its own expectations for deliverables and project outcomes. This is what has worked at Algolia, and I am not sure it would have the same positive reception at a large multinational corporation. Still, you will pick up a few tips here that may work for you.

Know what you’re trying to do

Let’s go back to the basics for a moment. What you want to learn will determine whom you will recruit, how you will test and how much time you will need. If you want to test usability of your feature, you’ll run a usability test. If you want to conduct exploratory research to generate new feature ideas, you may run an observational study or in-depth interviews. Defining your goals as a first step in your project will help you to pick the right research tools and to keep the project scope focused and manageable.

Save time on recruitment, not on research

Recruitment, in my experience, is the most painful part of user research. You can pay recruitment companies to do it for you, but if you have a modest budget, you can be creative to economize time.

Even if you can’t recruit your ideal target user, it is still better to have someone walk through the prototype than no one. You can recruit in coffee shops: offer people free coffee for 5 minutes of their time (pro tip: avoid the morning rush). You can try posting an ad on Craigslist. You can go to a co-working space and set up a research station. Ask your friends to take a look when you see them over the weekend.

Let users come to you. If there a company event/meetup coming up that will attract your target users, set up a research station and give out swag or gift cards as compensation. People will be there because they are already interested in your company. Capitalize on this! Make them feel like they’re helping shape your company’s future. Train others within your company to help so you can test with even more people.

A company I know has Support Days, where once a week, users can come in and get their questions answered in person. Next to the support folks, there is always a researcher recruiting participants and running usability sessions

Use tools like Calendly to minimize the back-and-forth of scheduling, which can add up time.

Test with fewer people

I usually go for 5–7 users (within each user type category). Most of the time, you will have enough data with this number to see trends. If you don’t see trends or the patterns are weak, then you can add a few more participants. Some research is always better than no research.

Approximate your user

When you need results quickly, something is better than nothing. This is especially true if you are testing a prototype and are looking for general usability. Instead of spending time trying to find the ideal user profile, you can approximate your user and test with people of similar profiles. Let’s say you’re building a web app that will help sales folks in the solar industry draw up preliminary plans for a solar project. You want to test the usability of your drawing tools, which they will use to place a project on the map and generate a solar panel layout. Do you need solar sales people to test this? No! You need people of the same general comfort level with technology to see how they would use the tools. On the other hand, if you need to test the usability of the industry-specific input fields, then you definitely need to test with your target user and there isn’t a way around that.

One important note: this technique does not work for generative research, in which you need to get as close to your exact user as possible. If you don’t understand your actual potential users’ problems, you may not build the right products.

ABC — Always Be Conducting

Finally, it is much easier to do research if you have target users in the pipeline. It takes a bit of organization up front (more here), but can help prevent scenarios where you need to test, but don’t have participants. If you are a product designer and research is not your full-time job, dedicating even 2-4 hours each week to planning user research upfront may save you time when a research need arises in the future. Constantly recruit and set up conversations, testing sessions, etc. Try to create a pipeline of research calls and activities that you can later adapt to your needs.

Use all the tools

Speaking of tools… When you’re short on time, you should use every opportunity and tool to get the data you need, which means stepping outside of the one-on-one interview comfort zone.

• I will start by mentioning the myriad of user research tools out there: Validately, UserTesting.com, UserZoom, and so many others. You can read about pros and cons here, and here is an oldie, but goodie on how to select these tools from Norman Nieman Group.
• Join sales and implementation calls with your colleagues. These can provide a lot of information for you.
• Does your company use Intercom? Set up mini-research questionnaires using the “Engage” feature to gather data and to recruit for research.
• Do you have a support team or a call center? Listen in on the calls if you can. Go through the support tickets and conversations and follow up with users for further details. Speak to the support team members about what they’re hearing as well. (Keep in mind that they may speak to you in terms of solutions: “Our customer would be happier if we built X.” Try to get to the bottom of the problem rather than focusing on the solution first.)
• Think about implementing an analytics tool like Kissmetrics, Google Analytics, Hotjar or FullStory on your site to get some insights about how it’s being used. While these tools tell only a part of the story, they can give you some indication about quick wins on your site. For example, we recently learned through Hotjar heatmaps that the “Search UI” section on our docs page is too hidden. As a result, we will make it more prominent in the next redesign to ensure we share our Search UI expertise in addition to our technical know-how.
• Talk to the subject matter experts. Sometimes, they will tell you more than ten users will. Recognize their biases (and tendency to suggest a lot of solutions), and use their wealth of knowledge.

There are many, many tools at your disposal to get insights into your users’ needs and thoughts. Learn more about the different tools here.

Show results quickly, often — and don’t overdo it

As tempting as it is, don’t wait for the grand finale results presentation. Synthesize results as you go along and whet your stakeholders’ appetite. I usually do a synthesis session at the end of each day and then a larger one at the end of the week. I like to send out a research update each day or every few days to my team (that includes PMs, developers and other interested parties). This creates a sense of progress and my stakeholders are happy to see some early insights.

When hacking research, try not to fall into the deliverables trap. I usually don’t spend a lot of time on picture-perfect research reports. I compile key findings and recommendations focusing on the “so what” rather than spending time making pretty persona sheets for the sake of creating attractive deliverables. They take time and may impress people at first glance, but if they walk away not knowing what to do with these deliverables, then my time wasn’t well spent. Focus on impact of your research. What action should your stakeholders want to take right after they read your results?

As I mentioned before, it is important to consider your organization’s expectations and culture while implementing these methods. One time, I consulted with a large, traditional company, where presentation was essential to selling the idea. Our program manager hired a video crew to make a short film about our project. To me it seemed excessive, but the project would not have succeeded without it. So keep in mind what type of delivery will ensure your project’s success, but don’t be afraid to go leaner on the presentation if you can get away with it.

Most people in my company love hearing what our customers experience when they use our product. They are hungry for insights. It is our responsibility as advocates of user research to adapt our techniques to the organizations we serve so that we can keep giving our users a voice.