A More Actionable UX Research Readout — Inform Design & Build Empathy
As a UX consultant, I get hired to lead projects that range from pixel-perfect validated designs, to ideation workshops, to all styles of user research (blue sky ← → current pain points). The user research projects are arguable the most exciting, the most energizing for the team, and the hardest to articulate the process. I’ve decided to put together my ‘top 5 learnings’ in how to successfully present a research readout, which covers a small part of that process. These learnings are from my past 3 years as a researcher, both at frog design and now working for myself. Most of my research is conducted by myself and/or with one or two other team members.
What are the main goals of user experience research? To build user empathy within the team, to inform design & roadmap decisions in an actionable way, and to drive towards a more differentiated product that will win the hearts and minds of users. In short to drive design and build empathy.
How do we present research in a digestible format that will inspire and align a team? I get asked this a lot from clients, so here are the principles I follow when sharing research:
1. Enable the team to hear from users directly.2. Don’t take a feature request at it’s word.3. Create conclusions that are both pointy and blurry.4. Bring the team along.4. Organize the raw notes to be as glanceable as possible.5. Synthesize multiple times until you have clear direction.BONUS: Tools I use.
What this means: To make your talking points, insights, and findings more salient, share quotes, photos, and video clips to underscore your ideas. This gives the team a taste of what the users look like, how they talk, what their homes look like, how they develop ideas during a conversation, and their justification for certain requests and preferences. Do NOT share entire interviews, or clips that are longer than a minute or two — it’s your job to make selections and share snippets. Most of the people I interview are dispersed across the country or the world, so I prefer to do my interviews over video conference. I record the videos, then I cut down clips and compile them by theme. Don’t worry about the tool you use. If you have the money, go fancy with dragon, pearnote, or Adobe premiere; if not, do it down and dirty with Quicktime and a word doc.
Why? This is the #1 thing you can do to build empathy. There’s nothing more enlightening to a product manager to hear a user directly ask for a feature that they’ve already built (and realize that discoverability is the obstacle, not new feature building), or for an engineer to hear users express why they need something and how it would change their lives. I ️love ❤️️ this part of research readouts where everyone has an ‘aha moment’.
What this means: Your ultimate solution has to meet users’ needs on a very deep level in order to earn a place in their daily lives. People might tell you they need XYZ, but it’s your job to figure out why they need it. I’ve met all kinds of people in interviews. Some people will immediately rattle off a thoughtful list of feature requests (power users!), while others have never thought about what they want because no one has ever asked; some people are extremely generative with an open ended question, some freeze up; some people are comfortable expressing what problems they face, some jump straight to a solution and you have to walk them back to the problem. Regardless of what type of conversation you are having, you must to get to the ‘why?’ behind the feature request. If you’re in UX, you probably already know, you should really get to the 5th ‘why?’ to truly understand the base kernel of the user need. So when a user says, ‘I need XYZ’ don’t go out and build that.
Ask why they need it, what problem it solves, how blocked they are without a solution to that problem; then find out how many users share the same pain, and build your own solution out of that.
Why? Products and companies have to solve real user needs in order to truly be needed and relied upon by users. Most teams don’t have time to make a mistake when it comes to feature rollout. You can’t afford to create a feature that is not deeply loved by all of your users. If you understand their pain, then you can use that as a checklist of sorts…to be able to say, ‘does this solution meet their underlying needs of _, _, and _?’ ‘Will this solution solve for the people that have X need and Y need?’
What does this mean? When you share research with a team, the takeaways should be both open ended (blurry), in the form of ‘How Might We…’ statements, outlining the opportunity areas; but it’s also important to showcase some pointy solutions that draw a direct and powerful line from the ‘How Might We…’ to a specific solution. Team members value both and this allows teams that need to move fast and trust your design decisions to move towards your pointy solution; or teams that want to ideate and simmer can create solutions within the parameters of your opportunity area, which gives them built-in success criteria.
Why? Even if you feel you have reached the perfect solution, team members need to be walked to it. No one responds well to being told, ‘this is the answer, go build it.’ Furthermore, the due diligence is important to maintain, because once you are validating the specific solution with users, you’ll be circling back on the opportunity area that brought you there. This ensures that if you hit a dead-end — a solution that doesn’t drive the needle, then you don’t go back to square 1, you only go back to your opportunity area.
What this means: This means two things — firstly, literally bring a team member to the interview to listen if you can. Alternatively, you should also check in at a regular cadence with the team to share more rough findings and snippets of raw data.
Why? If team members can join you in an interview they will be energized to make the product better just by virtue of meeting a user who is garnering value from it; and in the longterm, they now understand how your research works and why it’s a complimentary method to quantitative analysis. They will see you dig deep on the ‘why’s and get to a real user need, not just a feature request. If that can’t happen, then remember to share often. Don’t go into a cave and come out with a 100 page deck that takes a full day to read out. Instead, share your one pagers in chunks, share fun sketches of early ideas, share your curiosities. ⚠️Warning: don’t share anything too fleshed out or else people might be anchored on it and just want to start coding! It happens. But do let people in on the energy of your detective work, what you’re curious about, and your early affinity maps. This will also mitigate skepticism later, when you inevitably get asked about your personas, ‘Did you explore any other spectrums or archetypes?’
Why, also? Another reason to bring the team along is because your research guide should be iterative and agile, just like your product! Hypotheses that you thought you would need 20 minutes of questioning on could be put to rest after 5 minutes with your first 3 interviews — now you’ve opened up 15–20 minutes for fresh conversational content! Secondly, the stakeholders might be shifting focus as your interviews are being conducted, so keep those lines of communication open, build your guide with your stakeholders, and be ready to roll with changes, or explain why you can’t. Thirdly, you might realize that you need one guide for one type of person, and a second arc of questions for a different type of person. Be agile.
What this means: Your team (and all humans) have limited attention spans, limited capacity for absorbing new ideas in one sitting, and limited decision making energy per day. If you bring them to the cutting room floor, you’ll get lost in tangents, in one person’s struggle (instead of patterns), and the loudest voice in the room will control the direction. Instead, you must synthesize all of your learnings into a few topics that you want the team to remember. In every research project I’ve ever done, I’ve had more findings than I could share in one deck. Stay organized with your raw notes — compile them by theme, by topic, or by persona, in a glanceable format, so you can find the details quickly when you need it.
Why? I’ve seen designers get so enthralled with all of the sensational user quotes, that they are too overwhelmed to draw any conclusions. They want to share it all. Sharing 100 half-formed thought is far worse than sharing 5 well-formed thoughts that support each other in a framework. Even if it means you have to withhold great user comments to do so, you’ll be better off. If those details become relevant later in team discussion, you’ll have them in your back pocket.
I’ve been asked a lot about what tools I use. I purposefully made this article not about tools because I wanted to keep it a bit higher level. But…🔧🔨✂️…my current mix is:
Zoom for video interviews.
Mural for one pagers.
Keynote for presentations I do solo.
G-slides for presentations when I have a client collaborator.
Nothing for transcription, but this is my biggest pain point right now.
TryMyUI for usability testing.
Typeform for surveys.
Handbreak for compressing video.
Dropbox to host videos.
Calendly for scheduling.
…other tools I’ve considered but don’t use for cost reasons or just haven’t gotten around to it: DScout, UserTesting.com, Airtable, Dragon.
Have more questions? I’ve available for hourly consulting if you want to chat. Don’t be shy:
