Maze’s Future of User Research Report 2026 just dropped and there’s a stat in it that made me stop mid-scroll. Research importance to business strategy nearly tripled in one year. Not doubled. Tripled. 41% of survey participants reported that research now informs both product and broader strategic business decisions. We’ve been saying research needs a seat at the table for years, and now that we’re pulling it up, the pressure is on to keep it there. This report covers where AI actually fits into all of this (not to replace you, but to change what skills you need to be good at).

Read the full report

User research is a support system. With that support, we help our teams:

• Mitigate risky decisions

• Highlight the most important pain points and unmet needs

• Narrow the scope of possible solutions for a problem or unmet need

• Make more user-centric decisions

• Generate empathy and curiosity toward users

If you think about your user research as a product, those are the goals you try to achieve with your research studies. You are attempting to help teams make less risky, more user-centric decisions and also alleviate the pain point of trying to create meaningful products without a user’s perspective.

Our research is meant to boost our teams, empower them, and enable them to make the best decisions they can, given the information in front of them. This is the crux of user research and, often, one of the most important parts of our job.

When I was earlier in my career, I struggled so much with writing insights. I spent more hours Googling what insights were than writing them (and trust me, I spent many, many hours writing insights). They were an enigma, something that was meant to be magical, motivating, realistic, relevant, and concise.

It seemed nothing I wrote could come close to what everyone called an “actionable insight” (I hate the word actionable, by the way, because it is just such a vague word I tripped over for years). Yet, I also couldn’t find any concrete examples of insights seeing as most of them are kept locked away and confidential. The only real examples I found were ones I didn’t want to replicate. And, while it’s helpful to know what not to do, it doesn’t fully guide you in best practices.

Similar to my first personas and journey maps, my insights fell flat. They didn’t inspire great action and help teams make better decisions. They kind of just relayed the facts of the situation with subjective, vague language.

And, repeatedly, I was disappointed in my work. I felt like I wasn’t filling the full potential of my role and doing what user researchers are meant to. After some time, I decided to dive deeper into researching user research insights and create something that felt good for me, and that helped my teams in all the ways I strived to.

What is a user research insight?

Because it’s more interesting and fun, let’s start with defining all the things that a user research insight isn’t. There are a lot of terms floating out there that seem to get lumped together or used interchangeably with the word insight. Let’s take a closer look at these words and what they mean, independent of the word “insight.”

1. An observation. An observation, on its own, is not an insight because it cannot tell us why a person is acting in that way. It is simply something you observed happen without additional context surrounding it.

2. Quantitative data trends. Data trends tell you a lot about what actions users are taking on a product and can also highlight important trends in behaviors, as well as metrics. However, quantitative data doesn’t help explain why something is happening.

3. A fact. When we simply state a fact, such as “users have a lot to juggle at their jobs” or “participant one has poor eyesight,” we aren’t doing any justice to our projects. Facts are often well-known and lack a high degree of context, and that context is hugely important to insights.

4. A bug. Something wrong with the product isn’t an insight, but rather a bug that needs to be fixed. A bug is very product-centric, which is different from insights.

5. A finding. If you have information that will solve something today but won’t have a significant impact in the future, that is most likely a finding, not an insight. A finding typically doesn’t have a big consequence (we will get to define that word later) and is more on the shallow side. You typically have a lot of findings in evaluative research, such as usability tests.

6. A preference or wish. When a participant says, “I would love this feature...” you can’t use this as an insight. Dig deeper into why they want the particular feature to understand the outcome they desire. This outcome is the underlying motivation and is much more valuable (and closer to an insight) than a feature wish.

7. An opinion. Opinions are trickier than the above. When a participant expresses their opinion on something, that isn’t necessarily an insight. If a participant says, “Apple products are much better than Microsoft products,” that doesn’t really tell us much, does it? Similar to preferences and wishes, we need to dig deeper to expose the root of this opinion for it to get into the realm of an insight.

To demonstrate this a bit more clearly, let’s take a look at some of the insights I’ve written in the past that are less than ideal and break them down into these categories. This was when I was working at a hospitality b2b company, and we were also exploring residential properties as potential customers. Here is a screenshot from a report I wrote way back when:

Yes, I titled these as “insights.” Feel free to laugh — they make me laugh too. Or, if these look a lot like your insights, know that you aren’t alone! Writing insights is super hard work, and it takes a lot of practice. So, let’s rip my insights apart.

In the rest of the article, I break down what an insight is (and isn’t), using my own painfully bad “insights” from an old report as examples, then show the exact model I use to write insights that actually help teams make better decisions. Paid subscribers get:

• A clear definition of what a user research insight is (and what it’s for)

• A blunt breakdown of what an insight is not (observation, trend, fact, bug, finding, preference, opinion)

• Real examples of “bad insights” and why they fail your team

• The components that make an insight land: key learning → why → consequence

• A simple way to spot when you actually have an insight (four signals to look for in your data)

• The prework that makes insight-writing easier: quick stakeholder interviews + what to ask

• A lightweight satisfaction survey you can send after projects, with sample questions

• Two fully worked insight examples from generative travel research (package deal anxiety; price volatility distrust)

• A finding vs. insight comparison (with a rewritten version that shows how consequence changes everything)

Exclusively for paid subscribers

Read more

Paid subscribers get the power tools: the UXR Tools Bundle with a full year of four top platforms free, plus all my Substack content, and a bangin’ Slack community where you can ask questions 24/7. Subscribe if you want your work to create change people can feel.

Subscribe now

You know that sound a meeting makes when the energy drains out of it? The soft click-click of someone scrolling Slack, the PM’s throat clear, the faint shuffle of papers that don’t need to be shuffled.

You just said something important, something that took weeks of work, coordination, and probably a few late nights with messy transcripts, and nobody’s reacting.

You can feel the temperature drop.

That’s the moment every researcher dreads.

You’ve just presented evidence that contradicts what the team wanted to believe. Maybe users didn’t understand the new feature. Maybe adoption is lower than the optimistic model promised. Maybe your usability test showed people getting lost halfway through a flow that was “definitely ready.”

Whatever the reason, your research just stepped on someone’s dream, and you’re the messenger standing in front of the firing squad.

The illusion of “positive” research

Most companies say they love research.

Until it tells them something they don’t like.

Everyone loves a good insight when it validates their roadmap. That’s not research; that’s confirmation theater.

What most teams secretly mean when they say “show us insights” is “show us good news.”

So when you bring something uncomfortable, the energy shifts. You can see the signs:

• The head tilt.

• The “That’s interesting” in a tone that means “We’re not doing that.”

• The immediate pivot to “Well maybe users will behave differently when it’s live.”

That’s the moment where a lot of researchers lose the room—not because they’re wrong, but because they’re unprepared for the emotional weight of truth.

It’s not the data they’re reacting to. It’s the threat.

When your findings contradict someone’s plan, you’re not just challenging the design. You’re threatening someone’s credibility, political capital, and sometimes their bonus.

If you’ve ever watched a PM’s smile tighten after a slide that says “5 of 6 users couldn’t complete checkout,” you’ve seen this firsthand.

They’re not mad at you. They’re scared.

Your data just put their name next to a potential failure.

And when people feel cornered, they fight—just in polite, meeting-friendly ways.

You’ll hear phrases like:

• “That’s just early data.”

• “We only tested with ten people.”

• “We’ll validate that with analytics later.”

It’s self-preservation disguised as feedback.

Understanding that changes how you approach these moments. You’re not fighting against ignorance. You’re navigating power, ego, and loss of control.

Your job isn’t to be liked. It’s to be useful.

When I first started, I thought being right was enough. I’d show up to meetings with a rock-solid report, all the evidence clearly laid out, convinced that logic would win.

It didn’t.

I learned the hard way that truth doesn’t sell itself.

If people feel attacked, they won’t hear a word you say.

What works is reframing your job.

You’re not delivering bad news. You’re mitigating risk.

You’re not saying, “This failed.”

You’re saying, “Here’s what’s blocking the outcome you want.”

It seems like a small shift, but it changes everything.

Instead of “Users hated the dashboard redesign,” say:

“Most users struggled to find the metrics that matter to them. That’s creating friction before value, which is likely reducing adoption.”

Same insight. Different emotional payload.

One sounds like criticism. The other sounds like help.

What’s really happening in the room

When the room turns cold, you’re standing in the middle of three emotional currents:

1. Self-preservation: Someone’s work, vision, or promotion feels at risk.

2. Loss of control: People hate uncertainty, and negative data threatens their illusion of control.

3. Fear of consequence: “If we admit this is broken, we’ll have to change direction. That costs time, money, credibility.”

Once you realize that’s what’s driving their reaction, you can stop taking it personally.

They’re not ignoring you. They’re protecting themselves.

Your goal isn’t to out-argue them. It’s to lower the threat level.

The reframe that keeps you grounded

When you’re facing that silent room, remember this:

Negative results aren’t failures. They’re truths that save money before launch.

They’re the reason you don’t have to explain to the CEO why sign-ups dropped 40% after launch. They’re the reason engineering doesn’t waste a sprint fixing something that never should’ve shipped.

You’re not the problem. You’re the one keeping problems small.

If you can carry that energy into your presentation, you’ll hold your authority without losing your humanity.

Try this mental reset before every “difficult” readout

Before your next meeting, write this sentence at the top of your notes:

“My job isn’t to make people comfortable. My job is to make the product smarter.”

Then ask yourself three questions:

1. What outcome are they chasing?

2. What’s blocking that outcome according to the data?

3. How can I frame this so it feels like progress toward that outcome, not a detour?

Why they don’t want to hear it

Negative results don’t make people angry because of the data. They make people angry because of what the data means. When your findings point to something broken, the people in the room don’t see insights. They see risk; risk to their plans, their competence, their credibility. And unless you understand the flavor of that fear, you’ll waste your energy arguing facts to feelings.

The trick is to stop assuming everyone resists for the same reason. They don’t.

Every stakeholder has their own brand of self-protection, their own internal monologue that starts the second you say, “Users couldn’t find the button.”

The four resistance types

These are the four personalities you meet every time you deliver uncomfortable research. Once you can spot them, you can stop reacting emotionally and start steering the conversation.

1. The Builder: “They just used it wrong.”

You’ll know you’ve met a Builder when they respond to feedback like it’s a personal attack.

You say, “Users struggled to complete checkout.”

They hear, “You’re bad at your job.”

Builders are deeply invested in their craft, often designers or PMs who’ve spent weeks nurturing an idea. Their self-worth is tied to the thing you’re dissecting. When you poke holes in it, it’s like you’re poking holes in them. What to do instead of arguing:

• Validate the effort. “You’ve clearly put a lot of thought into this flow, people picked up on the intent right away. The challenge came in step three where they weren’t sure what to do next.”

• Shift the focus to alignment. “Let’s look at what’s getting in the way of people seeing that great design work.”

• Offer a next step that keeps them in control. “How would you want to tweak this before we test again?”

Once they feel seen, they’ll relax. You’re not trying to prove them wrong, but helping their idea succeed.

2. The Politician: “We can’t show this to leadership.”

These are your optics-driven stakeholders, often department heads or executives who think two steps ahead to what this deck will mean upstairs. Their resistance isn’t about the insight itself. It’s about perception. They’re terrified of looking unprepared, out of control, or like they backed a bad initiative.

You can spot a Politician by the way they redirect. “We don’t need to share that level of detail.” Or, “Let’s frame this as learning, not failure.”

They’re managing spin. Your job is to give them something they can say. How to handle them:

• Reframe the finding as foresight. “This gives us an early heads-up before leadership sees it post-launch.”

• Use language they can repeat. “We identified an opportunity to improve conversion before rollout.” (They’ll quote that sentence word for word.)

• Give them talking points. Literally write out a one-line version of each key takeaway they can use in exec meetings. It makes you an ally instead of a liability.

When you make the Politician look prepared, they’ll protect your credibility in return.

3. The Optimist: “Users just don’t get it yet.”

This one’s easy to spot. The Optimist loves the vision too much to believe it might be flawed. They’ll wave away usability issues with “Once we polish it” or “Once people get used to it.” In their mind, users just need to catch up.

Optimists usually sit in product or leadership roles where their job is to dream big. You don’t want to kill that, you want to tether it to reality without crushing their excitement. How to handle them:

• Anchor to their goal. “You want adoption. This friction is what’s standing in the way of that adoption.”

• Quantify the cost of waiting. “For every week we hold this issue, we lose X potential conversions.”

• Turn it into an experiment. “Let’s prove your hunch. If users ‘get it’ after the polish, we’ll see it immediately in the next round.”

Optimists calm down when you make it safe to test their belief instead of kill it.

4. The Scapegoater: “Those weren’t real users.”

Ah yes, the all-time favorite.

Whenever a result feels uncomfortable, the Scapegoater questions the validity of the research itself. They’ll nitpick methodology, participant count, or recruiting criteria. “Were those our real customers?” “Ten people isn’t statistically significant.” “That’s just one data point.”

They’re not questioning your methods. They’re trying to protect their narrative. How to handle them:

• Ground in replication. “That’s a fair question. We can test again with a different segment to see if it holds.”

• Call out the pattern, not the number. “We saw six people fail in the same spot independently. That’s the signal we’re surfacing.”

• Offer escalation, not defense. “Happy to rerun it if we’re unsure — that’s cheaper than launching and learning it at scale.”

You don’t have to win the argument. You just need to redirect the conversation toward learning. That’s your home turf.

How to use these archetypes

Before your next big readout, sit down and fill out a quick Resistance Map. Grab a piece of paper, draw four columns:

You’ll walk into the meeting already knowing who’s likely to bristle, what they’re afraid of, and what tone will calm them down. You’re preparing for the reality that research is political. The Resistance Map gives you control before the conversation starts.

The mistake most researchers make

They try to bulldoze resistance with proof.

• “I have the data.”

• “I have the recordings.”

• “I have the quotes.”

But data doesn’t change minds. Emotion does. You can’t logic someone out of a defensive reaction. You have to give them a safer narrative to attach to. When you understand what’s really driving their discomfort, you can meet it head-on with empathy and authority at the same time. That’s when your research stops being a debate and starts being a shared decision.

Quick exercise before your next presentation

Pick one upcoming readout. Then, answer these questions in one line each:

1. Who in the room has the most to lose if this finding is true?

2. What version of this insight would they feel comfortable repeating to their boss?

3. How can you say it that way without watering it down?

If you can write those sentences before you walk in, you’ll present truth that lands instead of truth that explodes.

The real pre-work

By the time you walk into a readout, the story has already been written. Not by you, but by everyone’s expectations.

Read more

Paid subscribers get the power tools: the UXR Tools Bundle with a full year of four top platforms free, plus all my Substack content, and a bangin’ Slack community where you can ask questions 24/7. Subscribe if you want your work to create change people can feel.

Subscribe now

You’ve run a study. You’ve got a deck. There are insights. Quotes. Maybe even a juicy clip or two. And yet something’s off. No one’s acting. Your team smiles politely, mumbles something about “circling back,” and then your findings drift into the digital void.

We’ve all been there.

It’s not that your work wasn’t good. It’s that no one, including you, had a clear way to know if it worked. That’s where success metrics come in.

We’re not talking about KPIs like "# of insights generated" or "level of excitement in the room." We’re talking about hard, clear signals that your research did something.

This article breaks down:

• What success metrics actually mean in user research

• How to pick the right ones

• How to track them (without turning into a PM)

• How to use them to grow your influence, your visibility, and your budget

And yes, B2B, B2C, and internal impact examples are all here.

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to—not around.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

Define What “Success” Means Before You Start

(No, “We learned a lot” doesn’t count)

If you’re anything like I was in my first few years, you probably run a research project, wrap it up, send the findings around, and then stare at your Slack hoping someone tells you it was useful.

If you wait until the end of a project to figure out what success looks like, you’ve already lost the chance to shape it. Success isn’t the presentation. It’s what changes afterward.

Here’s how to figure out what success actually means for your research, before you even write your first interview question.

Step 1: Ask the only question that matters

Before you build a screener or open a FigJam, ask your main stakeholder one thing:

“What decision are you trying to make?”

If they say something vague like “We just want to understand our users better,” push again. That’s not a decision. That’s a vibe. Keep digging. Say:

• What’s something you’re stuck on right now?

• What are you debating in your team meetings?

• Is there something that feels risky about what you’re building?

You’re looking for a moment of clarity. A real fork in the road. A choice they need to make but don’t feel confident making yet.

B2C example:

You’re talking to the product lead for a mobile meditation app. They say they want to understand their users better. You ask again:

“Is there a feature you’re debating?”

They say they’re unsure whether to invest in sleep stories or morning focus playlists next quarter. Boom. There’s your decision.

B2B example:

You’re working with a SaaS platform for accountants. The PM wants to “make the dashboard more intuitive.” You ask:

“What do you need to decide?”

They say they’re debating whether to hide advanced filters by default. That’s your research target.

Internal/organizational example:

You’re working inside a company on the design system team. A designer says, “We’re getting feedback that the spacing tokens are confusing.” You ask:

“What do you need to decide?”

They say, “We don’t know if we should rename the tokens or run workshops to teach them.”

Great. Now we’ve got something specific.

Step 2: Turn the decision into a success question

Once you’ve found the real decision, translate it into a success question. Think of this like writing the headline for your project before it starts. It should sound like this:

• Did we clarify the decision?

• Did the team feel confident picking a direction?

• Did the research unlock a concrete next step?

If you want to go further, you can even write it as a fill-in-the-blank sentence:

“This research will be successful if it helps the team ___________.”

Let’s use the examples from above.

B2C – Meditation app:

“This research will be successful if it helps the team choose between sleep stories and morning playlists for Q3 prioritization.”

B2B – Accountant dashboard:

“This research will be successful if it gives the product team enough confidence to hide advanced filters by default, or shows that it would hurt workflows.”

Internal – Design system:

“This research will be successful if it helps the design system team decide whether to rename tokens or invest in onboarding.”

Step 3: Write it down in plain language

Put this success statement somewhere visible.

Don’t just keep it in your head. Don’t bury it in a Google Doc that no one will read. Write it at the top of your research plan. Pin it in your team’s Slack channel. Repeat it every time someone asks what you’re working on.

And during the readout? Put it on slide one. Then repeat it on slide ten. Then end with it on slide twenty. Seriously, people forget. You’re not being annoying. You’re making it stick. Here’s what that might look like in real life:

Slack message you can send at kickoff

“Hey everyone, quick recap before we start sessions. This research will be successful if it helps the team decide between focusing on morning playlists or sleep stories for Q3. I’ll be shaping the sessions around that question, so if anything shifts, let me know now!”

Top of your research plan

Study Goal: Help the team choose the next focus area for content (sleep vs morning). Success = clear recommendation backed by user evidence + action taken in Q3 planning.

Slide 1 of your readout

This study’s success = helping the team pick a direction.

Based on what we heard, here’s what we recommend and what to do next.

If you’re still stuck…

Ask yourself:

• “What would make this study feel worth it a month from now?”

• “If I wasn’t here, what decision might they make blindly?”

• “What’s the worst-case scenario if no one listens to this research?”

The answer to any of those questions will help you write a better success metric.

Pick the Right Type of Metric

Most metrics user researchers are told to track are either impossible to prove or completely disconnected from the actual work.

• “Number of studies run.” Great. And?

• “Number of hours spent interviewing users.” Who cares?

• “Number of insights shared.” Shared where? With whom? Did anyone do anything?

That’s why I only use three types of success metrics now. These are the ones that consistently tell me whether the research mattered. You only need to pick one per study. Just one. That’s it. But pick the right one.

Type 1: Decision Metrics

Read more

You’ve spent weeks conducting interviews, analyzing data, and crafting insights that you believe could change the trajectory of your product. But when you share your findings, the response is… underwhelming. People nod politely, maybe ask a few questions, and then go back to business as usual. It’s frustrating, but it’s not uncommon.

The problem …

Read more

Paid subscribers get the power tools: the UXR Tools Bundle with a full year of four top platforms free, plus all my Substack content, and a bangin’ Slack community where you can ask questions 24/7. Subscribe if you want your work to create change people can feel.

Subscribe now

User researchers love uncovering insights, but let’s be honest, tracking the impact of our work? That’s a different beast. If you’ve ever felt like your research disappears into a black hole after presenting it, you’re not alone. But if you want a seat at the strategic table, you need to show your value in ways that are undeniable.

This isn’t about vanity metrics or feel-good storytelling. It’s about hard data, real influence, and making sure your work leads to tangible product decisions. Here’s how to track impact like a pro, using a structured framework that aligns with your UXR Impact Tracker.

Step 1: Set Up Your Impact Tracker from the Start

Most user researchers make the mistake of thinking about impact tracking after the research is complete, by then, it’s too late. The key to ensuring your work drives real change is planning for impact before you even start.

If you don’t define success from the beginning, you’ll have nothing concrete to measure later and your research could be dismissed as “interesting but not actionable.” Let’s fix that.

Define What Success Looks Like

Before launching into research, pause and answer these critical questions:

• What is the problem this research is solving? (Be specific, don’t just say “improve usability” or “increase engagement.”)

• Who are the key stakeholders, and what decisions will they make based on this research?

• What specific metric, KPI, or business outcome will this research impact?

• How will we measure whether the research was successful in 3-6 months?

Without clear answers, your research may be valuable in theory but won’t drive real product changes.

Example: Good vs. Bad Goal-Setting

Bad Research Goal: “Improve the onboarding experience.” (Too vague!)

Good Research Goal: “Identify usability barriers in onboarding that prevent users from completing the setup process. Success will be measured by an increase in onboarding completion from 60% to 75% within 3 months of implementation.” (Clear and measurable!)

Log Your Research in an Impact Tracker

Once you’ve defined the goal, immediately document it in your UXR Impact Tracker. This ensures the research is tied to a tangible outcome from the start.

Set up a new entry in your tracker with these fields:

• Project name: Ensures clarity about what the research is for.

• Impact statement: Defines what success looks like in measurable terms.

• Research type: Specifies the type of study (usability test, survey, etc.).

• Stakeholders: Identifies who will use this research to make decisions.

• ROI type: Connects research to business impact (retention, cost savings).

Example entry:

Align with Stakeholders

To ensure research is used, you must get stakeholder buy-in before starting. This means having direct conversations with the people who will act on your findings.

Steps to take:

1. Schedule a 15-minute alignment meeting with key stakeholders (PMs, designers, leadership, engineers). Ask them directly:

   1. “What decisions do you need to make, and how will this research inform them?”

   2. “What’s the biggest risk if we don’t solve this problem?”

   3. “What kind of insights will be most useful for your team?”

Document their responses in the tracker under Stakeholders & Decision Needs.

Example:

• PM: “We need to know why 40% of users abandon onboarding after step 3. If we don’t fix this, we risk losing potential customers.”

• Designer: “We need usability feedback on the new dashboard layout before launching it.”

If stakeholders don’t feel personally invested in the research, they won’t use the results.

End every meeting with: “What would make this research a success for you?” Their answer will help you tailor insights to drive action.

Define What Type of Impact You’re Measuring

Not all research influences product changes immediately. Some research influences strategy while other studies drive immediate fixes.

The 3 Main Types of Research Impact:

1. Direct Product Impact: Research findings result in product changes, UI updates, or feature adjustments.

   1. Example: “Our study on checkout friction led to a redesigned payment flow, decreasing drop-off by 12%.”

2. Strategic Influence: Research shifts company priorities, informs a roadmap, or changes a long-term strategy.

   1. Example: “Our research showed that users prioritize speed over new features, leading leadership to invest in performance improvements.”

3. Operational/Process Impact: Research improves internal workflows, saves time, or enhances research efficiency.

   1. Example: “We streamlined participant recruitment, reducing turnaround time from 10 days to 4 days.”

Log the expected impact type in your tracker. This will help when measuring long-term results.

Example tracker entry:

Establish How You Will Measure Impact

Once research is complete, how will you know if it worked?

Every research project should have at least one measurable impact metric that is reviewed at 1 month, 3 months, and 6 months.

Possible metrics to track:

• If you’re researching a pricing page redesign, track conversion rates before and after implementation.

• If you’re testing a new signup flow, measure if more users complete registration after the update.

Set a reminder to check these metrics at 1, 3, and 6 months. If impact isn’t visible, follow up with stakeholders to investigate why.

Next steps

By now, you should have:

• Defined what success looks like before starting research

• Logged the project in an Impact Tracker

• Aligned with stakeholders on expected decisions and impact

• Identified the type of impact (product, strategy, or process)

• Defined how you will measure success and set check-in reminders

Go document your next research study in an Impact Tracker and align with a stakeholder.

Step 2: Ensuring Research Gets Seen and Used

You’ve done the research. You’ve gathered valuable insights. Now, the real challenge begins: making sure people actually use it.

One of the biggest reasons research fails to drive impact is because stakeholders don’t engage with it or don’t know how to act on it.

This step ensures your findings are not just read but discussed, referenced, and used in decision-making.

Choose the Right Format for Sharing Findings

Different stakeholders consume information in different ways. If you want your research to be actionable, present it in a format they will actually engage with.

Match the format to the audience

Steps to take:

1. Before creating a report, ask stakeholders:

   1. “What’s the most useful way for you to consume these insights?”

   2. “Would a summary, a deep dive, or a quick walkthrough be best?”

2. Structure insights in a way that answers their key questions:

   1. What’s the main problem?

   2. Why does it matter?

   3. What should we do about it?

3. Use clear, concise, and scannable formats:

   1. Avoid long paragraphs.

   2. Use bullet points and data highlights.

   3. If possible, create an “Actionable Insights” section at the top.

Example:

Bad:

“We conducted a usability test with 10 participants to understand how they interact with the onboarding flow. Several issues were identified, including confusion around step two, lack of guidance, and unclear terminology.”

Good:

“Users drop off at step two of onboarding due to confusion. 70% of participants didn’t understand the next action. To fix this, add a progress indicator and clarify step two’s instructions. If addressed, this could increase onboarding completion by 15%.”

Present Findings in a Discussion, Not Just a Document

If you only send a research report via email or Slack, there’s a good chance it will be skimmed or ignored.

Instead, schedule a research readout or discussion session where you can walk stakeholders through the insights and ensure they understand them.

How to run a research readout session:

1. Keep it short (15-30 minutes).

   1. Stakeholders have limited time. Focus on the most critical insights.

2. Start with the conclusion.

   1. Lead with the main takeaway, not the background.

3. Make it interactive.

   1. Ask stakeholders:

      1. “Does this align with what you expected?”

   2. “What questions does this raise for you?”

   3. “How can we apply this immediately?”

4. Have clear next steps at the end.

   1. Assign owners to actions.

   2. Get verbal commitments from PMs or designers on what they’ll do next.

Example agenda for a 20-minute readout:

A discussion ensures engagement. A report alone can be ignored, but a conversation forces action.

Track Stakeholder Engagement and Reactions

Once research has been shared, it’s important to track who engaged with it and how they responded.

If no one asks follow-up questions or discusses the findings, that’s a warning sign that the research is not being absorbed.

What to track in your impact tracker:

Example stakeholder engagement log

If you share findings and receive silence, take action:

1. Send a follow-up message:

   1. “I wanted to check in, do you see any immediate next steps based on these findings?”

2. Tie it back to roadmap goals:

   1. “Since this aligns with the Q2 roadmap, I want to make sure we discuss implementation.”

3. Set up a quick 10-minute sync:

   1. “Would a quick discussion help clarify anything? Happy to jump on a call.”

Why this matters: Research that isn’t engaged with won’t be acted on. Ensuring discussion and action is critical to making research impactful.

Assign Ownership and Next Steps

Even if stakeholders love the insights, research won’t drive impact unless someone is responsible for acting on it.

Steps to Take:

1. At the end of your readout, assign clear action items:

   1. “PM to update the roadmap to include X change.”

   2. “Designer to update UI elements based on findings.”

   3. “Engineer to investigate feasibility of the recommendation.”

2. Log these next steps in the Impact Tracker.

Example impact tracker entry for next steps

3. Follow up within 2-4 weeks.

   1. f no action has been taken, check in with assigned owners.

Without clear ownership, research can sit idle. Assigning responsibility ensures it turns into real changes.

Next steps

By now, you should have:

• Shared findings in the right format for your audience

• Presented research in a discussion, not just a document

• Tracked who engaged, what was said, and what actions were taken

• Assigned clear owners for next steps

Go back to your last research project and check:

• Was it shared in the most effective way?

• Did stakeholders engage with it?

• Are there clear next steps documented?

If not, adjust how you share research going forward.

Step 3: Measuring Impact Over Time

You’ve shared the research. You’ve got stakeholder engagement. But how do you prove the research actually made a difference?

This step is about tracking what happens after research is delivered, following up to ensure action is taken, and measuring long-term impact.

Most research impact doesn’t happen overnight. Stakeholders may agree with your findings, but implementation takes time. Without a structured follow-up process, research can get lost in the shuffle.

This step ensures that your insights turn into real changes and that you can quantify their impact.

Read more

—

Bindu is passionate about understanding people, their behaviour, and the ecosystems in which they interact. In every role she drives cross-functional collaborations across R&D and Go To Market teams to craft impactful product and service propositions with the most recent being a new product for Customer Onboarding Experience. Having moved from India to the Netherlands, from engineering to design, working in multidisciplinary (and multicultural) teams deeply influenced Bindu’s worldview and shaped her approach of connecting the dots.

With experience spanning both agency and in-house roles, Bindu enjoys transforming user insights into innovative B2B and B2C strategies, products, and services. She ensures every voice is heard and valued, fostering an inclusive culture where teams can thrive.

Bindu enjoys a lot of hobbies - painting, crocheting, knitting, reading books, strength training, and, most recently, sending digital postcards!

In our conversation, we discuss:

• How Bindu went from being drained by early workshops to building a facilitation style that fits her strengths.

• What separates a true workshop from a meeting and how to tell if you’re running one that should’ve been an email.

• Why facilitation isn’t just for extroverts, and how any personality type can make it their strength.

• Handling tricky workshop dynamics like power imbalance, dominant voices, and unclear goals.

• Bindu’s favorite practical frameworks, including “I Do Art” and the double diamond model.

Some takeaways:

1. Facilitation is a skill you can build, not a personality trait. Bindu reminds us that facilitation isn’t something you’re born with. It’s a practice that develops over time. She began by running small team sessions, learned by copying and iterating, and now has a toolkit that reflects her style and boundaries. Whether you’re introverted, new to the field, or someone who dreads public speaking, there’s a version of facilitation that can work for you.

2. Preparation changes everything. Rather than starting with activities, Bindu uses a mental model that splits every workshop into three parts: before, during, and after. The “I Do Art” framework, intention, desired outcomes, agenda, roles, rules, and time, is how she checks if a workshop is actually needed. Without clear prep, even the best-designed session can fall flat.

3. Workshops only work when they’re participatory. If a session is used to share decisions that have already been made, it’s not a workshop, it’s a broadcast. Bindu encourages facilitators to clarify whether people are being asked to collaborate or simply observe. When that line is blurry, trust can break down fast.

4. Managing difficult participants takes quiet strategy. When workshops go off-track, whether due to dominant voices, resistance, or role-based groupthink, Bindu relies on alignment with a sponsor, pre-workshop conversations, and delegation. Giving strong personalities a constructive role, like timekeeper or discussion monitor, often brings them onside without confrontation.

5. Don’t forget the follow-through. Workshops can generate energy but, without clear wrap-ups and next steps, it dissipates. Bindu closes each session by reviewing actions, assigning owners, and sending a summary soon after. She recommends ending with a reflective question to help participants carry the insights forward, like “What’s one thing you’ll do differently now?”

Where to find Bindu:

• Website

• LinkedIn

• Blog

Stop piecing it together. Start leading the work.

The Everything UXR Bundle is for researchers who are tired of duct-taping free templates and second-guessing what good looks like.

You get my complete set of toolkits, templates, and strategy guides. used by teams across Google, Spotify, , to run credible research, influence decisions, and actually grow in your role.

It’s built to save you time, raise your game, and make you the person people turn to.

→ Save 140+ hours a year with ready-to-use templates and frameworks

→ Boost productivity by 40% with tools that cut admin and sharpen your focus

→ Increase research adoption by 50% through clearer, faster, more strategic delivery

Grab the Everything UXR Bundle

Interested in sponsoring the podcast?

Interested in sponsoring or advertising on this podcast? I’m always looking to partner with brands and businesses that align with my audience. Book a call or email me at nikki@userresearchacademy.com to learn more about sponsorship opportunities!

The views and opinions expressed by the guests on this podcast are their own and do not necessarily reflect the views, positions, or policies of the host, the podcast, or any affiliated organizations or sponsors.

If you want to see everything I post, subscribe below!

Subscribe now

A client brought me in to lead a new research project.

They were gearing up to explore onboarding friction again. But as I settled in, I started digging through past files and realized they’d already researched it. Multiple times. Interviews, usability tests, journey maps, their team had been asking the same questions for over a year.

The insights were there. The problem was no one knew where they lived, what was still relevant, or how to reuse them. Rather than running another redundant study, I proposed that we instead build a secondary research hub, something lean, flexible, and immediately useful. This is not always a fun game to play within the scope of consultancy, but I had worked with this team before.

I sat down and created a proposal for this new project, re-scoped, pitched it, and viola. We went from a project about onboarding friction to creating a research hub.

Using Condens, I pulled together findings from five relevant past studies and turned them into a browsable, shareable insight magazine. Within a week, stakeholders were referencing it in meetings. Within a month, it had prevented at least two unnecessary research requests.

In this article, I’ll walk you through the exact steps I took, from curating studies to tagging themes to building and sharing the Insight Magazine. You’ll get everything:

• What I tagged (and what I didn’t)

• How I structured the board

• What language got stakeholders to actually use it

• And how you can replicate the process yourself

If you’ve ever suspected your team is sitting on underused research, this is how to bring it back to life.

What you’ll need

Before you start, here’s what to gather:

1. A tool, if you want, you can grab a 30-day free trial of Condens to use here

2. Past research

3. A list of two to four common recurring research themes/questions

This whole process can take about 15-20 hours (sometimes more depending on how much research you want to use), but it’s definitely worth the effort.

Step 1: Curate What Matters First

Your goal: Identify and gather six to eight high-leverage past research studies to form the backbone of your hub.

Most researchers fail before they even start because they try to import everything at once. At least that’s what I did when I first started putting together research hubs and repositories. I’d start from the study we did about two years ago and work through everything until I got to the latest.

Calling that process a slog is a complete and utter understatement.

I quickly realized that building something like this, especially if you are doing for a contract role, is not immediately about completeness, but rather about building a lean, strategic hub that makes past research usable as quickly as possible.

And that means choosing which research you start with wisely. When doing this, I typically look for:

• Studies that answer repeat questions

• Research that still feels relevant

• Insights that can influence planning, design, or prioritization decisions today

• Something we already have that teams are continuously asking about

Instead of thinking about it like, “What have we researched?”, I try to instead ask myself, “What questions do stakeholders keep asking me that I know we’ve partially answered before?”

Identify Recurring Stakeholder Questions

The first step that makes this easier is to think about what questions constantly are coming up for stakeholders. These are usually:

• Questions that come up during roadmap planning

• Topics that pop up in Slack or team comments

• Themes that span multiple teams (onboarding, trust, navigation)

• Anything you’ve been asked about more than once

Some examples of questions I’ve heard that commonly crop up across different teams and organizations include:

• “Do we know why users drop off after signup?

• “What’s the biggest barrier to trust for new users?

• Have we ever researched how people use feature X?

• What did users say about [problem area] in past studies?

When you’ve gone through and found the most common questions that keep repeating yourself (bonus points if you keep sending the same deck to the stakeholders that they clrealy aren’t reading), create a quick table like this in Notion, Google Sheets, or even a Miro board:

If you don’t know any projects off the top of your head that apply, you can either leave it blank or consider it as a future project. This is actually a great exercise in being able to answer the question of if you actually have to do new research for a particular question.

I usually aim to have about three recurring questions at the end of this exercise. If you have more than that, I would recommend trying to prioritize the top three yourself (think about the ones that answer the most pertinent questions in your organization or the questions that impact several teams) or, even better, engaging your stakeholders in the process and having them vote on the top three.

If you are able to engage your stakeholders, try asking:

“Hey [name], I’m building a mini hub to help us reuse past research more effectively.

Are there any topics you feel like we’ve already researched but can never find when you need them?”

Find the Source Studies

Once you have your big questions, it is time to find studies that help answer those questions. These come in the form of:

• Usability test reports

• Interview transcripts

• Presentation decks with quotes

• Journey maps

• Personas

• CSAT verbatim collections

• Anything with direct user quotes or summaries of findings

I recommend not (yet) including:

• Raw video files without notes

• Surveys with only quantitative data

• Exploratory docs without direct evidence

Ideally we want to start with studies that are already more easily digestible, so more like deliverables than raw data.

I typically will go through old slack messages, emails, drive folders, past repositories that may have failed, and ask around to make sure I find as many sources as I can for one particular question. I see this step as quantity over quality, as that comes in the next step.

Select Only the Most Relevant Studies

Once you gather the studies for wach question, it’s time to look at the quality and relevancy of the data. Not all reports are created equal and not all research is stellar. I’ve actually cringed at some of the reports I created at the start of a role versus a year or two in.

When you go through each source, you can ask yourself:

• Do I have at least one study that provides a partial or full answer?

• Is it recent enough that the data still applies?

• Does it include direct quotes or clear findings?

• Would a stakeholder benefit from seeing this again?

Use a scoring system like this (optional):

You’re aiming to end this step with about two to three relevant studies maximum per recurrent stakeholder question from above.

This step made a huge difference for me because I was no longer trying to simultaneously shove all the data we had into our hub and, instead, was only picking the things that were most relevant and actually had a place within the hub. You’d be surprised at the number of outdated studies out there. Usability tests can become obsolete pretty quickly if you work at a fast-paced organization. The ones that are no longer relevant, you can put aside.

What you should have now:

• A list of six to eight high-impact research studies

• Each mapped to a real, recurring question stakeholders ask

• Each study containing direct quotes or insight summaries

Step 2: Import Studies into Condens

Your goal: Get your past work organized in one place, cleanly, clearly, and without overthinking.

Your goals are to take the studies you selected in Step 1 and bring them into Condens (or another tool) so:

• They’re searchable

• You can tag quotes and themes later

• They’re accessible in a way stakeholders can actually explore

Remember that you’re not uploading for archiving, you’re uploading to reuse. That means:

• Clear naming

• One project per topic

• Structure that supports tagging + exploration

What You’ll Be Importing

Most researchers have messy, mixed files. Here’s how I recommend handling each format:

One “Project” per original study

Each project can contain 1–n sessions (depending on how it was run), for example:

• Project: 2023 Usability Test – Signup Flow

  • Session 1: Participant A (notes or transcript)

  • Session 2: Participant B

  • Session 3: Research summary deck

• Project: Onboarding Diary Study – June

  • Session 1: Week 1 notes

  • Session 2: Week 2 synthesis

  • Session 3: “Top quotes” from client wrap-up

Don’t overthink structure, just match how the research was originally run.

Naming Conventions

Use: [YEAR] [Project Type] – [Topic]

Examples:

• 2024 Usability – Signup

• 2024 Interviews – Trust Signals

• 2023 Diary Study – Onboarding

This makes it easier to sort and tag later. What I sometimes do is ask stakeholders to vote on a naming convention or I will share this naming convention with them so they are easily able to understand how I’ve thought about the structure.

How to Import Each Type

PDFs (Slide Decks, Reports)

1. Go to New Project in Condens

2. Title your project clearly

3. Add a new Session, and drag the PDF in

4. If there are quotes in the PDF, use highlight + tag immediately

5. If not, extract relevant text into a new text-based session (“Top quotes from report”)

Google Docs / Notion Text

1. Open a new Session inside the Project

2. Copy-paste the text from your doc into the session

3. Format headers and speaker labels if needed

4. Add a short note in the “Session description” field about what this doc includes (“Post-study notes, not cleaned transcript”)

If you’re importing notes that aren’t clean, highlight only the strongest quotes or summaries.

Raw Text Notes or Spreadsheets

1. Export your spreadsheet as a .txt or .docx

2. Open a new Session → Upload or paste in

3. Break into sections if needed (each participant gets its own Session)

4. Immediately scan for quotes you’ll want to tag

Video Recordings (optional)

If you have interviews stored in tools like Zoom, or Google Drive:

• You can link or upload videos into Condens

• If transcription is available, use it

• If not, either skip or add timestamped notes manually

Don’t upload all your videos unless you plan to use them. If no one’s going to watch it, skip it.

Bonus: Add Session Descriptions

Each session in Condens has a description field. Use this to give future-you (or a stakeholder) fast context using this format:

“Summary notes from final week of onboarding diary study. Includes key frustrations and 3 quotes on mobile experience.”

Add a 1-2 sentence summary for each Session you import. Pretend you’re writing it for a teammate who wasn’t there.

Try to avoid…

• Uploading one giant PDF with no tagging → split it into quote-friendly chunks

• Using vague project names like “User Interviews” → add context

• Trying to structure a perfect taxonomy now → wait until you tag in Step 3

• Skipping session summaries → you’ll regret it later

Step 3: Tag and Extract Key Quotes

Your goal: Create a reusable evidence layer that connects multiple projects via themes.

A tagging system can either make your research useful or forgettable. I've seen both. I've worked on projects where the tags helped teams find answers quickly. And others where tags were vague or overcomplicated and no one could find anything. I've spent hours digging through Notion and Slack trying to track down a quote I knew existed somewhere.

If you're building a secondary research hub in Condens, this is where structure starts to matter. Tagging is what turns raw quotes into something others can actually use. Here's how I approach it, even when starting from scratch.

What Makes a Great Tag?

A great tag is:

• Thematic (about meaning, not metadata)

• Stakeholder-readable

• Consistently applied across studies

• Short and specific

Example Tag Set I Used:

Avoid vague tags like:

• “Insight”

• “Feedback”

• “Pain Point”

These don’t help your future self or anyone else navigate meaningfully.

The Two Kinds of Tags I Use

Global Tags

These apply across research. They're the labels that show up again and again. They let me pull insights from different projects using a common language.

These are the ones I return to most often:

• Pain Point

• Bug

• Usability Issue

• Need

• Goal

• Motivation

• Competitor Mention

• Habit / Task

• Feature Request

I use these to ask questions like:

• What bugs have come up in the last three studies?

• Where do users mention unmet needs?

• Are there common tasks they struggle to complete?

Project-Specific Tags

These come from the content of a single study. They're shaped by what comes up in that work and don't need to show up again elsewhere.

From a travel study, I tagged:

• Instagram Inspiration

• Review Trust Issues

• Language Barrier

• Local Navigation Stress

Project tags are more detailed and short-lived. Global tags provide the structure to see across studies. I use both.

Should I Tag This?

Not every quote deserves a tag. In fact, most of them don’t. A good tag is like a good quote, it tells you something real, relevant, and repeatable.

Here’s the decision tree I use every time I tag a quote:

1. Does the quote answer a real stakeholder question we’ve heard more than once?

   1. YES → Tag it

   2. NO → Go to 2

2. Does it reflect a moment of confusion, hesitation, or delight from the user?

   1. YES → Tag it

   2. NO → Go to 3

3. Does this contradict something we’ve assumed to be true?

   1. YES → Tag it

   2. NO → Go to 4

4. Is it a strong example of a broader pattern or theme we’ve seen in other studies?

   1. YES → Tag it

   2. NO → Go to 5

5. Would I reuse this quote in a meeting, brief, or presentation?

   1. YES → Tag it

   2. NO → Skip tagging

Some examples

Here are a few examples of quotes and tags I’ve used in the past:

Example one:

“I assumed when I clicked ‘Instant Pay’ that it would transfer immediately, but then I got an email saying it’d take 24 hours…so I didn’t trust it anymore.”

Tag:

• Feature Confusion

• Trust Signal Broken

• Mental Model Gap

Annotation:

“This user expected immediate transfer based on the feature name. The delay broke trust.”

Example two:

“I loved that it let me skip steps if I’d done them before. That felt really respectful.”

Tag:

• First-Time Wow Moment

• Efficient UX

Annotation:

“Captures an emotional reaction to optionality in the flow. This showed up in 3 other studies too.”

How Many Tags Per Study?

I aim for three to five great highlights per session. That’s usually enough to represent what happened without overloading the system. For an entire project, I usually land around 10–15. If I get close to 30, I take a breath and re-evaluate.

If you are struggling ask if you would I use the highlight in a meeting? Would you pull the quote into a deck? If not, skip it.

Tag what you’d reuse, not everything that’s interesting.

How I Test Tags with My Team

Before I ship any tagging system, I pressure test it with the people who will be using it. I use the following methods to help me build and test a good tagging system that my stakeholders will understand.

1. 1:1 Interviews

I sit down with a couple of PMs, designers, or anyone who relies on research. I show them some quotes and ask:

• How would you search for this?

• What words would you use to describe this theme?

• Does this label make sense to you?

This helps me catch jargon and assumptions I didn’t know I was making.

2. Card Sorting

I put 10–20 tag options in a simple digital card sort. I ask people to group them, rename the ones that don’t make sense, and tell me where things feel repetitive or vague.

I always throw in some project-based tags to see how people respond to more specific terms.

3. Search Tests

Once the tags are live in Condens, I ask someone to try finding everything we’ve tagged under a certain theme, say, “onboarding friction.” I watch where they click and whether they find what they need. If they don’t, I fix it.

4. Feedback Prompts

Once a tagging system is in use, I add a simple prompt at the top of the board:

“Can’t find what you’re looking for? Something unclear? Let me know.”

That one line gets me more useful feedback than a dozen planning meetings.

Building a Tag Dictionary

Once the system is working, I document it. My tag dictionary lives in Google Docs and includes:

• The tag name

• A short definition

• A quote example

I review it once a quarter. At the end of each project, I check to see:

• Are any of these project-specific tags showing up again and again?

• Do we need to merge or rename anything?

If a tag proves useful in more than one project, I promote it to global. If it never comes up again, it stays where it is. The dictionary is never “done.” It grows over time. But that slow build gives the team a common language to work with.

If you are struggling with where to start on this, here are some examples of what a dictionary might look like:

Pain Point

Used when a user clearly expresses frustration or difficulty with something. This could be verbal (“I hate that I have to…”) or emotional (confusion, hesitation, visible irritation).

Example: “I never know which button to press first. It’s not clear at all.”

Usability Issue

Used when a user struggles with a task due to design or layout problems. Often tied to interface, copy, or interaction flow.

Example: “I thought clicking ‘Save’ would submit it, but nothing happened.”

Need

Used when a user shares something they require or are missing to complete their goal or task. This can be stated directly or implied through behavior.

Example: “I just want a way to filter by date. Right now I have to scroll forever.”

Trust Signal Broken

Used when a user feels uncertain, misled, or suspicious, often triggered by language, design, or unexpected outcomes.

Example: “It said ‘instant payout’ but then it took 24 hours. That felt shady.”

Motivation

Used when a user talks about what’s driving them, why they’re here, what outcome they’re aiming for, or what’s pulling them toward a tool or action.

Example: “I want to get my finances in order before I hit 40. That’s my goal.”

Feature Request

Used when a user asks for functionality that doesn’t exist or isn’t visible. Often phrased as a wish, a comparison, or a direct ask.

Example: “It’d be great if I could just drag and drop these instead of going one by one.”

Step 4: Build an Insight Magazine in Condens

Your goal: Turn tagged highlights from multiple sessions into a curated, browsable hub that answers the question, “What do we already know about [topic]?”

Once the tags are in place, this is where things (finally) start to pay off.

This is the part where you stop being the only person who knows what was learned in a project. Where research stops sitting in your head, or buried in slides, and starts working for the team without you having to explain it again. It’s where your work starts to actually get reused.

When I build an Insight Magazine in Condens, it’s not about creating a final report. I’m not trying to make something polished and pretty. I’m making something that’s fast to skim, easy to bookmark, and built to be used during decisions, not just after them.

I started doing this after a client messaged me, asking if I could “pull together a few quotes about onboarding trust issues.” I’d already tagged and organized all of those quotes, but they were spread across three studies. I realized the real issue was the way the data was presented. So I pulled everything into a quick magazine, grouped by theme, and dropped it into their planning doc. They never asked for another research summary after that. They just bookmarked the link.

This is how I build an Insight Magazine that gets used

What an Insight Magazine Actually Is

In Condens, a magazine is a way to curate research into a scrollable, structured page. It’s more lightweight than a report and more flexible than a slide deck. You can use it to:

• Pull together tagged quotes and themes across multiple projects

• Group insights into sections so they’re easy to scan

• Add commentary or summaries to help others understand what’s going on

• Create something you can link to directly, inside Slack, Notion, strategy docs, etc.

You don’t need to include every single thing you learned. Just the parts that people ask about most, or that affect decisions being made now.

Step-by-Step: How I Build It

1. Open the Magazine Builder in Condens

Once you’ve tagged and highlighted your quotes, head to the “Magazines” tab in your project. Start a new one. Give it a name that someone outside research would understand.

Not “Study Synthesis Q1 2024.” Instead: “Everything We Know About Onboarding Friction.”

That alone makes it more likely to get clicked.

2. Create Sections Based on Themes

Each section is like a mini-chapter. I usually create 3 to 5 of them per magazine. These can come directly from your tags, or you can group tags together under a broader heading.

Examples:

• Where trust breaks down

• What makes first-time users hesitate

• Things that surprise and delight

• Moments of confusion during sign-up

Use plain language. Think about what someone skimming this in a meeting would be drawn to. It should read like a list of FAQs, not internal taxonomy.

3. Pull in Highlight Cards

This is where your tagged quotes come in. For each section, I add 2 to 5 highlight cards that show the user’s voice in a way that supports the theme.

Each card should be:

• One clear quote (short and pointed)

• The tags you already applied

• A short annotation underneath, to explain what’s going on

Let’s say you have a section called “Where Trust Breaks Down.” You might include:

Quote: “It said ‘instant’ but it didn’t go through until the next day. That felt sketchy.”

Annotation: This came up in three sessions. Users expect ‘instant’ to mean immediate. When it doesn’t, trust erodes fast.

Keep the annotation brief. This is meant to be just enough context to help someone understand why the quote matters.

4. Write a Short Summary for Each Section

Above the quotes, I add a short paragraph (2 to 4 sentences) that sums up what the section is about. This is your headline insight, the thing you’d say out loud if someone asked you in a hallway.

It should answer:

• What’s happening?

• Why does it matter?

Example:

In three different studies, users hesitated during onboarding when they didn’t understand why personal information was being requested. The lack of upfront explanation made the flow feel untrustworthy. Friction increased when users couldn’t see how their data would be used.

These summaries are what turn the magazine from a quote board into something people can read and understand. Don’t skip this part.

5. Add an Intro at the Top

This part gets overlooked, but it makes a big difference. A short intro at the top of the magazine helps your team know:

• What this is

• What projects it’s based on

• Who it’s for

Example:

This insight magazine brings together findings from five recent studies focused on onboarding experiences (2023–2024). It’s designed to support teams working on sign-up, account creation, or early activation. Includes highlights from interviews, usability tests, and diary studies.

How to Keep It Useful Over Time

The best part about Insight Magazines is that they don’t have to be final. I treat them like working documents. Every few months, I:

• Add a few new quotes from recent studies

• Rewrite sections if patterns have changed

• Remove anything that’s no longer relevant

It takes me less than an hour. And it means I don’t have to start over the next time someone asks me for a synthesis.

Step 5: Share + Operationalize Your Insight Magazine

Once your Insight Magazine is live, the next part is getting it into the hands of the people who need it before they forget they even asked for it.

I’ve had projects where the research was solid, the quotes were rich, and the patterns were clear. But no one used it. Not because they didn’t care, but because I didn’t share it in a way that made it feel useful or relevant. It sat in a folder, unclicked.

So I started changing how I share. I focused less on the “ta-da” moment of launching a synthesis and more on building small habits around reuse. I stopped thinking of research as a one-time delivery and started treating it like a shared resource, something people could go back to again and again without needing me to walk them through it.

How to Share Your Insight Magazine

Step 1: Share It With a Clear Intro, Not Just a Link

One of the biggest mistakes I used to make was just dropping a link in Slack and hoping people would click it. They usually didn’t.

Now I treat the first message like a mini pitch. Not in a salesy way, just in a way that answers the questions they didn’t ask out loud:

• What is this?

• Why should I care?

• What can I use it for?

Example message I’ve sent:

Pulled together everything we’ve learned on onboarding friction across five projects, including trust issues, unclear copy, and some standout UX wins that made people feel confident. If you’re working on anything related to sign-up or early activation, this should be useful. Link: [Insert Magazine]

That one message usually does more than any deck I’ve ever made.

Step 2: Embed It in Strategic Places

People won’t go looking for research. It’s just how work happens. So I put the Insight Magazine in places where they’re already working.

Where I embed the link:

• In product briefs, under “Relevant Past Research”

• At the top of Notion pages for upcoming initiatives

• Inside strategy decks or team rituals (like “Week Ahead” or sprint planning)

• In feature specs, often in the background or rationale section

Every time I do this, I add one line of context. Something like:

“Full synthesis on onboarding friction lives here, with tagged quotes and section summaries.”

That line gives permission to explore without making it feel like homework.

Step 3: Reference It in Conversations

This is probably the most important part of the entire step. Because most decisions don’t happen inside documents. They happen during chats, planning calls, and Slack threads.

I make a point to reference the Insight Magazine when:

• Someone asks a question I’ve already answered in past research

• We’re in a meeting discussing a decision that touches on that topic

• A PM or designer is doing early exploration and needs context

It usually sounds like this:

“We actually covered that in our onboarding work. Want me to pull a few quotes?”

Or:

“That’s already in the onboarding magazine, there’s a section on trust signals that breaks it down.”

Once you build the habit of referencing the magazine like it’s part of your toolkit, others do too. And it starts becoming the default place people look before kicking off new work.

Step 4: Make It Easy to Ask for More

I usually add a prompt at the top of the Insight Magazine that says something like:

“Need this expanded or want to add a new section? Just ping me.”

This does two things:

1. It makes people feel like the research isn’t locked or final.

2. It gives me a signal when something’s missing.

I’ve had two clients ask to “add a section” on competitor reactions based on that note. I didn’t plan to do it, but I had the data already, it just hadn’t made it in yet. So I tagged the highlights, dropped them in, and let them know it was updated.

Step 5: Track Whether It’s Working

I don’t use complex analytics here. I keep it simple. I watch for:

• Repeat clicks (does the same person come back to it?)

• Reuse (do quotes from the magazine show up in strategy docs?)

• References (do people start linking to it in other threads or meetings?)

Even if you don’t have built-in analytics, you can spot these signs:

• “I saw that quote in your magazine, can I use it in our deck?”

• “Let’s check the magazine before we rerun another study.”

When I hear that, I know the magazine’s doing its job.

Step 6: Refresh It Every Quarter

I block time on my calendar every three months to check in on the Insight Magazines I’ve created. This doesn’t have to be a full overhaul.

Here’s what I do:

• Scan for any broken links or outdated examples

• Add a few new quotes from recent projects, if they fit

• Update the intro if the audience or focus has shifted

• Archive any sections that are no longer in use

It usually takes me about 45 minutes. And it saves me hours down the line when someone says, “Can we revisit our findings on onboarding trust?”

Step 7: Build Reuse Into Team Norms

Once I’ve shared a few magazines and seen that they’re landing well, I start to introduce the idea of reuse as part of team habits.

I’ll say things like:

• “Before we start this round of interviews, let’s check what we already have on this.”

• “Can we build this planning doc off the onboarding magazine?”

• “The quotes for this section are already tagged. Should we copy from the Insight Magazine?”

Sometimes I even build a short checklist into a kickoff doc that says:

• Have you checked existing Insight Magazines?

• Do we already have past findings tagged on this topic?

Over time, this starts to shift the default from “start new” to “start with what we have.”

Wrapping It All Up

If you’ve made it this far, you already know research isn’t just about what we learn. It’s about what gets remembered, reused, and shared. The goal isn’t to impress people with how much work we did. It’s to make what we learned so accessible and useful that it actually changes what teams do next.

That’s what this workflow is about.

It’s not about building a perfect repository or creating the most beautifully tagged quote board on the planet. It’s about building a system that works for you and the teams you support. One that helps you avoid starting from zero every time someone kicks off a new project.

If you’re tired of repeating the same insights in every meeting, tired of being the only person who remembers that one thing that user said three quarters ago, or tired of scrambling to find “that slide from the other deck,” then this is your out.

Build a tagging system that you can actually stick to. Group themes the way people actually talk about them. Share quotes the way you’d share advice, straightforward, short, and honest. And when it’s time to package it all up? Make it skimmable. Make it something you’d want to find if you were the one building a roadmap or writing a brief.

When I started doing this, I didn’t expect it to stick. But it did. Teams stopped asking me for decks. They started asking me to update the Insight Magazine instead. Stakeholders came to meetings already quoting users. I even had a product lead tell me she now checks past magazines before writing new OKRs. That’s when I knew it was actually working.

You don’t need to overhaul everything to start. You can try it with one project. Tag five great quotes. Write one Insight Magazine. Share it once. See what happens.

That’s how I started. Not with a grand plan, but with a problem I was tired of solving over and over again.

Now I have a growing system that actually makes my work more visible. Not louder—just easier to find, easier to use, and harder to ignore.

So if you’re thinking, “I don’t have time for this,” I hear you. But I’ll say this: the time I’ve saved not re-explaining past research is worth every minute I spent tagging or writing summaries.

The goal isn’t perfection. It’s momentum. One tag. One theme. One quote. One page that makes someone say, “Oh, we already know that.”

That’s the win.

If you’re tired of repeating work, answering the same questions, or being the only person who remembers what happened last quarter, this workflow is worth trying.

You can start a 30-day free trial with Condens here:

Make your insights hub

Paid subscribers get the power tools: the UXR Tools Bundle with a full year of four top platforms free, plus all my Substack content, and a bangin’ Slack community where you can ask questions 24/7. Subscribe if you want your work to create change people can feel.

Subscribe now

If you’ve ever spent weeks on a research report only to have stakeholders skim it, misinterpret it, or worse, ignore it entirely, you’re not alone.

No matter how great your research is, if you don’t communicate it well, it won’t have an impact.

This realization hit me early in my career when I spent three weeks crafting a beautifully detailed 30-page research report. I presented it to the product team with excitement, only to hear:

• “Can you summarize the key takeaways in a few sentences?”

• “So… what do you actually want us to do with this?”

• “I didn’t have time to go through everything, can we just chat?”

I was crushed. All that effort, and they weren’t even reading it. That’s when I realized I was structuring my reports the wrong way.

Fast forward to today, and I structure every single research report using The Pyramid Principle and it has changed everything.

Now, my reports don’t just get read. They drive real product decisions.

If your reports keep landing with a dull thud, it’s rarely the research and it’s usually the structure. Paid subscribers get the full Pyramid Principle system I use to write reports stakeholders can skim in two minutes. Inside the paywalled section, I share:

• my exact “first sentence” formulas (by study type)

• a copy/paste report skeleton with headings you can reuse every time

• a simple way to choose 2–4 “key arguments” without dumping your whole findings list

• examples of weak vs strong insight statements, rewritten into stakeholder-ready language

• how I package evidence so it reads like a case, not a data dump

• the “action plan” block that stops the “so what?” question before it shows up

• a finished example you can mirror for your next report

Exclusively for paid subscribers

Read more

In this video conversation, I discuss:

• The five-layer insight question model as a framework to extract progressively deeper, more actionable insights during synthesis.

• How AI tools like Breyta can enhance efficiency by surfacing themes across transcripts, but require human interpretation to avoid misdirection or hallucination.

• The difference between broad, hard-to-action pain points and layered, specific insights that drive meaningful change.

• Strategies to test AI’s usefulness by layering questions tied to stages, products, goals, and user segments.

Key takeaways:

1. Layered questions make insights more actionable. Using top-level questions like “What are the main pain points?” only gives broad strokes. By layering questions, adding context like journey stage, feature, or goal, you surface insights that teams can actually act on. For example, identifying pain points with a specific booking feature during the consideration stage reveals usability issues the product team can directly address.

2. AI tools help, but they don’t replace your thinking. Tools like Breyta can accelerate the synthesis process by scanning multiple transcripts and identifying recurring themes. But they don’t do the analysis for you. You still need to critically evaluate what’s surfaced, connect dots, and build context. You’re not outsourcing the insight, you’re speeding up how you get there.

3. Nuance creates opportunities. Broad findings like “travel schedules are inconvenient” are often not feasible for teams to act on. But when you dig deeper, like discovering that Gen Z values maximizing time at a destination, you can reframe pain points into strategic product opportunities, such as promoting early arrival flights or flexible departure windows.

4. Efficiency opens the door for creativity. AI helps you explore insights you may not have had time to look into. That “interesting quote” from a few users that would usually get dropped? You can now ask precise questions to explore whether it’s a larger pattern worth surfacing.

5. Copy-paste is not the goal. Even with AI tools, insight creation remains a deeply human job. The goal isn’t to take what the tool gives you at face value, it’s to use it as a springboard. Combine it with your notes, memory of interviews, secondary research, and strategic lens to shape insights that are not just descriptive, but directive.

The 5-layer template:

Grab the 5-layer insight question template here and try it out with your next project (or with a project you recently did!).

Try Breyta:

Want to try this out on Breyta? You can grab an extended free trial below

Try Breyta

Interested in sponsoring the podcast?

Interested in sponsoring or advertising on this podcast? I’m always looking to partner with brands and businesses that align with my audience. Reach out to me at nikki@userresearchacademy.com to learn more about sponsorship opportunities!

If you want to see everything I post, subscribe below!

Subscribe now

Hello Curious Human!

One of the toughest challenges I came across wasn’t necessarily conducting the actual research but getting stakeholders to care about and act on that research. You might have been in a similar place presenting your findings, hoping the insights will lead to decisions and changes, but instead, you’re met with polite nods, a few questions, and ultimately…crickets.

What if you could turn this around? What if you could make user research not just informative but engaging—even fun?

In this article, I’ll guide you through 10 ways you can integrate games into your user research process to engage stakeholders. You’ll learn specific, actionable techniques that you can implement in your next project, whether you’re running usability tests or gathering insights for strategic decisions.

Why Gamify User Research?

Let’s start with the obvious question: Why bother turning user research into a game? Isn’t that trivializing the work?

Not if you do it right.

By introducing game-like elements into the process, you make it easier for stakeholders to connect with your research, understand its importance, and even actively contribute to the findings. The key is to keep the focus on the insights while making the experience more memorable and impactful for everyone involved.

Games tap into our natural instincts for competition, problem-solving, and fun. When we play, we become engaged, focused, and, crucially, more likely to retain information. When done correctly, games can make your research a shared experience, which means stakeholders won’t just hear your insights—they’ll remember and care about them.

Here’s how to make that happen.

1. Usability Bingo: Turning Feedback into a Game

Usability Bingo transforms a typical usability test into an interactive experience for stakeholders. By giving them Bingo cards filled with common usability issues, this game forces stakeholders to pay close attention and actively engage with what they’re seeing. The simple act of crossing off a square whenever they notice a problem keeps them alert and involved, making post-test discussions more effective.

Goal: Increase engagement during usability testing by making it a game.

When to Use It: Ideal for usability tests where stakeholders need to observe and recognize patterns in user behavior. Use this when stakeholders tend to disengage during observation sessions.

How to Set It Up:

1. Create Bingo Cards: Fill each square with common usability issues relevant to your product (e.g., “user hesitates before clicking,” “user struggles with navigation”).

2. Distribute Cards: Hand out the Bingo cards to your stakeholders before the session begins.

3. Explain the Rules: Stakeholders mark off each issue they observe during the test. The first to complete a row, column, or diagonal wins a small prize.

4. Debrief After the Session: Discuss the Bingo cards and the issues identified, making the post-test debrief more dynamic.

2. Internal Hackathons: Get Stakeholders to Solve the Problems

An Internal Hackathon turns research insights into actionable solutions by putting stakeholders in problem-solving mode. You gather them into teams, provide them with the challenges uncovered during research, and let them brainstorm and prototype solutions. The competitive aspect encourages creativity and deep engagement, ensuring they feel responsible for the outcomes.

Goal: Encourage collaboration and creative problem-solving among stakeholders based on user research findings.

When to Use It: Use this after presenting research insights to involve stakeholders in generating solutions, especially when multiple departments are involved.

How to Set It Up:

1. Present the Challenges: Based on your research findings, present a series of challenges or pain points that need solving.

2. Form Teams: Divide stakeholders into small teams with mixed expertise (e.g., product, design, marketing).

3. Set a Time Limit: Give teams a clear amount of time to brainstorm, prototype, or sketch out solutions (e.g., two hours).

4. Showcase Solutions: At the end, each team presents its solution, followed by a discussion of how these solutions can be implemented.

3. Pin the Pain Point on the Persona: Mapping Stakeholder Insights

This interactive game helps stakeholders internalize user pain points by visually mapping them onto user personas. Think of it as an improved version of “Pin the Tail on the Donkey.” Stakeholders write down the pain points they believe each persona is experiencing and then “pin” them on a large printout of the persona. The result is a visual, collaborative way to understand where stakeholder assumptions align—or differ—from the research.

Goal: Help stakeholders understand and empathize with user pain points by mapping them to personas.

When to Use It: Use this when introducing personas to stakeholders or when correcting stakeholder assumptions about user pain points.

How to Set It Up:

1. Prepare Persona Posters: Print out large versions of your key personas and hang them on the wall.

2. Hand Out Post-its: Give each stakeholder a stack of Post-its and ask them to write down the pain points they believe this persona is facing.

3. Pin the Pain Points: Stakeholders place their Post-its on the appropriate areas of the persona (e.g., motivations, behaviors, frustrations).

4. Debrief: Discuss the pain points that were pinned and how they align with your research findings, opening up discussions on misaligned assumptions.

4. UXR Escape Room: Escape the Inefficient Tasks

Read more

If you want to see everything I post, subscribe below!

Subscribe now

Hi there, curious human!

I’ve received quite a lot of questions on the topic of estimating potential product improvements based on insights. I talk a lot about how important it is to report insights in terms of outcomes like:

• Fixing the navigation could reduce drop-off rates by 20%, which would boost conversions by 15%

• We need to redesign the onboarding flow to reduce friction, starting with a simpler first step. This will lead to a 10% increase in user retention

Seems simple? Just put some interesting numbers in there and huzzah, we have buy-in. But, honestly, I didn’t start my career doing this and it took me years to understand how to put numbers to my findings and insights.

However, when I started doing this, the change was transformative. People paid attention, listened, didn’t zone out during reports, and even prioritized my work. Stakeholders need to understand the value of your insights. It’s not enough to report findings; you need to show how implementing your recommendations will drive measurable outcomes.

By learning to estimate improvements, you become not just a researcher but a strategic partner in product development.

But how do we really do that? Especially if we are more geared toward words rather than numbers. Here is my step-by-step process for estimating improvements and relating numbers back to my research.

Step 1: Define the target metric

The first step is to identify the specific product metric your recommendation will impact. This ensures your research aligns with measurable outcomes.

How to define the metric:

1. Understand business goals: Meet with stakeholders to identify the metrics they prioritize. Common examples include:

   1. Conversion rates: Percentage of users who complete a desired action (ex: sign-ups, purchases).

   2. Retention rates: The proportion of users returning over a defined period.

   3. Drop-off rates: Percentage of users abandoning a flow (ex: onboarding).

   4. Engagement metrics: Time spent, number of sessions, or feature usage.

2. Align metrics with insights: Choose a metric directly related to the problem uncovered in your research. For example, if users abandon onboarding, focus on the onboarding completion rate.

3. Document the target metric: Write down the specific metric so you stay aligned during the estimation process. For example:

   1. Finding: Users drop off at Step 3 of onboarding due to a confusing form

   2. Metric: Onboarding completion rate

Step 2: Gather baseline data

To estimate an improvement, you need a clear understanding of the current state of the metric—this is your baseline.

How to collect baseline data:

1. Access analytics: Use tools like Google Analytics, Mixpanel, or Amplitude to gather current metrics. If you don’t have access, collaborate with your product or data teams and ask them how they measure analytics.

2. Record key data points:

   1. Current value: What is the current metric value? For example, a 60% onboarding completion rate.

   2. Affected population: How many users does this metric represent? For example, 10,000 users go through onboarding monthly.

   3. Segments: Are there specific groups (mobile users, international users) with different behaviors?

3. Visualize the data: Create a chart or table summarizing baseline data for easy reference.

Step 3: Craft a hypothesis

A hypothesis links your research insights to a measurable improvement. It includes three elements:

1. The problem: What is causing the issue?

2. The solution: What are you proposing to solve it?

3. The expected outcome: What measurable improvement will result?

How to write a hypothesis:

Identify the problem

Use your research findings to articulate the issue:

• What’s happening? Users drop off at Step 3 of onboarding.

• Why is it happening? The form has too many fields, causing friction.

Propose a solution

Define a specific, actionable recommendation tied to the problem. For example: Reduce the form fields from 10 to 5 to simplify onboarding.

Estimate the improvement

This is the most challenging part for many researchers. Follow these steps:

1. Use past data: If similar changes were made previously, analyze their impact. For example: Simplifying a checkout process in the past improved conversion rates by 8%.

2. Leverage industry benchmarks: Research typical improvements for similar changes. For example: UX benchmarks show that reducing form fields can improve completion rates by 5-15%. You can use the following places to research this information:

   1. Nielsen Norman Group (NNG)

   2. Baymard Institute

   3. Forrester Research:

   4. Gartner

   5. Open Data Institute

   6. Kaggle Datasets

   7. ACM Digital Library

3. Analyze the room for improvement: Look at the size of the problem. If 40% of users drop off at Step 3, aim to reduce drop-offs by 10-20%.

4. Be conservative: Use a cautious estimate for initial predictions (ex: 5-10%).

Example hypothesis:

Reducing form fields will reduce drop-offs by 10-15%, increasing onboarding completion rates from 60% to 65-70%

Step 4: Model the potential impact

Once you have a hypothesis, calculate the impact of your proposed change on the metric. This involves applying the improvement percentage to the baseline data.

How to calculate the impact:

Identify the affected population.

Determine the number of users impacted by the metric:

• 10,000 users go through onboarding monthly

Apply the improvement percentage

Use the formula:

Improved Metric = Baseline Metric * (1 + Improvement Percentage)

Example:

• Baseline completion rate = 60%

• Improvement estimate = 10%

60% * (1 + 0.10) = 66%

Quantify the results

Calculate the number of additional users completing the flow:

Additional Users = Total Users * Improvement Percentage

Example:

10,000 users × 10% = 1,000 additional completions.

Translate into business value

If possible, calculate the financial or business impact. If each completion generates $20 in revenue:

1,000 * 20 = $20,000 additional monthly revenue

Step 5: Evaluate your hypothesis

Evaluating your estimate ensures your recommendation is grounded in reality. Use these methods to refine your predictions. You can do this through:

1. Usability testing: Test your proposed changes with a small group of users in a controlled environment to observe how they interact with the new design or feature.

   1. Create a prototype or mockup of the proposed solution.

   2. Ask users to complete tasks using the new design and measure success rates, time on task, or satisfaction.

   3. Compare results to the baseline behavior observed with the current design.

2. Wizard of Oz testing: Simulate the new experience without building the full solution. The user interacts with what appears to be a functional system, but parts are manually operated behind the scenes.

   1. Set up a partially functional prototype where manual effort substitutes for backend functionality.

   2. Observe how users engage with the simulated change and gather feedback on their behavior and satisfaction.

3. Split funnel analysis: Instead of comparing users in two distinct groups (as in A/B testing), analyze different stages of the user journey to identify where the proposed change would have the most significant impact.

   1. Break down the user journey into smaller steps (ex: Step 1: Account creation, Step 2: Onboarding completion).

   2. Identify where drop-offs occur and use the data to test small changes in targeted areas of the funnel.

4. Scenario modeling: Model the potential impact of your proposed solution by simulating changes in metrics based on user behavior patterns and historical data.

   1. Use historical data to model “what if” scenarios for the change. For example: “If 20% of users who currently drop off at Step 3 continue instead, how would completion rates change?”

   2. Compare modeled results to real-world observations after implementation.

Step 6: Communicate the findings

Presenting your estimates clearly and persuasively is key to gaining stakeholder buy-in.

1. Start with the problem: “40% of users drop off during onboarding due to a complex form.”

2. Propose the solution: “Reducing the form fields from 10 to 5 will simplify the process.”

3. Share the estimated impact: “This could increase the onboarding completion rate from 60% to 66%, adding 1,000 new users per month and $20,000 in monthly revenue.”

Impact estimation template

Step 1: Define the problem

• What’s the issue?

  • Example: 40% of users drop off at Step 3 of onboarding due to a complex form.

• What’s the impact?

  • Example: This results in a 60% onboarding completion rate and a loss of potential revenue.

Step 2: Proposed solution

• What’s the change you’re recommending?

  • Example: Simplify Step 3 by reducing form fields from 10 to 5.

• Why does this solve the problem?

  • Example: User feedback indicates that long forms are a primary pain point.

Step 3: Target metric

• What metric does this impact?

  • Example: Onboarding completion rate.

Step 4: Baseline data

• Current metric value:

  • Example: 60% completion rate.

• Affected population:

  • Example: 10,000 users start onboarding each month.

Step 5: Hypothesis

• Expected improvement range:

  • Example: Reducing form fields will increase completion rates by 10-15%.

• Data source/benchmarks for the estimate:

  • Example: Historical data shows similar changes improved completion rates by 12%.

  • Example: UX industry benchmarks indicate a range of 5-15% for form simplification.

Step 6: Modeled impact

• New metric value:

  • Example: 66-69% completion rate (10-15% improvement on 60%).

• Additional users completing onboarding:

  • Example: 1,000-1,500 additional users monthly.

• Business impact:

  • Example: If each completed onboarding generates $20 in revenue, this adds $20,000-$30,000 per month.

Step 7: Evaluation plan

• How will you evaluate the hypothesis?

  • Example: Conduct usability testing with a prototype.

  • Example: Run a cohort analysis to track behavior over time.

Step 8: Next steps

• Develop a simplified prototype for testing.

• Evaluate the hypothesis.

• Share results and adjust the estimate as needed.

Estimating potential improvements transforms your research from observation to actionable strategy. It allows you to connect user needs with business goals, ensuring your insights drive measurable change. By presenting clear, data-backed outcomes, you build trust with stakeholders and increase the likelihood of implementation. This practice not only amplifies the impact of your work but also positions you as a strategic partner in product development. Over time, this approach strengthens your credibility and helps you deliver meaningful results for both users and the business.

Is there anything that’s worked super-well for you that I didn’t mention or that you totally agree with? Share in the comments 🙏

Leave a comment

📚 Additional resources to explore

1. Use these simple formulas to show research ROI

2. Deliver research insights that demand action, with zero guesswork

3. Top questions to my UXCon Vienna presentation

4. A Guide to Writing Effective Research Reports

The Impact Membership : A space for user researchers who think bigger

You know your craft. You’ve run the studies, delivered the insights, and seen what happens when research is ignored. You’re ready to go beyond execution and start making real strategic impact but, let’s be honest, that’s not always easy.

That’s where the Impact Membership comes in.

This is not another free Slack group or a place to swap survey templates. It’s a curated community for mid-to-senior user researchers who want to:

• Turn research into influence – Get insights to stick, shape product and business strategy, and gain real buy-in.

• Break out of the research silo – Learn from peers facing the same challenges and work through them together.

• Stay sharp and ahead of the curve – Dive deep into advanced research strategy, stakeholder management, and leadership.

Why join now?

• You don’t have to figure this out alone – Every member is carefully selected, so you’re learning alongside people who truly get it.

• Get real value, fast – No fluff, no generic advice—just focused conversations, expert-led sessions, and practical guidance you can use right away.

• Make it work for you – Whether you want to participate actively or learn at your own pace, there’s no pressure—just a space designed for impact without overwhelm.

Membership fee: £627/year or £171/quarter

This isn’t just about keeping the lights on. Your membership funds exclusive research initiatives, high-caliber events, guest speakers, and a space that actually pushes the field forward.

Spots are limited because we keep this community tight-knit and high-value. If you’re ready to step up and drive meaningful change through research, we’d love to have you.

Join today

Stay curious,

Nikki

1. The User Research Round-Up: CW 38

2. Episode 83: Membership Spotlight - Giulia Tumminelli on Transitioning from Product to UXR

3. How to Mentor Other User Researchers

4. The User Research Round-Up: CW 36

5. Work With Me: Building a Research Plan for a Consultancy Client

6. Episode 82: Manager or Individual Contributor?

Subscribe now

Hello, Curious Human!

I recently had a talk at 2024 UXCon Vienna about articulating the strategic value of user research. You can download the slides below (please give credit if using/referencing the slides):

Nikki Anderson Uxcon Vienna 2024

14.6MB ∙ PDF file

Download

Download

Some key takeaways from my talk:

1. Stakeholder interviews are integral to understanding what they need so that you can pitch impactful research

2. Two frameworks for writing and presenting your insights strategically

3. Several formulas for calculating how your research can impact the bottom line (a full article on that coming)

I couldn’t answer all the questions that came up, but the fantastic team sent me the captured questions, so I wanted to give some answers to those who asked great questions that needed more depth than I could reach within the 20-minute talk.

Prefer to listen to an overview? Listen on YouTube or below.

This audio is created with NotebookLM

Q: How can I calculate the ROI of the insights obtained from qualitative studies?

Calculating the ROI of qualitative insights may seem tricky because these insights don’t typically come with numerical data attached. However, they can lead to actions that result in measurable outcomes. Here’s how I quantify the value they bring:

1. Link insights to actionable changes

The first step is to identify the business actions directly influenced by the qualitative insights. Did the insights lead to a change in product design, marketing strategy, or customer experience? The more concrete the actions, the easier it will be to measure the impact.

Keep in mind that you might have to wait a little bit to tie your qualitative research to metrics because these things take time, and that is okay.

2. Measure the outcome of these actions

Use traditional business metrics to measure the outcome. For example:

• Revenue impact: If the insight led to a product feature improvement, track how this affected customer acquisition, conversion, or retention.

• Cost savings: If the insight reduces customer support tickets or operational inefficiencies, calculate the associated cost savings.

3. Use comparative metrics

Compare the “before” and “after” states of a key metric. For instance, if a design change based on qualitative research reduced the drop-off rate on a webpage from 50% to 30%, quantify the additional users retained and project their value in terms of sales or conversions.

B2B example:

Imagine a SaaS company that conducts qualitative interviews with enterprise customers and discovers that a particular dashboard feature is confusing. The company changes the feature, and over the next three months, they see a 15% reduction in churn. By calculating the lifetime value (LTV) of the retained customers and multiplying that by the number of customers saved, they can estimate the financial impact.

B2C example:

A retail company conducts user interviews and discovers that customers are abandoning their carts due to unclear shipping policies. They adjust the website copy and streamline shipping options. In the next quarter, they notice a 10% improvement in conversion rates. The revenue generated from these additional sales can be compared against the cost of conducting the research to determine ROI.

Q: How can we articulate the consequence of insights from exploratory/strategic research when the opportunity can’t yet be connected to KPIs or $$$?

Exploratory research often provides insights that influence long-term strategy, which can be hard to tie immediately to financial metrics. I’ve struggled with this myself. However, there are ways to communicate the strategic value effectively:

1. Link insights to company goals

Start by connecting the insight to broader company goals. For instance, does this insight contribute to innovation, product-market fit, or competitive differentiation? Even if the dollar impact isn’t immediate, you can articulate its role in driving the company toward key strategic objectives.

2. Frame in terms of potential impact

Use hypothetical scenarios. While you may not have data yet, you can model what success would look like if the opportunity were realized. For example, “If we can address this user pain point, it could lead to a 20% increase in adoption of this new product.”

3. Use risk mitigation language

Highlight what’s at stake if the company doesn’t act. Often, exploratory research helps mitigate future risks. Articulating the cost of inaction—such as market share loss or missed opportunities—can be just as compelling as presenting potential gains.

4. Work with others to understand the holistic consequence

One of the best things I’ve ever done is collaborating with other departments to understand, more holistically, what my insights might mean. I’ve gone to marketing, sales, account management, customer support, and other departments to share my findings and to understand how it might impact areas outside the immediate product. Make meetings with these colleagues to discuss how your findings could be relevant to their areas and goals as well.

B2B example:

For a B2B company exploring a new market, research reveals that customers are hesitant to adopt the product due to a lack of clear integration with their existing tools. While you can’t yet quantify the exact revenue lost, framing it as a potential barrier to entry for a $10 million market opportunity can emphasize the importance of addressing the issue.

B2C example:

For a B2C app targeting young users, exploratory research might reveal a growing trend in voice-activated commands. While it may be hard to quantify the financial impact immediately, you could frame it as a strategic investment to stay ahead of competitors who might capitalize on this trend if ignored.

Q: How do you avoid recommending approaches that increase revenue, but hurt your users or stakeholders?

Balancing the need to drive revenue while maintaining user satisfaction is critical, and can sometimes be a tricky thing to balance. Typically we can feel like our hands are tied — I remember a need for introducing a service fee to save the business that could have had an extremely negative impact on users. You can achieve this balance by following a user-centric approach that ensures business goals align with user needs.

1. Prioritize user feedback

Begin by deeply understanding your users’ pain points and motivations through research. Make sure any recommendations for revenue-generating changes align with these insights. And, if they don’t, understand what it is you are “giving up” when it comes to the user’s side.

2. Impact assessment

Before recommending any approach, conduct an impact assessment to weigh the benefits against potential drawbacks for users and stakeholders. Ask: “Will this drive short-term revenue but erode long-term trust?”

3. Create a balanced scorecard

Implement a balanced scorecard approach that includes metrics for both revenue and user satisfaction (ex: UMUX/SUS, churn rate). For every revenue-generating idea, evaluate its impact on these non-monetary metrics to ensure a sustainable approach.

B2B example:

A software company wants to increase revenue by adding premium features to its base product. However, qualitative feedback shows that customers are already frustrated with existing complexity. Rather than introducing more complexity for a revenue boost, the company decides to simplify the core product first and then introduce premium features based on user feedback, maintaining both revenue growth and customer satisfaction.

B2C example:

A streaming service considers increasing subscription prices to drive revenue. However, user surveys reveal dissatisfaction with the current content-to-price ratio. Instead of a blanket price hike, the company introduces flexible pricing tiers, ensuring that users feel they’re getting value at different price points. This approach sustains both revenue and loyalty.

Q: How do you create a safe space for both you and the stakeholders during a stakeholder interview on your work? I imagine it can be uncomfortable.

Creating a safe and productive space during stakeholder interviews is absolutely necessary especially when discussing potentially sensitive or uncomfortable topics. However, I’ve had a hard time in the past with trying to talk to stakeholders that were not only skeptical of my work, but also ones I had previously yelled at (you read that right) in the past.

After some years of holding these interviews, here’s how you can help to establish trust and openness in these interviews:

1. Set expectations early

At the beginning of the interview, set the stage by explaining the purpose of the discussion. Make it clear that the goal is to gather insights that will help everyone, not to assign blame or make anyone uncomfortable. Mention that the session is meant to be collaborative and solution-focused.

2. Use empathetic listening

Demonstrate empathy by actively listening to the stakeholder’s concerns. Reflect on their statements to show you understand their perspective. Avoid interrupting, and allow space for them to express their thoughts freely.

The same techniques that we apply in research sessions with participants are relevant here — make them feel heard and understood and remind them you are there to support them.

3. Ask open-ended, non-confrontational questions

Structure your questions to be open-ended, focusing on the stakeholder’s experiences and pain points rather than probing for specific failures. For example, instead of asking, “Why didn’t this project meet its goals?” try, “What were some of the challenges you faced during the project?”

4. Acknowledge vulnerability

Show vulnerability yourself by acknowledging that some topics may be difficult to discuss. For example, you might say, “I know discussing challenges can sometimes feel uncomfortable, but understanding them helps us work together to improve.”

5. Ensure confidentiality

If needed, assure the stakeholder that the feedback will be handled with care, and sensitive comments will remain confidential. This builds trust and encourages more open communication.

B2B example:

In a B2B setting, imagine you are interviewing a key decision-maker about why user research findings haven’t been fully implemented. You could start by asking, “Can you walk me through your thought process during the last implementation phase?” This framing shifts the focus to understanding the context rather than assigning blame.

Creating a safe space here allows the stakeholder to feel comfortable sharing internal challenges, like budget constraints or team dynamics, that may have impacted the decision-making process.

B2C example:

For a consumer-focused product team, you might interview a stakeholder in the marketing department about the challenges of aligning marketing efforts with product research. A question like, “What can I do to make research findings more actionable for your team?” opens up a constructive conversation. This approach can reveal gaps in communication or resources that you can work to resolve together, creating a sense of collaboration.

Q: We usually conduct qualitative studies. Is it appropriate to convert qualitative findings into quantitative insights (to calculate ROI)?

Yes, qualitative insights can and should be converted into quantitative data to help calculate ROI when necessary. While qualitative research provides depth and understanding, quantifying these insights helps communicate the value in business terms, making it easier to measure impact.

1. Identify themes and patterns:

After conducting qualitative research, identify recurring themes. For instance, if multiple users mention confusion with a specific feature, this insight could form the basis for quantification.

2. Quantify the frequency

Estimate how widespread the issue might be across your entire user base by quantifying how often these themes occur in your qualitative research. You could say, “50% of the users we interviewed expressed confusion about this feature.” This gives you a starting point to project the impact.

3. Estimate the business impact

If the insight suggests that an issue may cause users to abandon a product, you can estimate the revenue lost as a result. For example, if 30% of interviewed users indicated confusion with checkout options and your total user base experiences a similar issue, you can calculate potential lost sales based on conversion rates.

4. Run experiments to evaluate insights

You can also use A/B testing or surveys to turn qualitative insights into quantifiable data. For example, after redesigning a confusing feature based on qualitative feedback, you can run a survey to ask users whether the change improved their experience, and compare this to conversion metrics.

B2B example:

A B2B SaaS company conducts interviews and discovers that several clients find a reporting feature confusing. You estimate that this confusion affects about 20% of clients. If your average client contract is worth $100,000 annually and those 20% are at risk of churn due to dissatisfaction, you could project a potential $2 million revenue risk. This provides a clear ROI incentive to improve the feature based on qualitative insights.

B2C example:

A clothing e-commerce site finds through user interviews that customers often abandon their shopping carts due to unclear return policies. By conducting a survey or looking at session recordings, you can estimate that 10% of users drop off for this reason. If this represents a potential $50,000 per month in lost sales, clarifying the return policy could recover a significant portion of that revenue, providing a measurable ROI.

Q: What tooling/methods do you recommend for these measurable insights? Currently, we don’t have the numbers, making it challenging to give an indication of revenue.

When you don’t have existing data to quantify insights, there are several tools and methods you can use to gather the necessary numbers. These tools will help you turn qualitative insights into measurable outcomes and link them to business metrics such as revenue, customer retention, or cost savings.

*I have no relationship to the tools mentioned, they are simply tools I’ve used in the past.*

1. Set Up analytics tools

Tools like Google Analytics, Mixpanel, or Amplitude allow you to track user behavior, conversions, and drop-off points in real time. By understanding where users are having issues, you can quantify the size of the problem and estimate its impact on revenue.

2. A/B testing platforms

Platforms like Optimizely, VWO, or Google Optimize enable you to test different versions of a feature or product change to see which one performs better. These tests can give you concrete data about how a qualitative insight impacts metrics like conversion rate or retention.

3. Surveys and feedback tools

Tools like SurveyMonkey, Typeform, or Qualtrics help gather customer feedback at scale. You can survey users before and after making a change, asking them to rate their experience and satisfaction. This data can then be used to estimate the business impact of improvements based on qualitative feedback.

4. Heatmaps and session recordings

Tools like Hotjar and Crazy Egg provide heatmaps and session recordings that show how users are interacting with your website or app. This helps quantify how widespread an issue is and links qualitative insights (e.g., “users are confused by the layout”) to hard data (e.g., “30% of users never click past the first step of checkout”).

5. Revenue impact calculators

Many businesses use custom-built calculators to estimate revenue impact from product changes. These calculators typically factor in conversion rates, average order values, and user retention rates. You can input your qualitative findings (e.g., “20% of users mentioned frustration with a feature”) to see how much revenue might be at stake if the issue persists.

Please check all tools with your legal team prior to setting them up or trialing them!

B2B example:

A B2B marketing platform could use Mixpanel to track how users interact with their reporting dashboard. After identifying issues through user interviews, you can track how many users abandon the process before completing a report. You could also set up a targeted survey asking users to rate their satisfaction with the changes you implemented based on qualitative insights, helping you tie these improvements back to revenue or retention.

B2C example:

An e-commerce retailer could use Google Analytics combined with Hotjar to analyze how users navigate the site. If you notice a high drop-off on certain pages, you can introduce qualitative feedback via on-page surveys (“What stopped you from completing your purchase?”). Once you identify the issue, run A/B tests to validate any changes you make and use analytics to measure their direct impact on sales.

Those were all the questions — thanks to everyone who attended the talk and conference — I can’t wait for next year’s lineup!

Which of these questions resonated the most with you? Anything that I missed that you would add? Or anything in particular that you think you might try? Share in the comments!

Leave a comment

📚 Additional resources to explore

1. The current state of measuring return on investment in user experience design

2. How user research impacts the AARRR metrics

3. Use these simple formulas to show research ROI

4. Episode 48: Tracking OKRs and impact as a user researcher

5. Episode 36: Tracking impact on colleagues as a UXR

Stay curious,

Nikki

Resources:

• How to build a b2c persona

Subscribe now

I’ll say it:

Writing research reports can suck. Big time.

There are difficult things in user research that I’ve been able to get behind and actually start to enjoy like whiteboard challenges or stakeholder management. I even eventually got over my fear of writing case studies.

But, holy moly, there is something about writing a research report that still gets me. Like, even today with my consultancy clients, over ten years into this wonderful craft, I still get nervous writing research reports.

Why?

They are so important!

They are the story behind the data, giving people the information they asked for to make less risky decisions. They are the epitome of our research.

Maybe that sounds dramatic, but I honestly feel like effective reports can make or break how user research is viewed at an organization.

However, I didn’t always “believe” in research reports, just like for a while I didn’t “believe” in using quantitative data or surveys, or didn’t “believe” in personas — you might spot a trend: I didn’t believe in things I was scared of.

I tried to avoid writing reports by doing other things like demo desks, movie nights, and session snapshots (all of which I’ll talk about later). While there is nothing wrong with these methods of sharing research, there is still a time and a place for reports.

So, while I am still nervous about them, over the years, I’ve honed some effective report-writing skills and techniques, which, if you are on the same side of the report-writing fence, then hopefully they will help.

Let’s dive in.

What Goes Wrong with Research Reports

When I finally decided to tackle writing research reports and getting more comfortable with them, I knew I had to investigate all the things going wrong with my research reports. This struck true fear in me. I was all for constructive critcism, but I was also scared of it — what if I asked what was wrong and enough people recognized me as the impostor I felt I was?

It was less about receiving criticism and more about opening Pandora’s box to find out what was wrong, only for everyone to realize I had no idea what I was doing. There wasn’t a worse user research nightmare for me.

But, as I have found out again and again in my career, the best way to figure out what to do better is to uncover what’s going wrong. And there was no one better to do that with than my product managers, as they were (and are!) the users of my research reports — they would know best what was happening.

Although I often interview my stakeholders broadly when I join a company, and also send out stakeholder satisfaction surveys after most of my projects, this was a different kind of initiative. I wanted to pinpoint exactly what was going wrong with my reports, and I wanted to also reach out to previous stakeholders as well as product managers I knew but hadn’t directly worked with.

Basically, I wanted to run a research study on what’s wrong with research reports, both from a more personal level of what’s wrong with mine, and then, more generally, what stakeholders find painful about research reports. I decided this was likely the best way forward as it gave me a certain objectivity when it came to this topic — I was simply a researcher researching.

The Study

I recruited various stakeholders, focusing in on product/tech teams, such as designers, product managers, and developers, who had engaged with user research reports at least twice in the past three months. I decided on 1x1 interviews with a follow-up survey to help me understand the insights more broadly.

I ended up interviewing about twenty five stakeholders. Most of them ended up being product managers, with a few designers and developers. The feedback felt consistent across the various roles, with a few exceptions, so I decided at that point, not to do a phase two and three of research just looking into designers and developers.

My questions consisted of things like:

1. Walk me through the last time you engaged with a user research report, what was that experience like?

2. Describe the number one problem you had with the report.

3. Explain how you used the report, including the most useful information.

4. Talk me through the parts of the report less helpful, and why?

5. Tell me about a research report that was hugely successful. Why was it successful?

6. Describe a research report that you had a hard time with and why?

7. Tell me about the number one thing missing from research reports.

Each interview was about 60-90 minutes and stakeholders showed me direct examples (of my work, not others!) of what was going wrong and what was helpful for them. I swallowed my pride and watched as they walked me through their journey of using a report and all the pain points and barriers they encountered.

Let me tell you. It was FASCINATING.

Here are some of the quotes from the interviews:

“Long lists of factual information is not particularly helpful to me. I need something specific and insightful to take action on rather than just generalized themes or watered-down information. For instance, telling me the users were frustrated at the experience frustrates me. What about the experience is frustrating? What can we effectively change? If 8/10 people failed something, do we know why? What can we do to fix it? Overly vague statements (and lots of them), cause me to not want to deal with implementing research. It just takes too much more time and effort.”

“Trust me, I know I don’t know everything about users and that I make assumptions, just like every other human. But, when you don’t trust anything that I say that isn’t “backed by research,” I get frustrated because then you are presenting things I already knew. I’m all for evaluating our hypotheses, especially bigger bets that we really aren’t sure about, but the worst reports reiterate things that were pretty clear in the first place that don’t actually make a difference to what we can do.”

“Sometimes there are big opportunities that aren’t immediately feasible because of tech or business constraints, and we usually know that ahead of time. If you then present your research that’s all about these practically impossible things, it’s frustrating. I’d rather get data about things we can actually do — get a shared understanding from your stakeholders about what’s not possible and what they actually care about in that moment. What’s really relevant to them? What are they trying to enact change on? That’s the stuff we care about. Believe it or not, we want to make positive changes too.”

“Sometimes I wish researchers would run reports by me first. I’ve had projects put in such a harsh light, highlighting everything wrong with the project, that execs just kill the project before we can make improvements. Sure, some of them should be killed, but it’d be nice to get a heads up on such negative findings so I’m ready with a plan.”

“Create a shared understanding at the beginning of the project that aligns the purpose and expected outcomes — the worst thing I’ve received are insights that have nothing to do with my work or what I’m trying to deal with. A lot of discarded research is the result of the product manager thinking the research would cover certain topics, but the researcher does other things. This is not to say you won’t discover things outside the original outline of research questions, but the core questions have to be answered. Not answering the agreed-upon questions, or not even agreeing on any, is a huge waste of time for everyone.”

Because I hadn’t really dove into the nuances of people receiving these reports and having to do stuff with them, I didn’t really understand the ins-and-outs of the different barriers people encountered. Learning this was immensely helpful because it gave me a different perspective to go off when it came to writing my reports. I had tangible evidence and understanding of what wasn’t going as well.

But it wasn’t all bad. Here’s a list of what I found was helpful when it came to research reports:

• Being involved with the research and actually hearing the users talk or seeing the problems they are having

• Being able to craft and shape the research plan with the UX researcher so there is a sense of alignment and ownership of the project

• The research is relevant to the problems the stakeholder is facing and they have autonomy to act on the research

• Understanding the business questions that stakeholders are trying to answer so the most appropriate methods/approaches are picked

• The research comes at a time where it can still actually influence decisions — stakeholders seem to lose interest in a project that takes over six months to complete (unless previous specified)

• The researcher doesn’t let personal bias interfere with the results and they aren’t pushing negative sentiment where it’s not truly there

• A focus on presenting actionable insights, not just facts

• There is an understanding about the political nature of a company

• The report contains outputs that capture customer quotes, ideally some video clips to bring it to life

• The researcher partners with other departments, like analytics to bring some numbers and additional context. Seeing the whole picture is key

For once in my research life, it was good to understand what was working with the reports — typically as a user researcher, I focus on the negative and, when that was all I was looking at, I was overwhelmed. I realized that’s what my stakeholders must feel when I list a bunch of things that went wrong with their idea, prototype, or feature. From that moment forward, I decided to also include a slide of what was going well in my research reports.

And while all this information was good, I had to digest it and understand how I could bring it into action. Just like anything (and like stakeholders said), fact was not enough to take action on, it was time to turn the information into something actionable.

Making the Data Actionable

I took all of the interviews and used affinity diagrams to understand the bigger patterns and trends of what I needed to improve moving forward with my research reports. Unfortunately, I didn’t take screenshots with me so I lost all the diagrams, but I do remember (since I still use these principles!) what the overarching trends were.

I found four main themes:

Shared Understanding

Shared understanding and alignment on a project is literally one of the most critical things to set a research project up for success. I know that we’re talking about a report, which is at the end of the research process, but writing an effective report starts from alignment in the beginning.

If you and your stakeholders aren’t aligned with the project’s purpose, goals, and outcome, there is a good chance someone will be disappointed. My worst studies were when I went off and did research without truly understanding what my stakeholders needed from me. In the end, I would present the research, and people would be like, “Okay, cool, but we needed something else.” It was a devasting response.

When you ask your stakeholders what decisions they are trying to make and what information they think they need to make those decisions, creating a shared plan becomes much easier. You can even ask them what type of outcome they expect.

If your stakeholders are having a hard time articulating this type of information, you can give the following fill-in-the-blank:

I need (information needed) to answer (questions they have) by (x timeline) in order to make (the decisions they need to make).

I typically start every research project with a research plan in which I directly align with the stakeholders on the purpose, goals, decisions they are trying to make, and outcomes of the project. Using that direct information, I’m able to shape a study that makes sense based on what stakeholders are trying to understand, and we are all in agreement with what we’re trying to accomplish when speaking to users.

In addition to this research plan, I also like to have regular check-ins with stakeholders to ensure that we are continuing to go in the right direction with research. Now, I don’t always have these, for instance, if it is a straightforward research project that doesn’t need check-ins, but for longer and more complex studies, I like to check in every two weeks or so and update my stakeholders.

Context + Consequence

Just like quite a few stakeholders mentioned in the interviews, a list of facts isn’t particularly actionable. I really struggled with writing insights (check out this article for a very in-depth explanation of writing impactful insights) for a long time because I didn’t really understand what the buzzword actionable meant when it came to insights.

I would often write insights like they were facts without any context or consequence associated with them. This, coupled with not aligning properly with stakeholders’ needs, left me writing things that just weren’t helpful and were, ultimately, ignored.

Here are some “insights” I wrote a while back.

This is the dreaded list of “stuff” disguised as insights or findings. There is absolutely no context or consequence around these different bullet points. In fact, there is really nothing to do because there is not nearly enough information for anyone to take this information and make changes or meaningful decisions.

When I asked for examples of “unactionable” insights, stakeholders shared similar looking lists. Here’s another one of mine they brought up as a prime example:

People were immediately confused when they saw the first screen. Meh. Not great. Cringeeee.

These are good examples of information that lacks context and consequences that could make it actionable.

Again, I now tend to include a “what went well” slide just to reiterate to the team that there are certain things we shouldn’t or don’t have to change. I shied away from this because, when I used to do it, I think I went too overboard, and teams would see all this wonderful stuff and decide that they didn’t really have to make changes because the product was clearly “good enough.”

So, I don’t include positives everywhere, but I do nod toward things that are currently working.

Timing

Time is no one’s best friend, especially in product teams. It always feels like we are running a solid month or more behind on something, and research is no different. Whether it’s because someone came to you too late in the process, recruitment didn’t pan out the way you expected, or literally anything in between, timelines for research can be tight.

And this is made more difficult by ensuring our research is rigorous. We can cut some corners, but not all the corners. So, one thing I learned is to only do research when the timing works out — I now ask my stakeholders how soon they can act on and implement the insights from my work. If it is more than two months, I usually wait to do the research.

Or if I see a research project is going South and we won’t get the research done in time, I try to pivot by either changing the method or putting the research on hold until we can figure something out.

Delivering a report that no one has time to read or act on will usually lead to a lot of disappointment for all people involved. It is disheartening to do all that work and have nothing to show for it. So, as many people say, timing is everything.

Relevance

Read more

If you want to see everything I post, subscribe below!

Subscribe now

I hope I am not the only one who has felt the sting after spending hours and hours on a research report and crafting insights only to have it either ignored or pushed over to the side. It is a horrible feeling, especially when you know the insights could help improve the product/service so much.

But, it can be really difficult to get colleagues to listen to insights or to get them to rearrange their work to include your findings on a roadmap or in the next sprint. Even if it seemed obvious to me, it wasn’t always the case with others.

For a long time, I just kept repeating the same cycle of creating reports and watching most of the work go unused. Sometimes people listened, sometimes they didn’t. The inconsistency really confused me and I figured it was because some of my work was just better or more appealing.

But I knew that it wasn’t realistic for my career. I couldn’t just leave it up to chance whether or not people would listen to my work. I had to find a better way to ensure my insights were recognized and utilized.

This meant, at first, I held a lot of meetings in which I read and reread reports, presented findings, had follow-ups, and supplied plenty of colleagues with lots of coffee. However, I kept coming back to the same issue.

My colleagues understood the insights and they found (most of) them interesting and important, but we kept getting caught at the same crossroads:

“So, what do we do next?”

To be honest, I wasn’t entirely sure how to answer this question. I figured, as a researcher, I had done what I had to do and it was up to my team to figure out the next steps.

However, I came to realize this wasn’t the best way to collaborate with teams and I was missing a huge part of what I came to later learn was the activation portion of my role. In this part of the process, I would work together with teams to bring the insights from the problem-space to solution-land. Without this guidance, teams often felt unsure how to move forward from insights, especially if they were on the more abstract side of things.

Over time, I picked up several ways to activate user research insights, but one of the first and one of my favorite ways to collaborate with teams when it comes to this part of the process is How Might We Statements.

What are How Might We Statements?

How Might We statements are small but mighty questions that help us with bringing insights that are currently in the problem-space to a place where teams can start thinking of solutions.

HWM statements are originally part of the Design Thinking approach. This method of questioning allows for the teams to take the research into the ideation phase.

As I mentioned above, it can be really difficult to go from presenting your insights to helping the team to create something from those insights, especially if the insights feel more abstract and are large, generative-based findings. Often, teams can feel overwhelmed trying to navigate this situation and can feel stuck bringing insights to life.

How Might We statements are a fantastic way to frame the problem/insight in a way that spurs creativity and solution-based thinking, all with a user-centric focus.

Why are they called "How Might We's?"

There is a reason why these three special words were chosen for this approach. Each of these words holds a key into the innovative and collaborative nature of How Might We statements:

• "How" suggests that we do not yet have the answer. It allows us to consider multiple avenues for innovation and reinforces that we are still exploring the problem and solution space.

• "Might" emphasizes that there are many different paths we can go down when thinking about solutions. This allows for open-minded creativity and brainstorming and thinking about the problem from multiple perspectives. This "might" is where innovation becomes part of the process!

• "We" immediately brings in the idea of teamwork. "We" should all work collaboratively to come up with a joint understanding of the problem and put our heads together to come up with a joint solution.

Using these three words can help open your team up to innovation, creativity, and, most importantly, using your insights to create user-centric solutions.

The Benefits of Using How Might We Statements

It might already be obvious how beneficial How Might We statements can be, but just in case you might meet resistance with stakeholders, it’s important to really understand what using these statements can truly achieve.

These statements help to stimulate creative thinking and collaboration in a team by framing insights or user-centered problems as open-ended questions. They encourage teams to think beyond conventional solutions, while still focusing on users. Instead of picking a problem from scratch or using an idea that came to someone in the shower, How Might We’s empower you to take direct insights and problems from reach and turn them into questions the team can answer with creative solutions.

How Might We’s not only inspire creativity and help ensure research is properly used, but they also give so many other benefits, such as:

Encourages Positivity and Motivation

• Shifts Perspective: HMW statements reframe challenges as opportunities, encouraging teams to view obstacles not as insurmountable problems but as chances to innovate and improve. This shift in perspective can transform the team's approach to challenges, leading to more positive and productive outcomes.

• Maintains Morale: By focusing on possibilities rather than limitations, HMW statements help maintain a high level of morale among team members, even when tackling difficult issues. This optimistic outlook is contagious and can uplift the entire team's spirit.

Fosters Collaborative Inclusivity

• Democratizes the Ideation Process: HMW statements invite input from all members of a team, regardless of their role or level of experience. This inclusivity ensures that a diverse range of perspectives is considered, enriching the ideation process.

• Levels the Playing Field: By framing challenges as open-ended questions, HMW statements create a neutral space where all ideas are valued equally. This can empower quieter team members or those who might typically feel marginalized, encouraging them to share their insights and contribute more actively.

• Encourages Co-creation: HMW statements naturally facilitate collaborative brainstorming sessions, where team members build on each other's ideas. This co-creation process not only generates more innovative solutions but also fosters a sense of ownership and commitment among team members.

• Breaks Down Silos: By bringing together diverse groups within an organization to answer a common question, HMW statements can help break down silos. They encourage cross-functional collaboration, leading to more holistic and well-rounded solutions.

Enhances Flexibility

• Adaptable to Various Contexts: The versatility of HMW statements means they can be applied across different stages of product development, organizational change, service design, and more. This flexibility allows teams to use them as a tool for a wide array of challenges.

• Promotes Agile Thinking: In today’s fast-paced work environments, the ability to quickly pivot and adapt is crucial. HMW statements support agile thinking by keeping the problem space open and fluid, enabling teams to explore multiple solutions and adapt their strategies as needed.

Stimulates Creativity

• Invites Diverse Solutions: The open-ended nature of HMW statements encourages creative thinking and invites a wide range of solutions. This openness can lead to innovative ideas that might not emerge through more conventional problem-solving methods.

• Prevents Premature Convergence: Often, teams rush to converge on a solution too quickly, which can stifle creativity. HMW statements keep the exploration space wide open, preventing premature convergence and encouraging a thorough exploration of possibilities.

Builds a Research Culture

• Encourages Experimentation: HMW statements promote a culture where experimentation is valued as part of the learning process. They support the idea that not every attempt has to be successful as long as it provides insights and learning that can lead to better solutions.

• Facilitates Reflective Practice: The process of working with HMW statements encourages teams to reflect on their assumptions, question established norms, and continuously seek improvements. This reflective practice is a cornerstone of a learning culture, driving ongoing innovation and growth.

Puts Research at the Forefront

• Uses User-Centric Ideas. Instead of the common “what should we do next” question or “I had an idea in the shower” statement, How Might We’s encourage teams to build on findings and insights from user research. This means the work is based on the users’ needs and pain points, and will have a powerful impact.

• Brings Teams from Problems to Solutions. If you have ever struggled with activating insights, How Might We’s give you the chance to help teams go from problems to solutions while still maintaining creativity and the user at the center of the idea.

As I said, How Might We statements are powerful little questions! They not only help us with bringing creativity to our work, but they can also empower cross-departmental collaboration, innovation, and help us work toward building a solid research culture at an organization.

Now let’s dive into how you can craft these statements and integrate them into your process in an efficient way!

Crafting Effective How Might We Statements

Characteristics of How Might We Statements

Although How Might We’s are small questions, they do need to be written in a way that strikes a delicate balance between breadth and focus, inviting a wide range of creative solutions while being specific enough to direct efforts toward actionable outcomes. That’s a lot to think about at once and, trust me, I made a lot of mistakes in my earlier How Might We statements. After many years of using these statements, here are the best practices I use whenever I am formulating my How Might We statements:

1. User-Centric

• Focuses on User Needs: A well-crafted HMW statement always centers around the needs, pain points, or desires of the target user group. It's grounded in empathy and a deep understanding of the user experience, ensuring that the solutions developed are genuinely useful and relevant.

• Example: "How might we help new parents easily track their baby’s sleep patterns?"

2. Broad Yet Specific

• Invites Creativity: The statement is open-ended enough to encourage a broad exploration of ideas, avoiding premature limitation on the types of solutions that can be considered. It welcomes innovation from any direction.

• Retains a Clear Focus: While being open, HMW statements must have a clear focus area or challenge that guides ideation towards relevant and actionable solutions. It needs to be specific enough to prevent aimless wandering during brainstorming sessions.

• Example: "How might we make our public transportation system more accessible to people with disabilities?"

3. Action-Oriented

• Implies Action: The point of HMW statements is to encourage action and suggest that there is a solution to be found. It needs to be formulated in a way that gets the team thinking about the steps they can take to address the challenge.

• Example: "How might we reduce the time customers spend waiting in line at our stores?"

4. Inspiring and Engaging

• Sparks Interest: An effective HMW statement is inspiring; it should energize the team and provoke curiosity. It’s crafted in a way that makes people excited to start exploring solutions.

• Example: "How might we transform our workspace to boost creativity and collaboration?"

5. Addresses a Real Challenge

• Based on Insight: The statement should stem from real user insights or identified business challenges. It's not based on assumptions but on verified needs, ensuring that the solutions developed are grounded in reality.

• Example: "How might we integrate sustainable practices into our product lifecycle to meet our environmental goals?"

6. Ambiguous Enough to Explore

• Allows for Exploration: While being focused, the statement should also leave room for interpretation, allowing the team to explore different angles and perspectives. This ambiguity encourages a deeper dive into the problem, often leading to more innovative solutions.

• Example: "How might we reimagine online education to better engage students?"

It took a lot of practice to feel comfortable writing How Might We’s that encapsulated all of these different characteristics. It was a lot of trial and error, and I recommend giving yourself the space to try and experiment with your statements. Trying to balance all these points at once can feel overwhelming but, with practice, it becomes more natural and intuitive.

The key is to craft a question that is sufficiently broad to open the door to innovative, unexpected solutions, yet sufficiently focused to ensure that the solutions are relevant and actionable. This allows the question to guide the ideation process in a productive direction but without being too blue-sky.

Let’s now dive into how we can write these statements effectively.

Writing How Might We Statements

One of the biggest mistakes I made with How Might We statements was either going way too broad or too narrow — it felt like it took me forever to write a HMW that was right in the middle and struck that amazing balance I’d been searching for. Once I felt more confident and comfortable with creating How Might We statements, I moved over to teaching others how to write them.

I had no idea how difficult it was going to be to explain something that seemed so small and simple. But, over time, I created a step-by-step process I use and teach to others who are looking to write impactful How Might We statements:

Step 1: Gather Insights and Identify Problems

Start with user research, customer feedback, and team insights to identify the pain points or needs that have come from recent research. This step is absolutely critical to creating effective How Might We’s as the entire point of them is to base them on user-centric data. Without this step, the team is just creating ideas from nothing.

This step comes after you’ve done the research and prioritized the most important and unaddressed pain points and needs from the research. You can do this through affinity diagrams.

An Example Problem: Users feel anxious about managing their finances.

Step 2: Define the Core Problem or Opportunity

Once you identify the most important and unaddressed needs and pain points, it’s time to choose some to turn into problem statements. A point-of-view (POV)/problem statement allows you to focus on your users and their needs. You can create a problem statement by combining three elements: user, need, and insight into a fill-in-the-blank.

A model to use for this is: user (fill in user) needs to (fill in need) because/to (fill in insight/consequence)

Example Problem Statement: "Users need a simpler way to understand and manage their finances to reduce anxiety."

Step 3: Use the HMW Formula

Once you have a problem statement, you can then create a HMW question. I always use the two following formulas:

• Basic Formula: How might we [verb] [outcome] for [user]?

  • Example: "How might we increase engagement for teenage users?"

• With Specific Action: How might we [verb] [outcome] for [user] by [action]?

  • Example: "How might we improve learning outcomes for high school students by integrating interactive technologies?"

You might not always need the "by [action/means]" part, as it can sometimes limit the scope of ideation. Use it when you want to guide the brainstorming process in a specific direction.

Example (basic) HMW Statement: "How might we simplify financial management for users to reduce anxiety?"

Step 4: Refine for Broadness and Specificity

Ensure your HMW statement is broad enough to allow for creative exploration but specific enough to be actionable. It should invite a wide range of solutions but be directed towards a clear outcome.

Tackling Broad HMWs

Here are some examples of HMW statements that are too broad and vague:

• How might we redesign our website to make it better?

• How might we make our app more usable?

• How might we innovate on weather apps?

These statements give minimal direction or inspiration and can actually feel overwhelming to try to answer. Imagine trying to think of all the potential ways to make an app more usable? What does usable even mean? There are way too many solutions and not nearly enough focus, meaning your HWM participants will be confused at where to even begin to define a solution.

Signs that your HMW statement is too broad include:

• It could apply to almost any organization or situation.

• It invites a vast range of solutions, making it hard to know where to start.

• It doesn’t clearly relate to your specific user needs or business goals.

You can fix broad HMW statements by adding specificity through introducing specific user groups, contexts, or outcomes to focus your statement. Consider who you're designing for or the particular aspect of the problem you want to tackle.

• Example Broad Statement: "How might we improve education?"

• Fixed Statement: "How might we enhance online learning for rural high school students with limited internet access?"

• Example Broad Statement: "How might we make workplaces better?"

• Fixed Statement: "How might we create more collaborative workspaces for remote teams to enhance productivity and connection?"

Tackling Narrow HMWs

HMW statements can also be too narrow:

• How might we change the CTA button on the add to cart to a different color to make it more engaging?

• How might we make the perfect weather app by telling people the weather before they wake up?

• How might we make children less hyper during school by extending recess for 20 minutes?

When HMW statements are too narrow, we lose all the incredible, innovative ideas that can come from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.

Signs Your HMW Statement Is Too Narrow:

• It suggests a specific solution or technology.

• It focuses on minor issues, missing the bigger picture.

• It doesn’t leave much room for exploration or alternative approaches.

You can fix narrow HMW statements by broadening the scope through removing constraints and opening up the statement to a wider range of possibilities. Avoid mentioning specific solutions or technologies.

• Example Narrow Statement: "How might we develop a mobile app to improve English vocabulary for eighth graders?"

• Fixed Statement: "How might we make learning English vocabulary more engaging for eighth graders?"

• Example Narrow Statement: "How might we add a chat feature to our project management tool?"

• Fixed Statement: "How might we facilitate better communication among project team members in a remote work environment?"

Example (specific) HMW Statement: "How might we make financial management feel more accessible and less intimidating for young adults?"

Step 5: Test and Iterate

For a while, I went into sessions without first sharing or getting feedback on my How Might We statements, only to be met with blank stares or confused faces. By sharing your How Might We’s ahead of time with a few colleagues, you can get feedback on how they feel about them ahead of any ideation workshops. Are they inspired? Do the statements generate a wide range of ideas? Do they force them down a certain solution path? Or do they feel overwhelmed hearing the question?

Once I started getting feedback on my HMW statements beforehand, my ideation sessions became much more productive and I started to refine the craft of writing these statements. I iterated and learned so much by gauging people’s reactions to statements — this is where most of my learning came, tweaking these statements based on colleagues’ feedback.

Step 6: Finalize Your HMW Statement

Refine your statement based on feedback and your own insights. The final version should be inspiring, clear, and focused, ready to guide your team’s ideation process.

Example Final HMW Statement: "How might we design an intuitive financial management tool that empowers young adults, including those less tech-savvy, to overcome their anxiety about finances?"

Examples of Effective vs. Ineffective How Might We Statements

It takes some practices to get used to writing these statements in the most effective way possible. Below are some examples of effective versus ineffective HMW statements you can use as inspiration when creating your own:

Example One

• Ineffective: How might we design a new app?

  • Why Ineffective: It's too broad and lacks focus on the user's needs or the problem being solved.

• Effective: How might we make it easier for busy parents to track their children’s after school schedules?

  • Why Effective: This statement clearly identifies the target audience (busy parents) and the specific challenge (tracking after school schedules), inviting targeted and meaningful solutions.

Example Two

• Ineffective: "How might we reduce customer service calls?"

  • Why Ineffective: It suggests a goal (reducing calls) that might lead to solutions focused only on deflecting customer interactions rather than improving service quality or addressing underlying issues.

• Effective: "How might we enhance our customer service experience to increase satisfaction?"

  • Why Effective: This opens up a broader range of solutions focused on improving the overall customer experience, addressing the root causes of dissatisfaction that may lead to calls, and not just the symptom of high call volume.

Example Three

• Ineffective: How might we use AI in our products?

  • Why Ineffective: It focuses on a solution (using AI) rather than the problem or opportunity, which can limit creative thinking.

• Effective: How might we personalize our customers' experience to better meet their needs?

  • Why Effective: This statement is open to a wide range of solutions, including but not limited to AI, and is centered around improving the customer experience, encouraging innovation in service of the user.

Example Four

• Ineffective: "How might we drive more traffic to our website?"

  • Why Ineffective: While increasing traffic is one way to boost sales, focusing solely on traffic doesn't address the quality of the visitor experience or conversion rate optimization. It could lead to solutions that increase numbers without necessarily increasing sales.

• Effective: "How might we improve the online shopping experience to convert more visitors into customers?"

  • Why Effective: This statement focuses on the quality of the visitor experience and conversion, encouraging solutions that are likely to have a direct impact on sales. It invites a wide range of creative approaches to enhance the shopping experience.

Example Five

• Ineffective: "How might we use less paper in our office?"

  • Why Ineffective: It's narrowly focused on paper usage, which is just one aspect of sustainability. This narrow focus might limit the scope of solutions to those that only address paper consumption.

• Effective: "How might we foster a culture of sustainability in our workplace?"

  • Why Effective: It broadens the scope to include all aspects of sustainability, not just paper usage. This encourages a comprehensive approach to promoting sustainable practices across the organization.

Example Six

• Ineffective: "How might we comply with accessibility guidelines?"

  • Why Ineffective: While compliance is important, focusing solely on meeting guidelines may not fully address the needs of users with disabilities. This statement frames accessibility as a checkbox task rather than an opportunity to genuinely improve user experience.

• Effective: "How might we make our product more accessible and user-friendly for people with visual impairments?"

  • Why Effective: This statement is specific about the user group (people with visual impairments) but open in terms of potential solutions, encouraging innovation beyond mere compliance. It focuses on improving the user experience, which is a more inspiring and user-centered approach.

Integrating How Might We Statements into Your Research Process

One of the amazing things I learned about How Might We statements was how I could use them throughout my research process to help define, refine, and solutionize. Originally, I only used them as a way to frame my insights after I completed a project, but then I saw how they could be hugely helpful in so many different parts of the process that I started using them in many different situations.

I highly recommend using these statements throughout your process as it they can help you so much at each different stage. Here is when and how I use HMW statements at different parts of the research process:

Initial Problem Identification

One of the most powerful ways I learned to use How Might We’s was at the beginning of my research process to help set the direction and focus of a project.

How to incorporate them at this stage:

• Gather Preliminary Insights: Start with user interviews, observations, and data analysis to understand your users' needs, frustrations, and desires.

• Draft HMW Statements: Based on these insights, formulate HMW statements that capture the core challenges or opportunities you've identified. These statements should inspire you toward a future research project that strikes the balance between openness to explore and focus.

Example HMW for problem identification:

• Scenario: Users find it challenging to maintain a healthy diet due to a busy lifestyle.

• HMW Statement: "How might we help busy individuals easily integrate healthy eating habits into their daily routines?"

• Usage: This HMW statement sets the stage for understanding the broader challenge of maintaining a healthy diet amidst a hectic schedule. It guides initial research efforts, encouraging the team to explore users' daily routines, their understanding of healthy eating, and the barriers they face.

Ideation Sessions

Another great way to incorporate HMW statements is during ideation sessions after you have a solid understanding of your users and their needs. This stage is about generating solutions, and HMW statements help ensure that your ideas are aligned with user needs and open to innovative approaches.

How to incorporate them at this stage:

• Facilitate Brainstorming: Use the HMW statements as prompts in brainstorming sessions to generate a wide range of ideas. Encourage participants to think freely and build on each other's ideas.

• Diversify Thinking: Rotate through multiple HMW statements to explore different aspects of the problem or to challenge the team to think from various perspectives.

Example HMW for ideation sessions:

• Scenario: During research, you find that users often resort to fast food because they lack time to prepare healthy meals.

• HMW Statement: "How might we make healthy meal preparation quick and appealing for people with little spare time?"

• Usage: This HMW statement can spark creativity in brainstorming sessions by focusing on the specific challenge of time constraint in meal preparation. It encourages the team to think of innovative solutions that reduce preparation time, enhance the appeal of healthy meals, or both.

Solution Development

HMW statements should guide the selection of ideas for development and be a reference point throughout the prototyping and testing phases. They can help keep the team aligned on the project's goals and ensure that the solutions developed are meaningful and user-centered.

How to incorporate them at this stage:

• Narrow Down Ideas: Use HMW statements to revisit the core challenges and opportunities as you begin to narrow down your list of potential solutions. They can help ensure that the ideas you choose to develop further are both innovative and directly address the user needs identified.

• Prototype and Test: As you develop prototypes, refer back to your HMW statements to guide your design decisions and ensure that your solutions remain focused on addressing the specific challenges or opportunities you've identified.

Example HMW for solution development:

• Scenario: Ideation generates ideas around meal kits, quick recipes, and educational content on healthy eating.

• HMW Statement: "How might we design a meal kit service that caters to the needs of the time-strapped yet health-conscious user?"

• Usage: As the team moves into developing solutions, this HMW statement helps to focus on creating a meal kit service that addresses users' time constraints while supporting their desire to eat healthily. It guides the prototyping of meal kits, selection of recipes, and the development of complementary digital content.

Refinement and Iteration

You can also use HMW statements throughout the refinement and iteration stage, as you refine your solutions based on feedback. HMW statements can help ensure that your iterations are focused and purposeful, continually aiming to better meet user needs.

How to incorporate them at this stage:

• Iterative Feedback: Use HMW statements to frame questions and discussions during user testing and feedback sessions. They can help elicit insights on whether the solution effectively addresses the problem and inspire ways to improve it.

• Iterate on Solutions: Based on feedback, revisit your HMW statements to refine your solutions or to ideate new approaches that better meet user needs.

Example HMW for refinement and iteration:

• Scenario: Testing reveals that while users find the meal kit useful, they struggle with meal variety and staying motivated.

• HMW Statement: "How might we continuously engage users with our meal kit service, encouraging variety and sustained healthy eating habits?"

• Usage: This statement prompts the team to consider ways to enhance the meal kit service, possibly by introducing new recipes regularly, incorporating feedback mechanisms, or developing community support features. It ensures that iterations on the product directly address user feedback and enhance engagement and satisfaction.

See? Powerful and mighty little statements! They can really keep you on track to ensure you are focused on the user at all times while also inviting collaborative creativity on solutions. By incorporating HMW statements at each stage of your user research process, you can help team maintain a clear focus on user needs and innovative problem-solving, ensuring that the solutions developed are both creative and deeply rooted in addressing real user challenges.

Using How Might We Statements in Ideation Sessions

Although HMW statements can be used in a variety of ways, one of the most common and powerful ways to incorporate How Might We’s is through ideation sessions. These sessions are one of the best ways to get your insights in front of people and have your colleagues act on your research. An ideation session can solve the original problem of colleagues ignoring insights or not knowing what to do with them.

Here's how to effectively incorporate HMW statements into brainstorming sessions and workshops, encourage diverse perspectives, and prioritize ideas for further development.

Facilitating Brainstorming Sessions with HMW Statements

1. Prepare Your HMW Statements. Before the session, select or develop HMW statements based on prior research insights. Ensure these statements are broad enough to encourage creative thinking but focused enough to be relevant to your users’ needs.

2. Set the Stage: Begin with a brief overview of the user research findings that led to the HMW statements. This helps participants understand the context and grounds the session in real user needs. Clearly explain what HMW statements are and how they’re intended to spark ideas.

3. Encourage Open Ideation: Present one HMW statement at a time and invite participants to generate as many ideas as possible, using the statement as a prompt. You can use any ideation technique that feels most comfortable to you. Here are some of my favorites:

   • Flip the Problem: Invert the original problem statement and brainstorm ideas around the reversed question. Then, take some of these negative ideas and invert them back to solve the original problem.

   • How Would [Company] Do It?: Explore the problem space as if you were a CEO of a completely different company (e.g., Google, Amazon). This exercise encourages thinking outside your industry's norms.

   • Crazy 8’s: A sketching technique where participants create eight different ideas in eight minutes. This approach is inclusive and suitable for designers and non-designers alike.

   • Method 6-3-5: Six people write down three ideas in five minutes, passing their sheets to others to build on the concepts. This collaborative approach sparks creativity and innovation.

   • Worst Possible Idea: Encourage participants to generate terrible, absurd, or even illegal ideas. Then, challenge them to transform these terrible ideas into good ones by considering their opposites or extracting valuable aspects.

Encourage Diverse Perspectives

1. Diverse Participation: Include participants from different roles, backgrounds, and departments. Diversity in the room brings diverse ways of thinking, leading to a richer set of ideas. Consider inviting users or external stakeholders to participate or provide input ahead of the brainstorming session.

2. Create a Safe Space: Establish ground rules that support a judgment-free environment. Emphasize that all ideas are welcome and that critique is reserved for later stages. Use facilitation techniques like round-robin (everyone takes turns sharing ideas) or anonymous idea submission (using post-its or digital tools) to ensure quieter voices are heard.

3. Foster an Inclusive Environment: Actively encourage participants to build on each other's ideas, which can lead to even more innovative solutions. Be mindful of dynamics in the room to ensure that dominant voices don’t overshadow others. Facilitators can redirect the conversation to include more participants.

How to Prioritize and Select Ideas

1. Group and Theme Ideas: After generating a wide range of ideas, group them into themes or categories. This helps identify patterns or areas of interest that emerged during the session. Look for clusters of ideas that address the HMW statement in unique or particularly promising ways.

2. Criteria for Selection: Establish criteria for prioritizing ideas, which might include feasibility, potential impact, alignment with user needs, or innovativeness. Consider using voting methods (dot voting, for example) to allow participants to express which ideas they find most compelling based on the criteria.

3. Narrow Down and Plan Next Steps: Select a handful of ideas to explore further. This selection can be based on the outcomes of the voting, facilitator insight, and discussion among participants. Outline next steps for each selected idea, which may include more detailed research, prototyping, or incorporating the idea into a larger project plan.

4. Document and Share Outcomes: Ensure that all ideas, not just the selected few, are documented and shared with participants and other stakeholders. This can foster a sense of ownership and appreciation for the collaborative effort. Highlight how the HMW statements guided the ideation process and how the selected ideas will be explored further.

To make this more concrete, I’ve included a sample agenda I’ve used that incorporates a HMW ideation session while using the Crazy 8’s technique:

Sample Agenda for an HMW Ideation Session Using Crazy 8's

Goal:

To generate a diverse set of solutions to improve the user experience on a mobile banking app, guided by HMW statements.

Duration: 1.5 Hours

Part 1: Introduction and Warm-Up (15 minutes)

1. Welcome and Ice Breaker (5 minutes)

• A quick welcome with an ice-breaker activity to get everyone comfortable. I particularly love either:

  • The Aliens HaveInvaded, in which you ask everyone to explain a concept to aliens who can only speak via emojis

  • Paperclip Uses, in which people take a few minutes to brainstorm all the things they could use a paper clip for — it’s hilarious!

2. Session Overview and Goal (5 minutes)

• Explain the session's goal: To ideate solutions for improving the mobile banking app experience for users.

• Introduce the concept of HMW statements and Crazy 8's method.

3. Introduction to the HMW Statement (5 minutes)

• Present the chosen HMW statement: "How might we make the mobile banking app more intuitive and secure for first-time users?"

• Briefly discuss the background and user research that led to this HMW statement.

Part 2: Crazy 8's Ideation (45 minutes)

4. Explanation of Crazy 8's Method (5 minutes)

• Explain the Crazy 8's method: Each participant will fold a sheet of paper into eight sections and then, given 8 minutes, sketch or write down an idea in each section, moving quickly from one to the next.

5. Round 1 of Crazy 8's (8 minutes)

• Participants work individually on their Crazy 8's, focusing on the presented HMW statement.

6. Share and Discuss Ideas (10 minutes)

• Participants briefly share their ideas with the group, explaining their sketches or concepts.

• Facilitate a quick discussion to highlight interesting or recurring themes.

7. Refine HMW Statement (Optional) (2 minutes)

• Based on the discussion, slightly refine or introduce a new HMW statement for the next round to explore different aspects of the problem, e.g., "How might we personalize the mobile banking experience to build trust with first-time users?"

8. Round 2 of Crazy 8's (8 minutes)

• Repeat the Crazy 8's process with the new or refined HMW statement, encouraging participants to build on ideas from the first round or explore new directions.

9. Share and Discuss Ideas (10 minutes)

• Another round of sharing and discussion, focusing on the new ideas generated.

Part 3: Convergence and Prioritization (20 minutes)

10. Idea Grouping and Voting (10 minutes)

• Group similar ideas together on a wall or digital board.

• Use dot voting to identify the most promising ideas, allowing each participant a limited number (usually two or three) of votes.

11. Discuss and Select Ideas to Develop (10 minutes)

• Discuss the top-voted ideas in more detail, considering feasibility, impact, and alignment with user needs.

• Select a subset of ideas for further exploration.

Part 4: Wrap-Up and Next Steps (10 minutes)

12. Define Next Steps (5 minutes)

• Outline the process for further researching, prototyping, and testing the selected ideas.

• Assign responsibilities or create small teams for each idea if applicable.

13. Closing Remarks and Feedback (5 minutes)

• Thank participants for their energy and creativity.

• Briefly gather feedback on the session to improve future workshops. You can also send out a post-workshop survey to gather even more feedback (highly recommend this!).

Practice and Enjoy!

It takes time and practice to refine the craft of creating effective and impactful How Might We statements and I highly encourage you to take the time to learn this particular skill. Not only does it serve as a great way to collaborate with teams, but it empowers you to bring your research to the next level and truly make it actionable. Workshop facilitation and activation are critical soft skills for a user researcher and How Might We statements are a fantastic way to hone those skills and demonstrate the value of your research.

Try to enjoy the process as much as you can — HMW statements are meant to be fun, creative, and energizing for teams. I promise, once you get into a rhythm with using these statements, you will have a blast!

Join my membership!

If you’re looking for even more content, a space to call home (with a buzzing private community), and live sessions with me to answer all your deepest questions, check out my membership! Within the membership, you get all my Substack content for free and so many other wonderful resources to help you gain confidence and up-level in your user research career!

If you want to see everything I post, subscribe below!

Subscribe now

Raise your hand (clap, scream, or nod) if you’ve run an amazing research project and thought: my team will LOVE this data, and we will do so much with it.

Raise your hand (clap, scream, or nod) if you’ve then shared that data and…nothing happened.

One of the most frustrating parts of being a user researcher is when you feel like you have great insights or findings from a study, and then they end up dying in a virtual corner. No one seems to care about them or know what to do with them.

I struggled with this for so long in my research career, and it really got me down.

I’d run a study, create a deck filled with goodies, and then present it to my team. I thought the team would then take the data and run with it, improving the product, creating new features, or developing innovative ideas.

But reality looked much different. I’d present the results, and nothing would happen. I found this to be the case, especially with generative research.

To be completely honest, I blamed my teams. I claimed they didn’t care enough about user research and that no one valued my work. I believed that my work had enough information for the team to take and run with.

At one point, I threw my hands in the air and stopped spending time making reports. My research process stopped with the affinity diagram. What was the point if no one cared? What was the point if no one did anything with the reports?

My response was so much easier than thinking I could also be partially responsible for my findings and insights flopping. So (begrudgingly), I sat down and audited my current sharing process and then met with my teams to review and discuss what was missing.

These conversations were difficult, and I certainly had to swallow my pride when it came to receiving feedback — I still wasn’t wonderful at taking constructive criticism. However, the feedback my stakeholders shared completely opened my eyes and enabled me to revamp my sharing process to become so much more effective and impactful.

And I’ve never looked back. Here’s how I changed how I collaborate and interact with teams regarding sharing and activating insights.

Audit Your Current Sharing Process

The first thing you can do is understand what your current sharing process is and reflect on the different steps.

Start by listing out the different steps you have in your sharing process. You can see an example of mine below:

Once I did this, I went into each step and made a journey map, including what I was trying to accomplish in that step, the tasks associated with the step, and the pain points I encountered.

With this information, I could take a step back from my sharing process and understand, subjectively, what was happening and what wasn’t going as well within the process. For example, the “create a report” step looked like:

• Goal:

  • Create a report that stakeholders find helpful and use to inform their work

• Tasks:

  • Develop report design

  • Decide the audience and length of the report

  • Decide the most relevant information for the audience

  • Include any background information

  • Move findings from the affinity diagram to the report

  • Write out the report

  • Create video or audio clips

  • Link to relevant studies or resources

• Pain points:

  • Creating video and audio clips is hugely time-consuming and difficult on Quicktime to get exactly what I need because I need to skip through the video and trim, which can be very fiddly

  • I am not confident in the length of the report and what information I need to include versus what is too much

  • I hate designing reports and always find them to look ugly and like I can never get an eye-catching design

When going through this exercise, make sure you are specific with your pain points. Don’t just write that things take a long time; try to tease out exactly what is taking a long time, just like you would do with a participant. Be your own research advocate!

There are a few additional items you can include in your journey, such as:

• Tools you currently use

• Stakeholder involvement in the given step

• An emotion line (or emoji) indicating how you feel about that step

At the end of this exercise, you will clearly understand what your sharing process looks like and all your associated pain points. However, I highly encourage you to take the next step, which is to get stakeholder feedback. The first time I did this, I didn’t ask for feedback and tried to alleviate my pain points without context from my team. I wasted time on solutions that weren’t relevant, and I was unable to solve the pain points properly.

Always ask your team for feedback!

*If you want to take auditing your process to the next level and look at your entire process, check out my book Impact, where I talk through how to set up and optimize an entire research practice at your organization.

Get Feedback on Your Current Process

Once you have your process laid out, it’s time to involve your stakeholders to get their feedback.

I typically do this through a workshop setting, inviting each relevant team to their own separate workshop. For instance, I worked across four teams and held four workshops. Although this took a lot more time, it was much more manageable than shoving over thirty people into one workshop. I could understand each team’s feedback more deeply to think through better solutions.

The Feedback Workshop

I love a good workshop, and I will say this is a great opportunity for you to practice your workshop facilitation skills — always look for these moments of practice!

The goal of this feedback workshop is to present your current sharing process and get an understanding of stakeholders’ experiences to make improvements to the process. At the end of the workshop, you want to understand how stakeholders feel about the process, specifically their painful moments and how those overlap with your pain points.

With this knowledge and understanding, you can begin to ideate solutions that help alleviate the most common pain points.

Here is how I set up this feedback workshop:

• Talk through the goal and outcome of the workshop

• Introduce your current sharing process and how you created it

• Answer any questions before diving into the feedback portion of the workshop

• Ask for constructive feedback (acknowledge you won’t take it personally, this is very important)

  • Give stakeholders 10-20 minutes to fill out any tasks they have to do during each step

  • Come back and discuss the tasks, gaining any clarity if necessary

  • Give stakeholders 20-30 minutes to add any of their pain points to the different steps. Make sure everyone writes their own, even if the pain point is already up there, so you can understand the weight of each pain point

  • Take 30 minutes to discuss the pain points that came up for stakeholders

• Tackle any questions or parking lot topics that came up during the feedback session

• Assign action items to people

Review the Journey Map

Once you go through this process, you will have a journey map filled with everyone’s tasks and pain points. When I first did this, I was super overwhelmed by the amount of problems and pain points we uncovered. This led me to bounce around with about 50 different ideas and be incredibly inefficient in fixing anything. From there, I realized I had to prioritize, just like user research insights.

The next step for you is to review the journey map and list out the pain points that have the most weight (the ones most people wrote about) so that you can prioritize the most painful parts of the process. This will give you clarity on what to work on first and also allow you to show teams you are making progress on what is most important.

Depending on their size, I typically prioritize finding solutions to the top three to five pain points. If you are struggling with picking which pain points to focus on, I highly recommend sending out a poll to your teams so they can vote. You always want to ensure you include your teams in this process!

When I did this, I found the biggest pain points to be:

1. The team wasn’t sure what to do with big, abstract, generative research insights and often felt confused about how to bring them into brainstorming or a solution space

2. There was no prioritization of what should be worked on first or the most important problems for users

3. Sometimes, a report felt like it was unnecessary and just took a lot of time to create, especially if the teams were already involved in the research

I then honed in on fixing these particular problems.

Make Changes to Your Process

The next step is to start ideating on solutions to the biggest problems you and the team are facing when it comes to sharing research. You can do this one of three ways:

1. Ideate on your own and then experiment with your solutions over time

2. Bring your team in and ideate together on solutions, implementing them and monitoring how it’s going

3. Start by ideating on your own, sharing solution ideas with the team, and then asking them for feedback or ideas, which you can then implement

I’m a huge fan of making this a group effort and going with option two, but I also understand that’s not always realistic. The first time I tried this, I went at it alone. It turned out okay, but I wish I had asked my colleagues about their ideas.

From then on, I tried to go with either option two or three to get more feedback and ensure I was on the best path forward for myself and my teams.

Running the Internal Ideation Session

Regardless of whether you are doing this alone or with your team, essentially, you are running an ideation session.

An ideation workshop is a safe space that allows for this generation of ideas. The main goal of an ideation session is to spark innovation and draw out a sense of creativity. During this session, you aim to brainstorm as many ideas as possible surrounding the topic or pain point.

This is the same exact session we tend to run with user insights or pain points; however, this time, you are using the process pain points you identified earlier.

Here’s how I run my internal ideation sessions:

1. Talk through the goals of the session. My main goal with ideation sessions is for us to generate as many ideas as possible for the identified problems. You don’t necessarily have to focus on quality but rather on quantity. Although, I do tend to ask people to make sure their ideas are realistic :)

2. Define the outcome. By the end of this session, I want to have several ideas for each problem that we can implement and monitor to see how they work. I like to give a timeframe of how long we will monitor each solution to determine whether it is working.

3. Introduce one pain point at a time. I introduce one pain point at a time and make sure to give any context or answer any questions about the pain point.

4. Ideate on each pain point. We then ideate on each pain point, using methods such as:

   1. Flip the problem

   2. Method 6-3-5

   3. Crazy 8’s

   4. How would Google do it?

5. If necessary, vote or choose a solution to try. Depending on how many solutions you have for each pain point, you might have to vote or choose a solution to try. Depending on the issue, you might also be able to choose several ideas to implement at once.

6. Create success criteria. Once you choose what idea(s) to implement for the given problem, brainstorm some success criteria to help you decide whether or not the solution was successful.

7. Make a date to follow up. Make sure you have a time period to test the idea and follow up using the determined success criteria. If the solution was unsuccessful, choose other ideas from the session or rerun another ideation session. I typically give the ideas three months to understand if they are helping or not.

My Biggest Shift: Activation

One of the biggest pain points I identified in my sharing process was that teams were unsure of how to take big insights and bring them from the problem to the solution space. My biggest shift was understanding that I was missing this huge part of the research process. I went straight from presenting the research to checking in and seeing what teams were doing with it.

Since I was often the first and only user researcher at an organization, many people were unfamiliar with how exactly to work with user research, especially regarding larger generative research projects. I realized my way of throwing insights over the fence and hoping teams would act on them wouldn’t fly with everyone.

Once I heard from the team and saw how painful the experience was for them, I couldn’t unsee it, and I knew I had to change how I helped my teams digest and act on my research.

Ways to Activate Your Insights

Since I understood the problems and confusion my team faced on how to use my research, I baked the activation phase into each study. Here are the most common ways that I activate insights with my team:

An internal hackathon is a great way to help focus the teams on activating insights or personas. I took important insights from our persona and broke the organization into several teams, where they each brainstormed solutions (while competing) over two or three days. This is one of the most fun ways to activate insights.

Mini-brainstorm sessions. I left room in my calendar for ad-hoc mini-brainstorming sessions. I invited stakeholders, who had been present in the research sessions. We took some of the quick fixes/low-hanging fruit we’d been hearing about and had a quick brainstorm on how we could solve these issues. Within the session, we either sketched ideas on paper, wireframed potential solutions or just spoke through potential solutions.

Usability bingo. Let's dive into the concept of Usability Bingo, a creative approach to making user research more engaging. Imagine a 5x5 bingo board with randomly allocated phrases, quotes, pain points, needs, goals, and bugs from your usability tests instead of numbers. Rather than calling out numbers, you compile video clips from your usability tests that feature these phrases and issues. As your team watches these clips, they mark off corresponding spaces on their bingo boards, aiming to be the first to achieve five in a row and win a prize.

Ideation workshops are the end-all-be-all of insight activation. In these workshops, you bring one or two of the most critical insights from your persona (based on the prioritization you did earlier) and, together, ideate solutions. In this setting, you’re taking your research and making it into something, all while being there to help guide the team and provide context. Then, after the session, you have something to usability test!

The activation technique you choose depends on how much time and how many resources you have — ideation workshops, especially Crazy 8’s, are much less effort, whereas an internal hackathon takes a longer time to plan and run.

I recommend picking the easiest techniques (e.g., Crazy 8s or Method 3-6-5) first while you get used to them and then moving to more complex sessions with practice.

In-depth: Ideation Sessions

An ideation session is a turbocharged brainstorming session where your team unleashes their creativity. In this ideation session, your team reviews the problem and throws around solutions for the issues you’ve dug up in your research.

Feasibility and practicality can take a back seat in this ideation session. It's all about tossing out ideas and saving the serious evaluations for later. For this session, it is much more about quantity over quality. The more ideas, the merrier. In each of my sessions, "no" is banned because it stifles open-minded thinking.

Ideation sessions are the GPS for your team, guiding them through the maze of insights. These workshops light the way, pointing your team toward usability testing and the next big steps because they're rooted in user research, tackling real problems your customers face. No gut feelings or business whims – it's all about the users.

How to Run a Successful Ideation Workshop

Running a successful ideation workshop involves following best practices to maximize its impact

Begin with User Research

Ensure that your workshop is grounded in user research. Without this foundation, you risk exploring irrelevant topics that don't align with user needs, motivations, or pain points. Start with a clear problem statement derived from user insights.

Define Expected Outcomes

Set clear expectations for what you aim to achieve by the end of the workshop. These outcomes typically include gaining a deep understanding of the problem, generating many ideas, selecting the top ideas for testing, and determining the next steps for testing those ideas.

Craft a Problem Statement

A well-defined problem statement is crucial. It should outline a current user problem, goal, and challenges. Problem statements must be broad enough to generate diverse ideas but focused on addressing specific user needs. You can use the following techniques to craft a problem statement:

• Focus on the user's perspective: "I am a student who loves to travel, but I'm struggling because of my limited budget and trying to find cheap but safe flights. This frustrates me because I want to travel but feel stuck."

• Look at the four W's (who, what, where, why): "I'm a writer, but I also work a full-time job, making it hard for me to find time to write. I don't know how to properly manage my free time when I am not at work, so I waste a lot of time and feel bad."

• Examine needs: "I am a doctor and need a way to stay updated on the patient's charts. I don't have time to look through the computer program or go into the patient's room, so sometimes I miss important updates."

If you are struggling to create a problem statement, you can just utilize a pain point or struggle you and the team prioritized.

Select Ideation Techniques

Choose ideation techniques that suit your workshop's objectives. Here are some favorite ideation techniques.

• Flip the Problem: Invert the original problem statement and brainstorm ideas around the reversed question. Then, take some of these negative ideas and invert them back to solve the original problem.

• How Would [Company] Do It?: Explore the problem space as if you were a CEO of a completely different company (e.g., Google, Amazon). This exercise encourages thinking outside your industry's norms.

• Crazy 8’s: A sketching technique where participants create eight different ideas in eight minutes. This approach is inclusive and suitable for designers and non-designers alike.

• Method 6-3-5: Six people write down three ideas in five minutes, passing their sheets to others to build on the concepts. This collaborative approach sparks creativity and innovation.

• Worst Possible Idea: Encourage participants to generate terrible, absurd, or even illegal ideas. Then, challenge them to transform these terrible ideas into good ones by considering their opposites or extracting valuable aspects.

Follow Up

After the ideation workshop, ensure that the generated ideas don't just sit around. Collaborate with designers and product managers to plan usability testing for the selected ideas — make an actual date to do this, and put the meeting in your calendars ASAP. The ideation workshop is just the beginning; follow-through is essential to turn ideas into tangible solutions.

Ideation workshops are a dynamic means of harnessing your team's collective creativity and converting your research insights into actionable ideas. They can serve as a springboard for innovation and user-centered product development when executed effectively. For further inspiration and ideation techniques, explore these resources:

• Gamestorming

• Innovation Cards

• Trigger Cards

• Board of Innovation

• HI Toolbox

Example Agenda: Travel

I held many activation workshops, but ideation sessions, specifically Crazy 8’s, were always my favorite because they felt accessible to everyone and easy to explain. Over team, my teams got really great at running them without me — I was both happy and sad about this; super happy they learned, but I missed running them!

Here is an example of an actual ideation session agenda I used at one of my organizations:

Workshop Agenda Example

1. Welcome & Icebreaker (7 mins):

• Say hi to everyone and get everyone settled in the virtual or in-person room

• Icebreaker

  • Share your dream travel destination in 30 seconds. Bonus points for creativity!

2. Setting the Scene (10 mins):

• Briefly outline the workshop's goal

  • The goal of this workshop is to create as many

• Talk through the expected outcomes for the end of the session, such as:

• Emphasize the importance of fun and out-of-the-box thinking – we're here to dream big!

  • Everyone gets a chance to contribute

  • “Yes, and…” — “No” is banned!

  • Go wild with ideas!

3. User Insights Review (8 mins):

• Quickly dive into the chosen pain point or insight. I cover 1-2 per Crazy 8 session. For our session, we focused on:

1. Pain Point: Users often feel overwhelmed by the sheer volume of information available about potential travel destinations.

   1. Example: Sorting through endless travel blogs, reviews, and articles, leading to confusion rather than clarity.

2. Pain Point: Many users struggle to find travel recommendations that align with their unique preferences and interests.

   1. Example: Generic travel suggestions may not consider individual preferences, leading to dissatisfaction with the chosen destination.

4. Explain the exercise (5 mins):

• Briefly explain Crazy 8's: 8 minutes, 8 ideas. No holding back, no judgment – just pure creative chaos! Emphasize speed and quantity.

6. Problem Statement Focus (3 mins):

• Focus on each problem statement or pain point individually and follow the rest of the agenda for each one

6. Crazy 8's Exercise (8 mins):

• Set the timer and let participants sketch eight different ideas related to the pain point in eight minutes.

7. Show & Tell (5 mins):

• Whoever wants to shares their ideas with the group

8. Group Mashup (10 mins):

• Participants get into groups and mash-up the ideas into one or two Frankensteins

9. Review and Share (10 mins):

• Each team presents their ideas and other teams ask any questions

10. Voting for the Top Three Ideas (5 mins):

• Each participant votes on their favorite idea.

• The winning 2-3 ideas get brought into a design/prototyping phase to get testing with users then

11. Action Plan & Next Steps (8 mins):

• Assign tasks for refining the winning idea(s) and planning for a prototype or testing phase — assign actual people and dates here!

One of the wonderful outcomes of running activation sessions, whichever ones we chose, was that, even though I had a bit more work initially, I was slowly training my team to activate independently. Once I’d run several workshops with teams, I found champions and people who were interested in facilitating the workshops themselves. With time, I could take a step back, and I only facilitated when there was a particularly large and complex study.

Other Changes I Made:

Based on the biggest pain points and the ideation sessions, here are a few other changes I made to my sharing process that I still use to this day:

• Implementing the opportunity gap survey. Whenever faced with large amounts of qualitative data, the opportunity gap survey can really help you prioritize what is most important to work on first. Including this survey as part of the research process enabled my teams to focus much better and know they were impacting the biggest user pain points or needs.

• Creating success criteria for my research projects. I found it really difficult to prove my value when it came to the end of my research projects, and the teams also weren’t sure how to report on the impact of user research. So, we started defining clear success criteria for research projects so we could understand what positive changes came from research. You can read more about setting up success criteria here.

• Asking teams about the types of deliverables they need. Because teams mentioned reports sometimes felt unnecessary, I started asking upfront what my teams needed from me regarding deliverables. If they were heavily involved in the research and synthesis, we often determined that a Miro board was enough and there was no reason to create a whole report. By asking my team, I reduced the amount of unneeded work and was able to speed up the sharing process considerably.

• Creating an executive summary and catering to my audience. Similar to the above, I made sure to understand who my audience would be for the research. I knew if it was just the involved team, I might not have to create a big report, but if I presented to a wider audience, I would have to. I made sure to truly understand who my audience was and create a report that was applicable and relevant to them, including an executive summary.

I also took the time to audit my entire process (check out my book, Impact, if you want to do this) and continue to audit my process every six months!

Join my membership!

If you’re looking for even more content, a space to call home (with a buzzing private community), and live sessions with me to answer all your deepest questions, check out my membership! Within the membership, you get all my Substack content for free and so many other wonderful resources to help you gain confidence and up-level in your user research career!

If you want to see everything I post, subscribe below!

Subscribe now

I remember the first time I ran a very successful generative research study. I had spent months practicing my skills and finally felt like I had achieved a rhythm and depth that got us deep and meaningful data from our participants.

I had uncovered information beyond what we had imagined. Not only did I answer the study's goals, but the data we received included innovative, never-before-heard insights that surprised us. The “wows” we said topped those of Owen Wilson.

Never had I gathered quite as much qualitative research and so many insights. At the end of the study, I had to bring my report down from over fifty pages to something more manageable, but I had no idea which insights to prioritize.

Of course, I started with the study goals and made sure I shared the information the team needed to move forward with the decisions they’d been struggling with. But I had so much more deep data and interesting information for them.

Since I hadn’t had this kind of “problem” before, I wasn’t sure what to do, so I roped my entire team into the process of understanding all the insights and trying to decide which ones we should focus on first. While I was thrilled that the study had such an impact and gave us so much data, I soon saw how this could be a substantial problem. Outside of the direct insights we needed for the study goals, we had a very hard time trying to determine what else to focus on from the learnings.

After three workshops of trying to prioritize the insights, I threw my hands in the air, frustrated by our lack of progress. We had gone around in circles trying to determine which of the fifty insights were now, next, and later. We’d tried various prioritization models, such as RICE (Reach, Impact, Confidence, and Effort) and the Kano Model, but none of them seemed to help. We walked out with questions and doubts.

When that last workshop ended, instead of scheduling another, I decided to take a step back. We had put so much effort into this study and got everything we asked for and more, but now it felt like it was all being wasted. I could predict that, soon, people would give up on this exercise, and the insights would be stuck somewhere in a Google Drive folder like I’d seen happen before.

I researched how I could potentially solve this prioritization problem and stumbled across something called the Opportunity Gap Survey.

What is the Opportunity Gap Survey?

Officially, the opportunity gap survey is part of the Jobs to be Done framework and the Opportunity-Driven Innovation framework created by Anthony W. Ulwick. However, when I found out about this opportunity survey, despite not using Jobs to be Done for this study, I thought I could possibly use it to help us make some decisions.

The opportunity gap survey analyzes the gap between how important each insight is and how satisfied people are with current solutions. The “gap” between the perceived importance and the perceived level of satisfaction is your opportunity score. The bigger the gap between how important something is to the person and how satisfied they currently are, the bigger the potential opportunity.

Let’s look at an example to make this more concrete.

Imagine we were doing a study on students going through medical school — I asked my best friend about this since she went through this process a few years ago. We’re trying to understand their different needs during the process of “surviving” medical school.

During this generative study, we uncover the following needs and goals of medical students:

• Pass STEP exams

• Find research and paper publication opportunities

• Discover a mentor

• Find cheap accommodation

• Study for in-person interactions with patients

• Find time for exercising

• Overcome impostor syndrome

There is quite a lot of variety within these learnings, so where do we place our focus, and where do we start?

This situation is when the opportunity gap survey can become a very handy tool. For each of these points, we’d create two questions, one focused on the level of importance and the other on the current satisfaction. These questions each follow the below model:

1. How important is it to you that you are able to [outcome/goal/need]?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using [current solution], how satisfied are you with your ability to achieve [outcome/goal/need]?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

So, for each of the above points, we’d fill in the goal, need, or outcome, for the two questions, and it would look like this:

1. How important is it to you that you are able to pass the STEP exam?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using your current solution, how satisfied are you with your ability to pass the STEP exam?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

You’d set up these two questions for each of the bullet points above.

It might be that you’ve uncovered the solutions participants are using, so you can specify in the question if that’s the case, or you can even ask about the satisfaction of your own product as a solution (if the participants are users).

Once you send this out, you will start to receive opportunity scores, the delta between importance and satisfaction, which will help you to prioritize your learnings. We’ll cover analyzing the score in a second, but first, let’s walk through what creating an opportunity gap survey looks like.

How to Create an Opportunity Gap Survey

The entire point of this survey is to help you prioritize findings and insights from generative research, so the first and most essential step of creating an opportunity gap survey is to conduct some generative research. Basing your survey on results from this type of research is critical to ensuring you get the most accurate information from your participants.

Setting Up Your Study

Whenever I know I’m going to use a generative research approach, I automatically assume that I will be sending out the opportunity gap survey at the end of the study to help us prioritize insights and needs. By knowing I will send out this survey, I can ensure I get the most relevant information from participants, setting us up for success.

The first step to a successful study is setting up a research plan with incredibly clear research goals.

Research goals are the in-depth areas we want to explore in our research project that will help us answer what we are trying to learn. These goals are the things we want to be able to gather information about by the end of the study. They aren’t posed as questions, but we want to be able to “answer” them in the sense of getting enough data on them to feel comfortable making decisions.

When it comes to a generative research study that has an opportunity gap survey, my goals usually consist of:

• Discover the unmet needs of our participants and where we don’t support them in [topic]

• Identify participant’s goals and their current process to achieve those goals

• Uncover the different tools participants are currently using to achieve their goals and what their experience is like with them

Through this study, I am hugely focused on goals and needs, which is the exact information I need to put together an opportunity gap survey.

The opportunity gap survey will only be as helpful as it is relevant to the information you get. If you don’t have information on goals and needs, the opportunity score won’t be as helpful in prioritizing what you focus on. As always, make sure the approach makes sense given the goals of your study and the information you collect from participants.

Creating the Survey Questions

As covered above, for each need, goal, or outcome you uncover, you use both the importance and satisfaction questions to get the opportunity score:

1. How important is it to you that you are able to [outcome/goal/need]?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using [current solution], how satisfied are you with your ability to achieve [outcome/goal/need]?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

Let’s look at a few more examples of putting these together.

Need: Keep track of my eating habits

1. How important is it to you that you are able to keep track of your eating habits?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using MyFitnessPal, how satisfied are you with your ability to keep track of your eating habits?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

      ---

Need: Minimize time inputting expenses

1. How important is it to you that you are able to minimize your time inputting expenses?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using Xero, how satisfied are you with your ability to minimize your time inputting expenses?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

      ---

Need: Give specific package delivery instructions

1. How important is it to you that you are able to give specific package delivery instructions?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using UPS, how satisfied are you with your ability to give specific package delivery instructions?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

      ---

Need: Minimize the time it takes to research where to stay on a trip

1. How important is it to you that you are able to minimize the time it takes to research where to stay on a trip?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using Expedia, how satisfied are you with your ability to minimize the time it takes to research where to stay on a trip?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

      ---

As you can see, this survey is extremely adaptable and, as long as you have the right information to put into it, can be relatively simple to put together.

Whenever it comes to surveys, however, always make sure you take into consideration the number of questions. Since, essentially, each need is two questions, these can add up very quickly. Typically, once a survey response time exceeds seven minutes, you may start to see a significant drop-off in responses.

I like to keep my surveys shorter, — around fifteen questions (I count each of the two questions as one in the case of the opportunity gap survey — which might mean you can’t include all of your needs in your opportunity gap survey. In studies where I’ve had more than fifteen needs, goals, or outcomes to prioritize, I’ve had to sit with my team and try to work out the ones that are most important to ask in our given context.

Another option is to send out several surveys in different phases. Obviously, this takes longer, but it can be a good compromise. You still need to prioritize which questions you’re sending out first.

For this, we typically use the RICE model to help us understand which are the most important questions to send. Another way I’ve prioritized the questions is by the weight of the need, goal, or outcome. What I mean by this is how often that need, goal, or outcome came up across participants. The more participants who mentioned the given need, goal, or outcome, the higher it went on the list of questions.

Sending the Survey

Once you have your questions set, it’s time to send out your survey. This part prompted some questions, such as, “Who should I send the survey to?” and “How many people should I send it to?”

Typically, with generative research, you have a smaller sample size, such as fifteen or twenty participants. Unfortunately, that number is a bit too small of a sample size for a survey, and limiting to only that group of users may skew your results.

Ideally, when it comes to this type of survey, you would send it out to similar participants to those you interviewed, whether this means a particular persona, segment, or demographic. Make sure the survey participants are similar to those you interviewed and would have the same needs, goals, or outcomes, or use the same solutions. If you aren’t sure whether they’ve used those solutions or not, make the satisfaction question more generic by saying “your current solution.”

For this particular survey, we aren’t looking at comparison, so we can use a confidence interval around sample means, which in this case, are average satisfaction and average importance. So, we must determine our comfortable margin of error and confidence interval.

The most common of these is a 5% margin of error and 95% confidence interval. Calculate your necessary sample size by understanding your population size and popping that into a calculator like this one.

Once you have all of that set, plug your survey into the many survey-based tools and send it out to more people than necessary in your sample size. Remember, not everyone will respond to your survey. Typically, you can expect a 10% - 20% response rate, unless you have a very engaged customer base, in which you can expect closer to a 50% - 60% response rate.

If you are new to surveys, the best thing you can do is test out your response rates and which medium (e.g. email, pop-up) gives you the best response. It might take some time to understand your numbers, but it’s great to experiment and iterate on this process!

Also, as a tip, always send a dry run of your survey internally to make sure there are no problems with it and to see approximately how long it will take, as one of the worst feelings in the world is to have to resend a survey because of an error. Trust me, I’ve been there.

How to Analyze Your Opportunity Gap Survey

Once you receive your responses, it’s time to analyze your survey. In general, the criteria are relatively straightforward. Any insight with a high importance and low satisfaction is a potential opportunity that will bring a high ROI. This score indicates people find the goal, need, or outcome important but are currently dissatisfied with the solution. So, if the team were to make a better solution that addresses that need, goal, or outcome, the higher likelihood the person would use it and be more satisfied.

The other scores include:

• Low importance and high satisfaction

• High importance and high satisfaction

• Low importance and low satisfaction

These insights become deprioritized because there is either already a satisfactory solution or the insight isn’t important for users.

To score the test, you can use the following formula:

Importance + (importance - satisfaction) = opportunity

So let’s go back to one of our examples:

Need: Minimize the time it takes to research where to stay on a trip

1. How important is it to you that you are able to minimize the time it takes to research where to stay on a trip?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using Expedia, how satisfied are you with your ability to minimize the time it takes to research where to stay on a trip?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

Let’s say that a participant responded with the following data:

• Level of importance is 4

• Level of satisfaction is 2

We would then have:

4 + (4 - 2) = 6

The highest opportunity score for the survey is 9 (an importance level of 5 and a satisfaction level of 1), so an opportunity score of 6 is fairly significant.

Now let’s look at a different example.

Need: Give specific package delivery instructions

1. How important is it to you that you are able to give specific package delivery instructions?

   1. 1 to 5 scale, 1 = “Not at all important”, 5 = “Extremely important”

2. When using UPS, how satisfied are you with your ability to give specific package delivery instructions?

   1. 1 to 5 scale, 1 = “Not at all satisfied”, 5 = “Extremely satisfied”

Let’s say that a participant responded with the following data:

• Level of importance is 2

• Level of satisfaction is 4

We would then have:

2 + (2 - 4) = 0

Compared to 6, this is not a great opportunity to focus on. The participant does not find this insight important and is satisfied with their current solution.

For me, this has always been a relatively manual process since each participant has several scores (one for each insight).

Once you have scored each participant’s responses, it’s time to take the average opportunity score. To make this easy (using small numbers), let’s say we had five respondents to the insight of minimizing the time it takes to research where to stay on a trip. We got the following opportunity scores from the five participants:

• 6

• 5

• 7

• 8

• 6

We would then take the average of these scores and get an opportunity score for this insight of 6.4. We would do this for each insight so we understood the average opportunity score across all participants.

As I said, I’ve done this fairly manually on a spreadsheet (not the most fun), but there are some templates out there like this one, but they have slightly different setups to what I’ve used in the past.

How I’ve Used the Opportunity Gap Survey

I’ve used the opportunity gap survey quite a few times in my work to help with prioritizing qualitative research insights, especially when we were overwhelmed with the amount of information and no other prioritization model helped us.

An example

We had just finished an extensive project, with 25 diary study participants answering daily questions and then quite a few follow-up interviews to clarify some of the data. When I looked at our Miro board, I cringed at the amount of information on it. Everything was supremely interesting, and a lot of information was new. We’d looked at a new segment and how they found inspiration in fashion.

Since we’d rarely spoken to this segment in the past, we uncovered insights we’d never imagined, but, again, the team felt stuck. We had information and no idea how we could begin to prioritize what was most important to our customers, especially since we still didn’t know them well enough.

We had about thirty insights, which were too many to put into the opportunity gap survey. To narrow down which we would use, I facilitated a prioritization workshop. In that workshop, we went through all the insights, and we assigned a weight to each of them. That weight was based on how many participants had mentioned the given insight.

Once we’d weighed all the insights, we used part of the RICE prioritization model to predict our perceived reach, impact, and confidence of each of the insights. We left off the effort piece because there was no solution to base an effort level on. We used the weight of each insight to predict our confidence in it. In the workshop, we went through each insight and plotted it on an RIC matrix.

We ended up deciding on ten insights that we felt would have the biggest reach and impact for that segment. I turned those insights into survey questions:

We sent the survey via qualtrics. Luckily, we had a really large panel and had the budget to use our platform to recruit even more of our particular segment. We ended up with 500 responses to the survey, which was right around where we were targeting (we had a significantly large target population).

I then scored the different insights and plotted their scores on a graph:

The insights that had a high average level of importance and a low average level of satisfaction are those we decided to focus on right away.

We sent out two subsequent phases of the survey to include the other twenty insights we’d found and added to the graph and continued to reprioritize if we found another underserved insight or unmet need, based on the opportunity scores.

I shared this graph with my teams to help them visualize the scores and it hugely helped us with taking all that wonderful data and figuring out the best place to start, based on our users’ perceptions rather than our own.

The Impact Membership : A space for user researchers who think bigger

You know your craft. You’ve run the studies, delivered the insights, and seen what happens when research is ignored. You’re ready to go beyond execution and start making real strategic impact but, let’s be honest, that’s not always easy.

That’s where the Impact Membership comes in.

This is not another free Slack group or a place to swap survey templates. It’s a curated community for mid-to-senior user researchers who want to:

• Turn research into influence – Get insights to stick, shape product and business strategy, and gain real buy-in.

• Break out of the research silo – Learn from peers facing the same challenges and work through them together.

• Stay sharp and ahead of the curve – Dive deep into advanced research strategy, stakeholder management, and leadership.

Why join now?

• You don’t have to figure this out alone – Every member is carefully selected, so you’re learning alongside people who truly get it.

• Get real value, fast – No fluff, no generic advice—just focused conversations, expert-led sessions, and practical guidance you can use right away.

• Make it work for you – Whether you want to participate actively or learn at your own pace, there’s no pressure—just a space designed for impact without overwhelm.

Membership fee: £627/year or £171/quarter

This isn’t just about keeping the lights on. Your membership funds exclusive research initiatives, high-caliber events, guest speakers, and a space that actually pushes the field forward.

Spots are limited because we keep this community tight-knit and high-value. If you’re ready to step up and drive meaningful change through research, we’d love to have you.

Join today

I was recently asked, “how would you measure the success of user research?” I took a deep breath and started explaining our general UX metrics, such as task success, task completion, the SUS, and then dove, proudly, into how these metrics could also impact important business KPIs (I talk about both in this article). I …

Read more