Creating effective UX research deliverables

Today's article is a guest post from Laura Klein, author of Build Better Products and UX for Lean Startups. Enjoy!

Recently, somebody asked me about creating research deliverables. They were a new researcher on a small team, and they wanted me to tell them the most effective way to communicate what they were learning in order to have maximum impact.

I was about to launch into my normal rant about how 30-page research presentations and enormous PowerPoint decks full of qualitative data are horrible wastes of time and how they must be avoided at all costs, but I’m tired of giving that speech. Instead, I sat down with the person and started asking questions. What I came up with was this framework.

What are you trying to achieve?

We create research deliverables (and design deliverables, really) for a purpose. The first step to knowing what deliverable will be most effective is to decide the appropriate purpose.

You’re going to create very different deliverables depending on which of these things you want to do:

• Synthesize
• Communicate
• Convince

Synthesizing

Many of the most effective research deliverables aren’t really deliverables at all. They’re tools for helping us to synthesize and understand the data that we’ve collected. These are things like empathy maps, customer journey maps, affinity groupings, value proposition canvases, and the user map in my new book, Build Better Products (shameless plug).  

These are all wonderful ways of getting the team to work together to go through the data gathered from qualitative research sessions and turn them into a coherent document together. The act of synthesizing the research together tends to disseminate the information much more effectively than any sort of report.

And, of course, the deliverables from these sessions tend to be very visual documents that can be posted in your design space or shared online to remind the team of the users for whom they’re building products.

Try this:

Get a small, cross-functional team together and make sure that they’ve experienced some of the raw research footage. Ideally, they’ve all attended or watched full videos of at least a few user research sessions. But if that’s not possible, start with an hour or so of immersion with video clips of specific participants doing tasks or talking about the product. Spend a little time asking people to relate specific customer interactions that they’ve had recently.

Then, have everybody spend 10 minutes silently writing down observations from the sessions. I like to write each observation onto its own sticky note. Have everybody write as many observations as they can.

Once you have all the observations, you’re going to work together to create some sort of map of the user or the journey. At the end of a few hour session, you should have the rough outline of something like an empathy map that you feel accurately represents a key user or set of users of your product.

The final step is to take the rough map and turn it into something that can be shared back out with the team. They can use it for later reference, but really, the most important part of the deliverable is the act of creation, because it means that you will all come to an understanding of the user together.

Communicating

Sadly, we don’t always have the luxury of getting all of our stakeholders into a room and making decisions together. Even when we do co-create, unless we’re in a tiny, completely autonomous team, there will still be other people within the org who might benefit from our research.

The most important thing when creating deliverables for communication is to make sure we understand the users of the deliverables and their needs. In other words, treat the creating of these deliverables like a small design project.

If you’re sharing contextual inquiry results with engineers who want to know more about how real people are using the product, you’ll need an entirely different set of deliverables than if you’re sharing high-level observations from a diary study with executives who are deciding on a new product line.

Although the deliverables themselves can vary widely, they do tend to be higher fidelity than deliverables for synthesis, because they are meant to stand on their own and communicate information to people without much context.

Try this:

Try using annotated interface screenshots to show issues and suggested changes in-line.

Over at UserOnboard.com, Samuel Hulick posts teardowns of product onboarding flows that are a great example of this style. They each stand on their own and effectively show both problems and recommendations for interfaces in a clear, fun way.

Image credit: UserOnboard.com

Convincing

It would be glorious if everybody believed everything you said about your research results, but sadly, I’ve never seen this be the case. There is always somebody who needs some convincing.

Even when our teammates are naturally inclined to agree with us, which isn’t always the case, there are times when we need to make it clear how important a specific result is or how critical it is to fix something immediately. This is especially true when our results are surprising or when they mean a very large change that might mean a lot of extra work for somebody else in the organization.

In order to convince people, you’re going to have to understand your audience, just like with the previous type of deliverables. You need to understand how much time they’re likely to spend with your deliverable and the medium they prefer.

You also need to know how to deal with egos. It’s an unfortunate fact that sometimes people need more convincing because they “know” they’re right. When this happens, all the data in the world won’t necessarily convince somebody that something they know to be true is false.

The best way to deal with somebody who knows they’re right is to involve them in the research planning stages. While they may not be willing or able to come along on all the research sessions, having them participate as early as possible means that they’re more likely to buy into the results. Have them state up front what it is that they believe to be true, and what sort of results they’d need to see to make them change their minds. Have them weigh in on which research participants would be most helpful to them in learning new things.

By involving skeptics in the planning process, you’re making it harder for them to dismiss your research later because “you asked the wrong questions” or “you used the wrong participants.” You’re also, believe it or not, often making your research better since this process can help you challenge your own biases and tighten your research focus to the things that people in your organization need help learning.

Additionally, you’re also going to need to understand how your research findings might help or hurt other people in your organization. Remember, something you’ve found out your product or user might be threatening to somebody in your organization. If that’s true, you need to know ahead of time what’s likely to get the most pushback.

Because these deliverables are meant to convince people, they’re almost certainly going to be the highest fidelity. The single most useful thing for convincing people is always video of real users interacting with a product.

Interestingly, a lot of researchers I’ve met spend a huge amount of time talking about their testing methodology in order to prove the results are correct. Sadly, most people couldn’t care less about your methodology and probably don’t know enough about good research to know how perfectly you’ve crafted your study. Instead, focus on the results, and put all the information about how many people you interviewed and for how long and with which questions into a handy appendix that people can read if they care.

Focus on the research results and business impact, not the methodology.

And don’t forget to present the expected business outcomes, as well. Research results aren’t simply a report about what happened when you talked to a bunch of users. They should contain a prediction of what will happen if the recommendations are followed. Make sure to explain how improving the observed problems in specific ways will make things better for the business.

Try this:

Frame your research results as a set of short, easily digestible stories. Give a short summary of a problem or observation, something like, “participants all wanted to save an item for later, but nobody was able to complete the task.” Then show three or four video clips, as short as possible, demonstrating the problem. Finally, give your recommendation. If you have supporting evidence that your recommendation will work, like a test of a prototype or an example from another product, show that, as well.

If you expect that people will be viewing the presentations on their own, make sure to have alternate slides that show quotes from real participants or users in non-video format, since not everybody will be able to view the clips.