Getting the Most From User Interviews Part 3: Presenting Your Findings
Introduction
In part two of this series, I gave tips and tricks to think critically about analyzing what your users said. But all the analysis in the world won’t do you any good if you can’t persuade stakeholders and teams to take action. The final part of my series focuses on presenting your findings to get buy in from the people that matter.
Know Your Audience
The first and arguably the most important part of presenting your findings is knowing who your audience is. The C suite cares about very different things than your project team. Sure, you’ll use a lot of the same information when presenting to each audience, but knowing what to emphasize is key.
For example, when my team presented the findings from this case study, we presented 2 times. Once for our project, and once for the broader organization, including executives. The goals of these presentations were very different. Our team presentation focused on who we tested, why, the themes we uncovered, and recommendations. When we presented to the larger team, our goal was to demonstrate the value of doing this type of research, and how it could benefit the entire organization.
Decide What is Important and Why
If you’re like me, “everything” you found during your interviews is important. Unfortunately, there isn’t always time to investigate every datapoint fully. In order to help the business and team prioritize and make the right choices, you need to rank the finding. Fortunately, if you did the 3 pass from part 2, this should be relatively easy. As a user need perspective, the longer the chains and larger pattern/theme groups the higher the priority. That isn’t the whole story though. There are three aspects to consider when prioritizing: user need, business need/objectives, and technical feasibility.
Tell A Story
Let’s face it. User research is boring. There is nothing worse than staring at mountains of numbers and walls of text.
The User’s Voice is Always Better Than Yours
One thing I’ve learned is telling people “users said” is far less effective than hearing it straight from the user. Often times, UX teams lack the respect and trust of mature design organizations. The most compelling evidence that your product isn’t (or is for that matter) fulfilling the needs and providing value is hearing the actual voices of users. It is powerful. To help tell your story, incorporate the user’s voice instead of yours whenever possible.
Give Actionable Recommendations, But Don’t “Tell Them What to Do”
This is one of the hardest skills to master when reporting test results. Try to give non-UI related recommendations if possible. For example, if one of your findings was that users consistently failed to find a particular piece of functionality, don’t recommend “make the button bigger” or “add it to the main navigation.” Those are design decisions that need to be confirmed through conceptual testing. Instead, say something like, “explore ways to make X functionality more findable.” This way, you aren’t introducing bias in to the solution, and are giving the designers the opportunity to explore.
Conclusion
The quality of the interviews and analysis of the data is important, but convincing stakeholders and the team what to address and in what order can be the difference between success and failure.
