AI synthesis fails incredibly plausibly. Structured findings, clear themes, confident language and somewhere in there, an insight with no evidence behind it. I've been stress-testing this for a month and the gap between "looks right" and "is right" is where researcher credibility goes to die. I'm joining Tom Barragry from Survicate on May 6th to get into exactly this, where AI genuinely holds up in research workflows, where it'll quietly get you burned, and what human-in-the-loop actually looks like beyond the buzzword. 45 minutes, free, and worth your Wednesday.

Join us!

Attempt one 💩

The first time I created a customer journey map, I had no idea what I was doing, as you can see below:

I was the first and only user researcher working at a hospitality platform. Not only was I the first and only UXR, but it was also my first and only (real) job as a user researcher. Before this role, I did ad-hoc projects for family/friends and volunteered at charities or organizations to improve my skills (and build case studies).

So when I was tasked with creating a customer journey map, I did the one thing I knew how to do: googled it.

Unfortunately, in that day and age, user research resources were few and far between. I couldn’t simply look at templates online because there weren’t any. I couldn’t read articles on Medium because it was only one year old at the time and not filled with user research content.

So I scrambled and did my best to create the dumpster fire “customer journey map” you see above. Needless to say, people were quite disappointed in the result, but they couldn’t one hundred percent pinpoint why because they weren’t even sure what a customer journey map was. And I definitely wasn’t at the point in my career where I had the ability to ask what people needed and start with the goals.

There sat my customer journey map. Sad, alone, and looking suspiciously like a task flow rather than a journey map. It was a mess, and I was bummed out that I didn’t provide my team with what they needed.

After that, people dropped the concept of a journey map, and we went on with our regularly scheduled usability testing and sending out surveys to a too-small sample size.

However, luckily, over time, I learned to distinguish between a task flow and a customer journey map and how to create one. And I’m going to walk you through the step-by-step process I took to create one of my favorite journey maps I’ve created thus far.

Why and when are customer journey maps important?

Sometimes we tend to rush to decisions to create a deliverable. Someone shouts that we “need” a customer journey map without thinking about why or what we need it for. This very conundrum has led me to create many deliverables that have taken a Herculean amount of effort and, subsequently, have barely been looked at. We want to avoid that situation!

So before diving into how to build a customer journey map, we should explore why and when they can be important.

Why are customer journey maps important?

Customer journey maps highlight what the customer experiences as they interact with a product or service. It is the end-to-end journey someone takes with your product.

Consider when you interact with a digital product or service. It typically takes you several steps to do the things you want to do with the product, or you might come in at different parts of the stage. Some journey maps even show us the decision-making process before someone uses a product or service.

Let’s take a quick example from real-life. About a year ago, my husband and I were planning our end-of-2022 and 2023 trips. As I looked at the (alarmingly large) number of trips we were planning to take (having global families is fun), I thought about the pets and how we would contend with getting someone in to look after them, especially during Christmas and the summer.

I researched the problem and discovered kennels and pet sitters charge enough money that we could have taken several extra trips on top of what we already planned with the money we’d spend on pet care. With this, I found an alternative solution on Trusted House Sitters - you pay a yearly fee, and people travel to your house and stay there for free on holiday while looking after your pets.

Once I found this solution, I filled out all the necessary information about our house, the pets, sitter responsibilities, amenities, a welcome guide, and I set the dates. I then vetted people for the dates we would be gone (ranging from people already living in Jersey but wanting a break from family, to a nomadic couple from France, to a retired couple from the US). I booked them in, and we were done!

If that company wanted to understand the full journey I’d gone through, they would have started by asking me about my entire process, from when I was aware of the problem to when I booked the pet sitters.

And why is this important information to know?

Customer journey maps are a clear visualization that shows the ups and downs someone goes through, the unmet needs not reconciled, the pain points they encounter, and the feelings they have when using your product. It is a clear answer to the ever-burning question of, “what do users think of us?” or “what are users doing on our product?”

Customer journey maps can highlight problem areas in our product and lead us into solution-land, resulting in us either improving what we currently have or innovating to become more advantageous against our competitors.

Not only that, but customer journeys can be wonderful tools to condense a lot of data into a visual that’s easy to present and act on.

When should we use them?

Instead of picking a customer journey map out of a deliverable hat, it’s important to understand that what we want is aligned with what a customer journey map can give us. Usually, that discrepancy is why we are so disappointed with deliverables.

The goals I typically have for customer journey maps are:

• Deeply understand the customer’s end-to-end experience with our product and service

• Identify gaps in the current experience, particularly those that are painful for customers and where we don’t currently support them

• Uncover unmet needs that could lead to improvement or innovation

• Help teams recognize the importance of working cross-departmentally on solving problems by demonstrating the importance of creating a coherent and jointed holistic customer experience, from sales to customer support

• Foster empathy for the current experience across the organization

  ---

Below, I walk you through the full framework I used to turn a sad, dusty “journey map” into a decision tool teams actually used:

• The proto-journey workshop format (how I ran it across six departments without it turning into a blame-fest)

• The interview approach (how I mapped the end-to-end journey across multiple roles, not just the “user”)

• The synthesis workflow (how we combined front-of-house and back-of-house data into one map teams couldn’t ignore)

• The journey map build (what I captured per phase: who, goals, tasks, time, emotions, pain points, plus internal actions)

• The activation plan (the workshops that turned the map into roadmap changes, tighter handoffs, and fewer internal fire drills)

Paid subscribers get the full walkthrough, the workshop agenda, the interview guide, and the exact mapping template I used to build the final artifact.

Exclusively for paid subscribers

Read more

Research deliverables f*cking suck. I’m a words person. I do not have a design bone in my body, not even the tip of a pinky bone. I will write you a beautiful report. I will not make you a beautiful journey map and yet somehow half my job is making beautiful journey maps.

So when clients started asking for dynamic deliverables lately, my honest reaction was that I don’t even like static deliverables, how am I going to make dynamic ones?!?!?!? I’m not even dynamic.

Then I sat down with Claude Cowork one evening, uploaded two screenshots of a bogstandard journey map I made years ago at a now-defunct travel company, wrote an embarrassingly bad prompt (”how can we make this more dynamic”), and watched something kind of amazing happen. This video is me playing around, live, with very little plan. Things break. I yell at Claude (who, for the record, is a dude). I burn through some Lovable credits I was saving for actual work. And by the end I’ve got something I genuinely wish I’d had ten years ago.

What I cover:

1. From two flat screenshots to an interactive, segmented, three-persona journey map in one prompt. I fed Claude the world’s most standard journey map with goals, tasks, pain points, quotes, the usual, and a prompt that I am not proud of. Claude came back with a toggleable map across three user types (occasional, first-time, power), moments of truth, a backstage layer, channel dimensions, impact-vs-effort opportunities, and pain points ranked high, medium, and low. Not perfect but already more useful than anything I’ve ever built by hand.

2. The real journey is a mess and Claude can finally show that. Every journey map I’ve ever made has been a lie. Real people don’t walk in straight lines from Awareness to Conversion. They loop, they abandon, they come back three days later on a different device. We simplify, since showing the mess is genuinely hard and takes forever. I told Claude I wanted the realistic version. It gave me a more real scenario: 12 days, 7 sessions, 5 backtrack loops. You can scrub through it on a timeline. That sentence alone is more interesting to a stakeholder than my entire old journey map.

3. Pain points linked straight to Jira tickets. Opportunities linked to prototype prompts. The whole point of a journey map is to make someone do something. So I had Claude wire each pain point and opportunity to backlog tickets (manual now, Jira-connected later) and then try to link out to Lovable and Figma Make with a prompt pre-built to prototype the fix. Some of it 404’d. All of it pointed at something I couldn’t have dreamed of making myself a year ago.

4. This is a genuinely bad prompt and I want you to see it anyway. I’m a huge fan of prompt engineering. The prompts in this video are not that. I left them in on purpose. When you’re experimenting, perfect prompts aren’t the point, throwing stuff at the wall is. You do not need a flawless prompt to get something useful. You need to start.

5. The thing we used to beg others to build, we can now build ourselves. When I was making journey maps early in my career, I printed personas and taped them in bathrooms so people would actually look at them. That was the bar. Now I can hand a stakeholder something interactive they can click through, segment, and give feedback on without a wait. It’s not “AI replaces researchers,” it’s “researchers finally have the means, the power, and the resources to make the things we’ve always wanted to make.”

This is me experimenting live. A proper walkthrough with real prompt engineering is coming. I wanted to get this out now anyway, since it’s the most fun I’ve had with research deliverables in years, and I want you to go try it too.

Watch the full thing above then go make something ugly and cool.

Want Claude working like this without the “oh god what’s my prompt” moment?

I built the UXR Claude Skills Bundle for exactly this reason, 52 research skills installed directly into Claude, so the right framework shows up the moment you need it. Journey maps, TEDW interview guides, the insight formula, the Pyramid Principle for reports, the whole toolkit with no re-explaining, no starting from a blank chat every time.

One-time $49, lifetime access (updates included), and installs in 5 minutes.

Get the Bundle →

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I am an avid planner - I always have been, even when I tried to fight it. Planning ahead assures me that things will have a certain outcome and that everyone will be on the same page with expectations if anyone else is involved.

When it comes down to it, for me, planning is about managing expectations.

I didn’t apply this to my professional life for a long time. When I transitioned into user research, I was completely self-taught. Yes, I did a UX Design course at General Assembly, which mainly taught me I can’t design, but other than that, I read books and did my best to piece together the profession.

In my first role as a user researcher, I had little concept of planning. My colleagues and I would talk about research that needed to be done, and I would go and do it. At the time, I didn’t have the capacity to question why we were doing specific projects, asking certain questions, or what the outcomes were supposed to be.

My main downfall, and the reason behind this, was perfectionism. I wanted to appear like I was good at my job and that I knew everything.

We have to survey our users to determine what about our app was unintuitive? Sure thing!

We have to do discovery research to verify our assumptions? Can do!

In fact, I tried:

I didn’t know how to structure a goal — trust me, searching for user research goals and examples of them ten years ago led to absolutely nothing. The Interwebs was not my friend back then.

I didn’t know what to question, let alone how to respond to my stakeholders when they had questions.

What did this lead to?

• Lack of clarity on what I was trying to research (either too broad or narrow in scope), which made it a nightmare to figure out appropriate methodologies and which questions to ask

• Mismatched expectations on what colleagues got as outcomes of the research project

• Inability to focus during the research because I was unsure about what topics I needed to cover or what I could skip

• Little alignment on why we were doing the research project and what would make it successful in the end

What this list leads to is one word: disappointment. I don’t know about you, but (to me) nothing is worse than disappointing my team. And I’ve also found with disappointment comes skepticism. If research isn’t bringing value, do we need to do it? What’s the point?

That’s the last thing I wanted. So, I vowed to do better and, over time, built a research plan that I now use as a starting point (yes, still, to this day!) for my research projects.

What is a user research plan?

A user research plan is a document that lists the different parts of the research project, including why the research is happening to the research outcomes. They give you and the team an amazing overview of the research project and remind people exactly what the project is about, which greatly helps with scope.

The best part of a research plan is aligning people into a shared understanding so that everyone’s expectations are properly set up. Expectations are key when it comes to user research.

If a stakeholder is expecting that they will get a journey map out of a research project and we come to them with a written report, it won’t be the best of times.

Or, if a stakeholder expects deep insights and we conduct a survey, there will be a huge mismatch in the outcome.

A research plan is a forcing function (in the best sense possible) to get everyone’s thoughts and expectations of a research project out on paper, giving you, the researcher, clarity on how to best navigate the project for the necessary outcomes.

Below, I walk you through the full system I use to stop “random acts of research” and start running studies with clean scope, aligned stakeholders, and outcomes people can actually use:

• The research plan framework that protects you from disappointment (how to set expectations, lock scope, and stop “wait, I thought we were getting a journey map” chaos)

• The “does this project suck?” test (how to spot un-answerable requests early, push back without drama, and avoid wasting weeks documenting nonsense)

• The intake document that replaces endless follow-up meetings (the exact prompts that force stakeholders to show their homework and give you what you need up front)

• My complete research plan template, section by section (background, stakeholders, assumptions, goals, success criteria, methods, recruitment, deliverables, timeline, scripts, resources)

• Two real examples you can copy (one generative plan, one evaluative plan, written the way stakeholders actually read)

Exclusively for paid subscribers

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

“But it gives us numbers.”

“No thanks.”

That’s the first thing I said when faced with the suggestion of conducting a quantitative usability test.

I was more than happy with my conversation-filled qualitative usability tests. Asking people about their immediate reactions, how they perceived the screens, and their general thoughts on what was confusing and missing. It was a routine I quickly felt comfortable in and enjoyed.

But there’s always a but, isn’t there?

It came when I was sitting with my team, and we were chatting about a flow that many of our users were having trouble with. I had triangulated some data from previous research where the topic had come up, customer support tickets, and also from account managers.

I told my team that we had enough to understand most of the pain points, especially the important ones, and make changes. I was at a point in my career and at the organization where I was privileged enough to be able to say no to user research requests.

Luckily (at the time, it felt unfortunate, but for my career, it was a good thing), my manager was sitting in the meeting. He’s one of the most fantastic managers I’ve ever had (Hi, John 👋🏻), and he asked me a smoldering question:

“How will we know if the changes we make improve the usability?”

Of course, John already knew the answer to his question, but he directed it to me. I knew what he was going for, but I was terrified of the answer.

All I wanted to do was make the changes and then ask the users if the changes we made were helpful — I was even willing to sift through the customer support tickets for the next few months to see if complaints decreased. Anything to stay away from the numbers.

But my team was beaming. This was exactly what they wanted: a clear and straightforward way to measure usability and progress. There was no backing out. It was finally time for me to conduct quantitative usability tests.

And I am so glad for that push because they have become an absolutely essential part of my user research toolkit and have also helped me become a well-rounded (and promoted!) user researcher.

What is quantitative usability testing?

Usability tests, on a whole, are about having participants attempt to do the most common and important tasks on a product/service. While you conduct the test, you, as a researcher, are looking to find problems the participant runs into during the test. You then take these problems to your team and, together, brainstorm and find ways to fix the usability issues — which are sometimes simple and other times complex.

With qualitative usability tests, you are talking to the participants and describing the different reactions, perceptions, or issues they encounter.

However, with a quantitative usability test, you can still describe the problem, but you measure:

• How many people encountered a problem

• How many people were able to complete the tasks

• The time it took them to complete tasks

• How many errors participants ran into

• What types of errors participants encountered

• Participants’ perceptions of usability

With quantitative usability testing, you can find out a lot of important information that can help you generate the impact of your research. For instance, when I was working at a travel company, we conducted a quantitative usability test on our checkout flow.

We found that people were taking a long time to fill out information that ultimately wasn’t that relevant and, thus, dropping off and abandoning the flow for a competitor that was easier to use.

Based on these results, we made some significant changes and retested the flow after the improvements were made. We reduced the time it took to fill out information by 50% (which was faster than people could do on the competitive product as well), and we reduced abandonment by 35%. This meant that we increased revenue by £75,000 annually.

Big impact.

When it comes to measuring usability, we can break that down into three major areas:

1. Effectiveness: Whether a user can accurately complete tasks and an overarching goal

2. Efficiency: How much effort and time it takes for the user to complete tasks and an overarching goal accurately

3. Satisfaction: How comfortable and satisfied a user is with completing the tasks and goal

Below, I walk you through:

• How exactly to run a quantitative usability test for your team (with examples from my work)

• The most important metrics for you to know

• How to write a quantitative usability tasks/scenarios that give just enough detail to your participants

• How to analyze the results for tangible benefit to your team

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

For me, quantitative usability testing was always super straightforward. I put a high-fidelity design or live product in front of someone and asked them to do certain tasks, which I then measured through metrics like task success, time on task, and surveys like the Single Ease Questionnaire.

There was very little room for asking qualitative-based questions or for introducing bias. We were there to truly understand the effectiveness, efficiency, and satisfaction of what we put in front of the participants. Straightforward. Easy, dare I say. In fact, I could even set up an unmoderated test to get even more participants.

However, I felt uncomfortable when it came to qualitative usability testing. I never seemed to be able to strike the right balance and constantly felt like I was asking leading and biased questions. I hated the standard questions like:

• “What would you expect to see?”

• “What do you think of this?”

• “What would you change?”

• “Explore the interface and tell me what you would do.”

I hated those questions because they were so hypothetical and future-based. I felt like I was asking the participant to develop ideas and design the website or app. The data I got from those questions was skewed and unhelpful.

Very rarely, if ever, as a user, do I sit on a website and think, “What am I expecting to see?” I can’t remember the last time I went to a website or app to explore the interface. And, although sometimes I do have opinions on websites/apps, my opinions likely wouldn’t be helpful or actionable to teams trying to make changes.

“This is dumb” is not a very actionable quote.

Below, I walk you through the full approach to make qualitative usability testing stop producing fluffy, hypothetical feedback and start giving your team clear direction on what to fix, what’s missing, and what’s confusing:

• The “what qualitative usability testing really is” definition (why it’s not true usability testing, and where it sits between concept testing and quant usability testing)

• The goal checklist that tells you when this method fits (the exact types of decisions and uncertainty it’s built for)

• The TEDW-based question builder (how to replace “what do you think?” with prompts that pull real experiences, perceptions, and friction without leading)

• The session structure you can reuse (warm-up, overarching scenario, screen-by-screen flow, and wrap-up questions that don’t turn into opinions-only noise)

• The synthesis + activation workflow (deductive tags, affinity by screen, clustering patterns, and the built-in handoff into an ideation workshop so the work actually moves)

Exclusively for paid subscribers

Read more

I’ve spent the past few months watching synthetic research show up everywhere. Conference talks. LinkedIn posts. Case studies. Every time I saw it, I had the same reaction. This is going to be a disaster.

Not because synthetic research is inherently bad, but because I know what happens when a new tool promises efficiency. Someone uses it to skip the real work. Someone points to synthetic data and says “we don’t need to do user research anymore!”

I’ve cleaned up those messes before. I’ve been in the room when analytics replaced interviews, when surveys replaced conversations, when speed became more important than understanding. Every single time, the promise was “this will make research faster and cheaper.”

Every single time, we lost something that mattered.

So when synthetic research started gaining traction, I braced for the worst.

Then I looked around and realized this isn’t a future problem. This is already happening. 73% of market researchers have already tried synthetic responses. A third are using it regularly. Companies like Booking.com and Dollar Shave Club aren’t experimenting with it, they’re building it into their research practice.

The market moved without me.

And I had to ask myself: am I avoiding this because it’s actually bad, or am I avoiding it because I’m scared of what it means?

From Panic to Openness

Qualtrics asked if I’d be willing to test their synthetic audiences feature and write about the experience. My first reaction was panic. Was I going to try something like this? And how would it go?

Through the anxiety came another thought. How will I ever know if I don’t experience this?

I’ve been that person before. I was deeply suspicious of surveys when I was a qualitative purist. I thought unmoderated testing would never work. I resisted Jobs to be Done because I worried it would replace other frameworks I valued. Every time, my fear was the same, that this new thing will make my skills less valuable. Every time, I pushed these methods away and, ultimately, my career suffered.

I eventually tried the above methodologies and learned that they don’t replace what I do. They just give me a different way to approach certain problems.

Maybe synthetic research was the same.

So I said yes.

What I Needed to Understand First

Before I ran anything, I had to understand what I was actually testing and what synthetic really was because, trust me, there are a lot of different definitions out there.

Not all synthetic is AI randomly generating responses based on what it thinks humans might say. That’s what generic LLMs do when you ask them to “pretend to be a user.” Those fall apart fast. The responses are too agreeable, they lack demographic variation, they miss all the nuance that shows up in real research. It’s like having someone pat you on the back and tell you, “yes, that is the best product idea ever!”

I found that Qualtrics works differently. It’s trained on millions of actual human survey responses collected over 25+ years of research. When you ask it a question, it’s not guessing or fabricating. It’s looking at patterns across massive amounts of real human data and predicting what humans would likely say to that question.

This kind of synthetic data is model-generated data that’s built to mimic how a real audience might respond. Think of it as a way to explore likely patterns without running a full study with live participants. The key idea here is that mimicry isn’t the same thing as replication. In research, replication is tied to real people, real sessions, and repeating a study to see if the outcome holds. Synthetic data isn’t trying to do that. It isn’t claiming to recreate lived context or match what real participants would say word-for-word. It’s built to give you a fast, pattern-based preview of how a defined audience is likely to react, so you can learn, compare options, and move with more confidence before you invest in full fieldwork.

That difference matters. One is AI making stuff up. The other is AI drawing on what humans actually said when asked similar questions.

Source

I still went in skeptical, but at least I understood I wasn’t testing random text generation. I was testing whether a model trained on real research data could show me something useful before I talked to a single person.

The Research Question

I picked a research question that felt like appropriate territory for testing synthetic: how do people make food decisions when they’re tired, stressed, and low on money?

This question type matched what synthetic is actually designed to handle. Synthetic performs well with perceptions, preferences, and intent-based questions.

As of right now, it doesn’t perform as well with past behaviors, detailed recall, and awareness questions. So I avoided anything like:

• “Tell me about the last time you ordered takeout”

• “Walk me through your typical dinner routine”

• “How often do you meal prep?”

Those questions need memory. They need a biography. They’re asking people to reconstruct events and explain what happened. That’s not what synthetic is for. And, for me, that actually allowed a sigh of relief. Those questions above are the bread and butter of my deep, qualitative research and they aren’t what I would be asking a synthetic panel. I could save those for human-based research.

Instead, I focused on the mental state that shapes decisions:

• What mindsets do people bring to food choices when they’re under pressure?

• What kinds of friction stop people from deciding at all?

• What does “good enough” mean when you’re exhausted and broke?

• What would actually help in those moments?

These questions are about recognizing patterns, not recalling specific events. They focus on mental shortcuts and trade-offs.

WIth this, I built a 13-question survey. Every question had clear scenario framing, a specific cognitive task, and distinct answer choices that felt similar to those I’d create in a standard survey.

I kept the screening broad, just “are you involved in household food decisions?” You can screen with synthetic, you just can’t go hyper-niche, just like in real research. Screening for moms, millennials, pet owners, households of 3+, specific income brackets? Fine. Screening for “left-handed surgeons from Omaha?” That’s not happening. It’s the same as human research, the more niche you go, the harder it gets.

I launched the survey on a Wednesday morning.

By noon, I had 500 responses. How’s that for speed?

What The Data Actually Showed Me

I was met with a dashboard of data which, as a qualitative researcher, can sometimes feel overwhelming, but I took a deep breath and scrolled through the results.

Each question was broken down in several ways:

I really wanted to read the results as I would a traditional survey that I sent to real humans to fill out. The force was real with this. But, I took a step back first and really thought about how I would analyze these results. I took the first question: Now imagine it’s the end of a long day. You’re hungry, tired, and don’t feel like cooking, but you also have a limited budget this week. Which option becomes more important in your decision?

When I look at a synthetic-based chart like this, the goal isn’t to pretend I’m staring at “real behavior.” I was looking at a pattern the model thinks is likely when people are tired, hungry, short on time, and trying not to overspend. It’s a stress-test scenario. The value is in seeing how priorities reorder when the pressure dials up.

This is how I read the chart:

“Choosing something filling, even if not healthy” gets the strongest pull. In a depleted moment, people want to feel fed. Satiety beats ideals, beats convenience, beats health. It becomes the anchor. If I were running real sessions, this is where I’d expect the richer stories on what “filling” means, where they go, what they reach for, which shortcuts they trust.

“Sticking to something low-cost” sits right behind fullness. Tired or not, budget pressure stays in the picture. This gave me a directional hint that cost is a constraint people keep even when their energy is shot. In live research, I’d probe how they manage that tension. What counts as “low cost” in their mind? What crosses the line?

“Using what I already have” lands in the middle. It tracks with what real people say, that the intention is there, and it matters, but it’s easier to abandon when they’re drained. Synthetic data is giving me the shape of that trade-off, not the emotional story behind it.

“Getting something fast, even if it costs more” was lower that I expected. With a tight budget in the prompt, synthetic response showed a prioritization of price and fullness over speed. That doesn’t mean speed stops mattering for real people. It just means, in this hypothetical, it’s not the dominant driver.

“Skipping a meal to save money” sits at the bottom, but it’s not zero. That’s a cue for segmentation, not a headline. In real research, this is where I’d ask one of those beautiful, open-ended questions from above, “Walk me through the moment you decide not to eat. What’s happening right before that choice?”

“Not much changes for me” shows up in every study, real or synthetic. It’s the group with strong routines or fixed habits. They stick to their script regardless of energy or budget shifts.

Here are some other ideas I discovered while looking through the results.

The Cost-Versus-Speed Tension

One question asked: “When you’re low on time or energy, which of these factors usually has the biggest impact on your food choice?”

The results came back nearly split: “Cost” at 143 responses (29%) and “Speed” at 135 responses (27%).

Synthetic responses showed me that when people are tired and resource-constrained, cost and speed genuinely compete as decision drivers in human behavior. Neither factor dominates cleanly in the model’s prediction because neither factor dominates cleanly in real human decision-making. Results from the synthetic data said that humans are split on this because it’s a genuine dilemma they navigate.

I might not have seen that tension as clearly if I’d just written the question and jumped straight to interviews. I might have assumed one factor would always win. I might have designed my interview guide assuming cost would be the primary driver and missed the whole speed dimension.

This became a key area to explore in follow-up human research. When does cost win? When does speed win? What makes someone prioritize one over the other? The synthetic data had flagged where genuine decision-making complexity lives before I’d talked to anyone.

The Emotional Overwhelm Discovery

Another question asked: “What would make you completely give up on choosing food and go to bed without eating?”

“Feeling overwhelmed or anxious” came back at 222 responses (44%), which was significantly higher than practical barriers like “not wanting to clean up after” (112 responses, 22%) or “realizing everything costs too much” (101 responses, 20%).

I’d designed that question thinking about practical constraints like money, effort, time. But the model highlighted emotional overwhelm as a much bigger driver of food decision abandonment than practical barriers.

I’d been thinking about this as a resource constraint problem. How do people choose food when money and time are limited? But the model was indicating that this is primarily an emotional regulation problem. People don’t give up because the barriers are too high, but they give up because making one more decision feels unbearable.

When I redesigned my interview guide for follow-up human research, I centered the emotional state instead of practical constraints. I made that the primary lens for exploration rather than treating it as a secondary factor.

The “Good Enough” Complexity

I asked: “Which of these feels most like a ‘good enough’ food decision when you’re tired, busy, and low on money?”

The distribution came back with no clear winner: “something I had already planned” (153 responses, 31%), “anything hot, filling, and settles my hunger” (138 responses, 28%), “something that is comforting or emotionally satisfying” (107 responses, 21%), “something that meets a low-cost threshold” (99 responses, 20%).

“Good enough” doesn’t mean one thing to humans. The model demonstrated that all of these definitions of “good enough” show up with roughly equal frequency, likely because they’re drawing on genuinely different frameworks depending on which resource (physical energy, emotional capacity, money, cognitive bandwidth) is most depleted in that specific moment.

When you’re physically depleted, “good enough” means something that fills you up and settles your hunger. When you’re emotionally exhausted, “good enough” means something that brings comfort. When you’re financially stressed, “good enough” means hitting a cost threshold. When you’re cognitively overloaded, “good enough” means not having to deviate from the plan you already made.

The flat distribution was the model telling me that I’d asked a question that collapses multiple real human patterns into one. When I designed follow-up human research, I split this into separate questions focused on physical needs, emotional needs, financial constraints, and cognitive load. That separation allowed for much clearer exploration of how different resource depletion states drive different definitions of “good enough.”

The synthetic data hadn’t just caught a poorly-worded question. It showed me I was conflating multiple human decision frameworks that needed to be understood separately.

While reviewing the results, something shifted. Not in a “this changes everything” kind of way, but in a “huh…this is actually interesting” kind of way. I started to see where this could fit into my workflow.

What This Actually Gave Me

After two days with the data, I had to ask: was this worth it?

I didn’t get finished, complete insights. I didn’t learn everything about how people make food decisions under stress. I wouldn’t feel comfortable walking into a meeting and presenting findings that would drive our next biggest product decision.

But I also didn’t waste anyone’s time. I didn’t recruit participants for a survey with broken logic. I didn’t schedule interviews based on assumptions that turned out to be wrong. I didn’t build a research plan around questions that collapsed multiple concepts.

Instead, I learned where the complexity was before talking to anyone. The cost-versus-speed split showed me there’s genuine tension in how people prioritize. The overwhelm spike showed me I’d underweighted emotional factors. The flat “good enough” distribution showed me I’d conflated multiple decision frameworks.

I redesigned my research approach with better questions. Instead of asking broadly about “good enough” decisions, I split it into questions about physical needs, emotional needs, and financial constraints. Instead of treating food decision abandonment as a practical problem, I centered on emotional regulation. Instead of assuming one factor would dominate the cost-versus-speed trade-off, I designed my interview guide to explore the tension.

I saved weeks of iteration time. If I’d skipped synthetic and gone straight to human research, I would have recruited eight people for pilot interviews, spent three sessions realizing my questions were off, spent three more sessions trying to figure out what I should have asked, and then recruited twelve more people for a second round with better questions. That’s 20 participants and three to four weeks of calendar time minimum. Synthetic compressed that learning cycle and helped to narrow the scope of a very broad study.

By the time I sat down with real participants, I wasn’t wondering if my questions made sense anymore. I was listening for the nuance synthetic can’t capture and the reasons why people make specific choices, with the emotional context around decisions, and the moments where behavior contradicts stated preferences.

I could focus on listening because I wasn’t worried about structure.

So, yes, to me this felt worth it.

A Note on Data Richness vs. Data Poorness

Data-rich organizations have massive amounts of customer data, years of research, thousands of completed studies. They’re not using synthetic because they have no data. They’re using it to drill deeper into the data they already have.

Data-poor organizations are the opposite. They are startups, small teams, companies entering new markets, researchers exploring completely new problem spaces. They don’t have years of existing research to draw from. They can’t afford to run massive studies. They need directional clarity fast, and they need it cheap.

That’s where synthetic becomes really interesting.

If you’re exploring a new market and you have zero data about how people in that space think, synthetic can give you initial pattern recognition based on what the model has seen across millions of responses in adjacent spaces. It’s not definitive and it’s not finished insight, but it’s enough to help you figure out which questions are worth asking humans and where the complexity might live.

Or take the “water cooler ask” scenario. Your VP drops by and asks, “Hey, do you think our customers would care about this feature?” You don’t have time to spin up a full study. You need directional sense in the next day or two. Synthetic can help you triage whether this is worth a real study, or can we deprioritize this?

Or feature prioritization when you have ten concepts and you need to narrow to three before you invest in validation research. Synthetic can help you screen fast without burning participant goodwill or budget on ideas that won’t make the cut.

Nobody’s replacing human research. They’re using synthetic to figure out where to focus their human research or to move faster with human research when they don’t have the luxury of time.

It’s triage. It’s prioritization. It’s the pre-work that helps you not waste resources on the wrong questions.

The Dance

For me, the most interesting use isn’t synthetic OR human. It’s the dance between them.

I could start with synthetic to map the territory quickly, like to see where tensions live, which concepts need exploration, what questions I’m not asking yet. Then bring in humans to understand the why behind those patterns. But it doesn’t stop there.

Sometimes human research surfaces something unexpected. Instead of just noting it and moving on, I could go back to synthetic to test whether that’s a broad pattern or an edge case specific to the five people I talked to. Then back to humans to dig into the nuance if it looks like a real pattern.

It’s not linear. It’s iterative.

With my food decision study, synthetic showed me the cost-versus-speed tension. I’d bring that to human interviews and discover, let’s say, that the tension resolves differently on weekdays versus weekends. I could go back to synthetic and test that hypothesis across a larger set of responses to see if it holds. Then return to humans with a more refined question about what drives the weekday-weekend difference.

Or the emotional overwhelm finding that synthetic flagged. I’d explore it with humans and learn that it’s specifically decision fatigue, not general stress. Back to synthetic to see if that distinction shows up in how people describe the overwhelm. Then back to humans to understand what actually helps with decision fatigue versus other types of stress.

The dance is what makes it work. Synthetic gives you speed and breadth to test hunches. Humans give you depth and context to understand what the patterns mean. You need both, and you need to know when to use which.

I didn’t see that coming. I thought I’d use synthetic once, pressure-test my questions, and move to humans. What I actually discovered is that the back-and-forth between them is where the real value sits.

What I’d Use This For

After this experience, I know exactly where synthetic fits in my practice.

Pre-research testing: Before I invest time and participant goodwill on a real survey, I can use synthetic to rehearse. Test if my questions make sense. See if different demographic groups might interpret things differently. Catch confusing wording or weak spots before anyone real has to deal with them. It’s like a dress rehearsal before opening night.

Follow-up exploration: After I collect real data and find something unexpected, I can use synthetic to explore “what if” scenarios without having to recruit a whole new round of participants. Test additional questions I forgot to include. Stretch my research budget by running quick follow-ups to probe areas where the human data pointed to something interesting but didn’t give me enough depth.

Concept screening and feature prioritization: When I have ten concepts and need to narrow to three before doing validation research, synthetic can help me screen fast. I’m not using it to make the final decision, but using it to figure out which three are worth the investment of real human research. Same with feature prioritization, I can quickly assess which features seem most valuable before committing resources to full validation.

The water cooler ask: When someone drops by with a question and I need directional sense-making fast, synthetic can help me triage. Is this worth a real study? Should we deprioritize this? Can I give them enough direction to make a next step without spinning up a whole research project?

Data-poor exploration: When I’m exploring a completely new problem space or market where I have zero existing research, synthetic can give me initial pattern recognition to help me figure out which questions are worth asking humans and where complexity might live.

What I absolutely wouldn’t use it for:

• Answering research questions on its own without human validation

• Understanding personal motivation, emotion, or lived context

• Making high-stakes product decisions without any human input

• Past behaviors, memory, or detailed recall questions

• Anything where getting it wrong would hurt people

• Replacing interviews, usability testing, or actual human research

The Fear I Started With

The fear of “is this going to replace me?” was never really about synthetic research. It was about value.

We worry that someone will decide our work isn’t necessary. That someone will find a faster, cheaper way to get “insights” and we’ll be left explaining why depth matters, why context matters, why you can’t replace human understanding with pattern recognition.

Using synthetic didn’t make that fear go away.

But it did clarify something for me. The work that matters, the listening, the probing, the synthesis of human stories into understanding, can’t be automated. A model trained on millions of survey responses can tell me where patterns exist. It can’t tell me why those patterns matter or what they mean for any individual person.

But the prep work like the question testing, the concept narrowing, the structural validation, can be faster. And when you speed up the parts that don’t require human voices, you create more space for the parts that do.

What I’d Tell Another Skeptical Researcher

If you’re reading this because someone asked you to try synthetic and you’re suspicious, I get it. I was there three months ago.

Keep your skepticism. Don’t let anyone tell you synthetic can replace human research. Don’t let anyone pressure you into treating AI-generated responses like they came from real people. But you can try it once with clear boundaries.

Pick a research question that’s attitudinal and forward-looking. Write 8-10 questions with clear scenarios and distinct options. Run synthetic. Look at the data for pattern flags and complexity signals, not finished insights.

Then ask yourself:

• Did this help me design better questions?

• Did it show me where complexity lives?

• Did it save me from wasting participant time on bad design?

• Did it help me figure out where to focus when I bring in humans?

If the answer is yes, you’ve found a tool that can make your human research stronger.

If the answer is no, you’ve confirmed your skepticism with evidence instead of assumptions.

Either way, you’ll know.

I’m still a qualitative researcher. I still need human voices. I still believe depth and context and lived experience are irreplaceable.

I just have one more tool for figuring out the right questions to ask before I involve the people who matter most.

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

—

Sarah Doody is a UX Researcher & Product Designer with 22 years of experience. She is also the founder and CEO of Career Strategy Lab, a UX job search and career coaching company where she helps UX and product people get hired or promoted with average 5-figure salary increases. She is also the host of the podcast, Career Strategy Podcast that offers weekly tips and case studies about what’s working in the UX job market and hiring right now. Sarah also speaks at conferences worldwide including UXLX, UX London, AIGA, Productized, Front, Industry, and more.

In our conversation, we discuss:

• How Sarah used research practices to pivot from product work into career strategy, and what nearly a decade of data has taught her about getting hired and promoted.

• Why most job searches fall apart when people skip self-research and jump straight into resumes and portfolios.

• A simple career “journey map” exercise that helps surface patterns across roles, managers, projects, and personal energy.

• How a career roadmap creates focus, reduces rejection fatigue, and shapes better job decisions over time.

• The role of a clear compass statement in shaping resumes, portfolios, interviews, and confidence during a search.

Major takeaways from the episode

1. Sarah frames career growth using the same structure teams use to build products: research, synthesis, direction, and iteration. When people skip this step, job searches turn reactive and exhausting. A roadmap restores clarity and control by anchoring decisions to what actually works for you.

2. Resumes and portfolios break down when they’re built without context. Sarah explains how a simple highs-and-lows timeline across the past year can surface repeat signals around team fit, management style, project type, and energy. Those signals matter more than any formatting tweak.

3. Applying to hundreds of roles creates rejection loops that drain momentum and self-trust. Sarah links this pattern to panic behavior and short-term thinking. Fewer, better-aligned applications often lead to stronger interviews and better outcomes.

4. Career decisions ripple into mental health, relationships, time, and identity. Sarah urges people to layer real-life constraints and goals into their roadmap so work supports the life they want, rather than consuming it.

5. A strong compass statement acts like a thesis for your career. It guides which roles you pursue, how you frame your experience, and how you talk about your strengths. This clarity shortens resume cycles, sharpens interviews, and restores confidence under pressure.

Where to find Sarah:

• Website: www.careerstrategylab.com and www.sarahdoody.com

• LinkedIn: www.linkedin.com/in/sarahdoody

• Youtube: www.youtube.com/sarahdoody

• Instagram: www.instagram.com/sarahdoody

• Career Strategy Podcast

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 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.

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

I remember a time when stakeholders started to get excited about user research. It was an interesting switch for me — I went from constantly checking in to identify user research projects within teams to colleagues coming to me with research project ideas in hand.

It👏🏻was👏🏻awesome👏🏻

I felt like research was exploding. I felt like I finally had a say. I felt like I finally had power.

But “with great power comes great responsibility” (Source: Uncle Ben + others).

And I quickly realized that, with these research projects, as exciting as they were, I started to feel extremely overwhelmed by them. It wasn’t necessarily the amount of projects (that would come later) but rather the number of questions people had within each research project.

The first time I encountered this was at my job at a social media management company. One of my stakeholders had an idea in mind for a concept they wanted to test. We had heard several times within previous research that the analytics on our platform were not aligning with users’ expectations and needs. In fact, they fell short in several key areas.

Some of the key pain points highlighted from previous research included:

• We did not provide sufficient engagement analytics for our clients, inhibiting them from making data-driven decisions

• Many clients were asking for manual reports from account managers as our platform isn’t providing sufficient metrics/data that allows them to compare data

• Our current metrics had little context and weren’t very useful/reliable for our clients to make decisions

These were some pretty big flaws in our platform, rendering it an underutilized feature and, ultimately, creating more work for customers and our account managers.

So, with that in mind, my stakeholder came to me with a concept based on this previous research. I was thrilled. Not only had they listened to previous research, but they had used it as a jumping-off point for a concept! Hurrah!

And then I looked at the list of questions this stakeholder had that they wanted answered within the research project:

• Do people understand the concept?

• Do people like the concept?

• Do people perceive our recommendations as trustworthy?

• What types of comparison timelines do people prefer when it comes to analytics?

• What kind of engagement metrics are most important to see?

• How do people perceive the difference between engagement and interaction metrics?

• Can people use the concept?

• Would they like to use the concept to try it out?

• Are people annoyed when they have to open a new window to compare data?

• Is it clear how people navigate through the concept to get a monthly report?

😱😱😱😱😱😱😱

Not only were these a whole lotta questions, but they were also a lot of unideal-for-qualitative-user-research kinds of questions. There was no way we could answer so many questions in a 60-minute concept test, let alone get answers to the majority of these questions.

I went back to the stakeholder, terrified that I would disappoint them. I had just started the research ball rolling, and the last thing I wanted to do was say no to a research project or tell them that I couldn’t answer these types of questions.

Since I was still early on in my career, I had a tough time rewriting and narrowing down the scope of the questions. We went into the concept test with way too many yes/no and preference questions to answer.

This was one of the first projects that had landed on my desk from a stakeholder, and the results were a bit disappointing. Because the small sample sizes within qualitative user research aren’t ideal for answering yes/no questions (all the “do” and “are” questions), I didn’t have much impact.

Saying, “8 out of 12 people understood the concept,” was not powerful.

Similarly, saying “7 out of 12 people liked the concept” did not tell us anything. Many of the stares I got during my report said, “So what?” or “What now?”

I was gutted (my new British slang). That wasn’t the first or the last time I received a research project with a slew of questions that were either impossible to answer with user research or were way too broad in scope.

If you’ve ever been handed a 20-question laundry list and told “can you just test this,” the next part is your escape. Paid subscribers get the full system I use to:

• Turn “do/can/which/are” questions into interview questions that actually produce stories

• Separate what research can answer vs what needs A/B testing, analytics, or a survey

• Cut scope fast without disappointing the stakeholder

• Run a clean prioritization meeting that ends with a short, usable question set

• Use the upgraded spreadsheet (columns, definitions, scoring) to make decisions in real time

• Spot repeated questions across teams and turn them into strategic research themes

• Walk through the full example (your analytics concept test) with a finished sheet you can copy

Exclusively for paid subscribers

Read more

Subscribe now

I’ve received a ton of questions recently on how UXRs can use AI more in a day-to-day workflow so I recorded this quick to showcase how creating and using specific AI agents can help with:

1. Offloading tedious/mundane tasks or starting with a draft versus a blank

2. Getting an additional perspective on something

3. Training others with more guardrails

If this looks like something that would benefit your team, happy to have a chat to see if I can help through a training workshop!

Let me know if you have any thoughts or questions below.

PS - If you need some help with prompt engineering, check out my AI Prompt Library for UXRs!

Happy researching!

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Concept testing can sometimes feel like a mystery. There were quite a few times in my career when teams put an idea in front of me and asked me to test it with users (well, to validate or ask for preference, which we don’t do, of course 😁). And for some time, I felt incredibly stuck when my teams made these requests.

The ideas weren’t solid enough to conduct a usability test.

They weren’t basic enough for me to conduct generative research.

These concepts were in the in-between (or the upside-down, if you will 😂).

Whenever a team came to me with these concepts, I cringed. I had no idea how to get them the information they needed without leading the participants and asking biased questions. I knew I shouldn’t be asking things like:

• “Do you like this idea?”

• “Would you use something like this?”

• “How would you make this better?”

• “Is this going in the right direction?”

But I wasn’t sure how else to engage with participants.

So, I tried to conduct usability tests on concepts. That ended as a major failure. The ideas were too early to test. Participants got lost and confused because there wasn’t a flow. And, to be honest, I had no idea what I was trying to test. My goals for those research projects were vague, and the findings were unhelpful.

We understood that people had a hard time navigating a loosely defined concept, but we still had no idea whether or not we were heading in the right direction. Each of those reports ended up disappointing not only my teams but also me.

It was by chance that I heard about the concept of concept testing (very meta, I know). At first, I wasn’t sold. How were we meant to evaluate concepts in an unbiased way? And how were we meant to investigate their reactions without relying too heavily on future-based data?

But, after some more disappointing results and failed usability tests on ideas, I finally decided to give concept testing a whirl. Admittedly, I wasn’t very skilled at conducting those tests, but with some practice and guidance, I finally understood the importance of concept testing. And, from there, I never looked back.

What is Concept Testing, Anyway?

Concept testing is one of those elusive methods that, I believe, we don’t discuss nearly enough, as it can be an extremely powerful tool to use early in the discovery process. Because it can be such an “in-between” method, we often skip it, going straight from generative research to usability testing.

However, concept testing definitely has its place in our process. The way I define it is:

Concept testing is a way to engage with participants to more deeply understand a specific problem and their current process through a stimuli (concept). Through concept testing, we gather feedback that allows us to gauge how aligned we are (or not) with participants’ mental models regarding an idea.

Within the scope of this definition, we are looking for immediate reactions and perceptions from our participants. We are looking to see how participants respond to the idea and where there are gaps or confusion about what we’ve put in front of them.

This is the crux of the definition and often where I can see concept testing go wrong (and where I’ve done it incorrectly before).

Where Concept Testing Goes Wrong

As I mentioned, it took me a good amount of practice to hone my concept testing skills. Because it is a less-discussed methodology, I struggled with finding the proper resources on how to conduct a concept test and what exactly I was looking for as an outcome.

Unfortunately, I see concept testing used a lot for things like:

• Product/idea validation

• Preference testing

• A/B testing

• Asking about future-based behavior

When I first started concept testing, I made these mistakes. I wanted the concept test to tell me whether or not participants liked the concept, if they would use it or not, and if I tested multiple concepts, which one they preferred.

The problem with all of the above is that concept testing is still a qualitative method. And with qualitative methods, we can’t answer these types of questions. Qualitative user research isn’t set up for success to answer “whether or not” or “if” or “preference” questions.

Qualitative research involves uncovering reactions, perceptions, feelings, and mental models. Concept testing should be no different.

When I first started conducting concept tests, I asked many of those questions, and the results were more disappointing than the usability tests I had attempted to run on the concepts.

What did it mean if people liked or disliked a concept? What did preference mean when it came to the concepts? How would we know people would actually use the product in the future? Not only that, but usually, during these tests, there can be social desirability bias present, where participants will tell you what you want to hear.

So, when I delivered my results, my teams weren’t always sure what actions to take. We knew that people liked the concept and which they preferred, but there was so little depth to the answers and so little action within the data that the teams ended up feeling just as stuck as before.

From there, I changed how I thought and approached concept tests, ensuring that I got my teams the data they needed without asking participants questions that could skew our decision-making.

If concept testing has ever made you freeze, this next part is the fix.

Paid subscribers get the full concept testing playbook:

• A quick “Should we even run a concept test?” decision checklist

• A goal-setting script to pull the real decision your team is trying to make

• A concept setup guide (what to show, how low-fi to go, what to avoid)

• A question bank built for concept testing (TEDW prompts + follow-up ladders)

• Run-of-show templates for 60 and 90 minutes (1 concept, 2 concepts, 3 concepts)

• Sample screener prompts to recruit people with the real problem, not hypothetical interest

• A synthesis workflow tailored to concept tests (deductive tags + clustering pattern map)

• An ideation workshop plan that turns findings into prototype-ready directions

Exclusively for paid subscribers

Read more

• The fear and skepticism many researchers feel toward synthetic users, especially around job security and research quality.

• How a synthetic panel works in Qualtrics, step by step, including setup, question design, and early signals.

• The tension between stated advice and lived behavior in synthetic data, and how that tension becomes a clue for deeper human follow-up.

• How synthetic results can help shape hypotheses, narrow scope, and surface mental models worth examining with human participants.

• The role of experimentation, reality-checking, and ethical use when bringing synthetic insights into a human-centered research practice.

Key Takeaways:

1. Synthetic users aren’t a replacement, they’re a low-stakes way to surface potential thinking paths worth exploring. Fear of being replaced is real for many UXRs, but synthetic panels don’t replicate lived experience. They can spark ideas, highlight tension in responses, and point toward questions worth asking humans, but they don’t carry nuance, emotion, memory, or contradiction. They’re an extra tool, not a takeover. 

2. Synthetic panels help you see mental models earlier, especially the ones users rarely say out loud. The synthetic example in the video about routines revealed goal-driven thinking mixed with self-doubt, which is a pattern worth validating with real people. This gives researchers a head start when writing interview guides or structuring probes. It doesn’t give you truth, but it does give you direction.

3. Synthetic data is great for pressure-testing your own questions before running a study. I described how running a synthetic version of a study I’d previously done with humans showed where the survey and interview questions held up and where they needed tightening. This kind of dry-run can save time, catch weak spots, and help teams narrow scope before talking to real people.

4. Researchers still need to reality-check everything with humans. Synthetic outputs are predictions shaped by large datasets, not lived stories. Human sessions reveal timing, emotion, contradictions, and subtle meaning shifts that synthetic models can’t replicate. You can use synthetic to form hypotheses, but every hypothesis needs human evidence behind it. 

5. Ethical and intentional use must lead the way. Researchers should be the ones teaching teams how to use synthetic panels responsibly. That means knowing where they fit, where they fail, and how to protect user trust. Synthetic tools aren’t going anywhere, so UXRs benefit from learning how to guide their use with clarity and care.

The companion guide to synthetic users:

Want to learn even more about synthetic users? Check out the companion guide to this video which goes in-depth about responsible, intentional, and ethical synthetic user usage.

Try Qualtrics:

Want to try this out on Qualtrics? You can request a demo below:

Try Qualtrics

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!

—

Berkay is a UX researcher with over eight years of experience, mostly in e-commerce and banking, working across both B2B and B2C. He has a bachelor's and a master's degree in product design and design research. His focus is on turning research into actionable insights, improving research processes and helping teams make user-centered decisions. Basically, reducing uncertainty. He also co-founded UXR Playground, Turkey’s leading UX platform, where he runs trainings, workshops and mentorship programs. In a past role, he built and led a ResearchOps team, creating systems to make research more efficient and scalable.

In our conversation, we discuss:

• The eight-step framework Berkay uses for smooth, ethical participant recruitment, built from actual interviews and field work.

• Why many researchers are flying blind with recruitment and how junior researchers often end up as accidental call center reps.

• The most common screw-ups in screener surveys and how to write questions that don’t sabotage your study before it starts.

• How Berkay built a participant panel inside a 30-million-user company without a budget, and with legal breathing down his neck.

• Why most panels fall apart after setup, and what to actually prioritize if you want yours to last longer than three studies.

Some takeaways:

1. Ethics aren’t optional. If you’re collecting personal data, you’re responsible for what happens to it. Berkay shares how one company got sued after leaking participant emails. It’s not a footnote, it’s a risk. Build ethics and legal compliance into your process from day one, or you’ll learn the hard way.

2. Most companies are bad at recruitment and fixing it takes more than tools. Berkay got so fed up with watching junior researchers waste hours cold-calling participants that he turned the whole thing into a research study. The findings? A total lack of structure, zero shared frameworks, and a ton of internal guesswork pretending to be process.

3. Bad screener surveys kill good research. Asking “Do you use this app?” is a great way to recruit liars. Berkay shares simple but smart ways to avoid bias in screeners like using multi-select questions, hiding the research topic, and adding duplicate questions to sniff out lazy responses.

4. Building a panel sounds smart until you have to maintain it. Setting up a panel is the easy part. The real challenge is keeping the data clean, staying GDPR-compliant, and making participants feel like they’re still part of something. Regular outreach (like quarterly surveys) and strong ties to your data team are non-negotiable.

5. A good panel is a cross-team operation. Berkay didn’t just build a landing page and hope for the best. He brought in product, customer support, PMs, and data science from the start. If you want a panel that works across research needs and methods, it has to be owned across the company too.

Where to find Berkay:

• LinkedIn

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 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.

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Most researchers I know have the same story. The same raised eyebrow. The same deep sigh before they open another LLM convo and brace for disappointment.

The first time I tried to use AI for something “simple,” I remember asking it to help me dissect a stakeholder brief. I pasted the vague, chaotic message, something along the lines of “We need to test the new dashboard design before Friday; can you put something together?” and waited for help.

What I got back looked like someone had skimmed a UX blog from 2012 and stitched together a few polite sentences. It read like a student trying to impress their professor without actually doing the assignment. No context. No understanding of the politics behind the request. No reading between the lines. Definitely no sense of the real decision hiding underneath the pretty words.

The problem is that we’ve been throwing AI at UXR tasks with the same energy we bring to reheating leftover lunch. Fast. Distracted. Half-formed prompts that barely capture what we actually need. Then we blame the AI when it hands back something flat, vague, or straight-up wrong.

Most UXRs are stuck in this loop:

• You give AI a tiny prompt.

• It gives you a tiny answer.

• You rewrite everything yourself.

• You decide AI isn’t ready.

• Then you go back to doing everything the slow way.

But, at the same time, you really have been burned.

You’ve tried using AI to:

• Clean up messy notes

• Summarize a long research plan

• Rephrase an insight for an exec

• Draft a kickoff email

• Clarify a brief written by a PM who sprinted through it between meetings

And the output felt like it came from someone who wasn’t in the room with you.

I’ve spoken to senior UXRs in fintech, SaaS, marketplaces, health tech, people who run teams, shape roadmaps, and handle cross-functional chaos every day, and every single one of them says something like:

“I can see the potential…but I don’t trust it.”

Not because AI is bad.

But because nobody taught UXRs how to use AI in a way that respects the complexity of our work. We didn’t get training.

We’re self-teaching in the middle of deadlines. We’re experimenting with prompts in between interviews. We’re trying to make sense of output that feels helpful one minute and deeply misguided the next.

AI becomes incredibly powerful for researchers once you give it the kind of direction your craft already relies on which is precision, context, constraints, intention, and the decision you’re supporting.

The magic doesn’t come from the model. The magic comes from your brain, paired with a structure that helps the AI act like a competent partner instead of an overeager intern.

Most researchers give up after a few half-hearted prompts. You ask something generic. It spits out something shallow. You move on. It’s not that AI can’t help you think better, it can, but only if you know how to push it.

Now we’re going to walk through the entire research process, from messy stakeholder kickoff to crisp, confident insights, and turn AI into the kind of co-pilot you’ve wished for since your first week as a researcher.

Why Pancake Prompts Fall Flat

If you’ve ever asked AI for help and felt mildly offended by the output, you’re not alone. Most researchers start with tiny prompts, get tiny answers, and assume the model just isn’t good enough. It’s the same energy as handing someone a sticky note that says write the whole report for Monday? and expecting them to read your mind, decode your org politics, and magically land on something useful.

The problem isn’t the AI. The problem is the prompt.

I know that sounds like the kind of patronizing advice thrown around LinkedIn, but stay with me. I spent months testing how UXRs actually prompt AI across dozens of real projects, interviews, surveys, strategy sessions, prototype tests, you name it, and most of the prompts UXRs write fall into the same patterns:

1. The “do everything for me” prompt

Example: “Write a usability test.”

What the AI hears: “Guess wildly.”

2. The “here’s a crumb, bake a cake” prompt

Example: “Help me write a kickoff doc.”

What the AI hears: “Please hallucinate intentions for me.”

3. The “I’ll tell you the task but not the stakes” prompt

Example: “Suggest tasks for a survey.”

What the AI hears: “Throw generic content at the wall.”

When you feed AI a prompt that thin, you get output that reads like the UX equivalent of a cookbook written by someone who has never eaten food. Lacking any awareness of real-world messiness.

AI has no idea what you actually care about unless you tell it.

And UX research is built on a whole lot of context:

• Why the team wants this research

• What decision sits behind the request

• Who’s pushing for speed

• What’s riding on the outcome

• What happened last time someone skipped research

• Who will use the insights

• What the constraints look like

• Which trade-offs matter

• What business metric is at stake

• How much is already known

• What’s being assumed without evidence

When your prompt doesn’t include these pieces, you’re asking an AI model to work blindfolded. I started experimenting with a completely different approach: stop treating AI like a vending machine, and start treating it like a very fast, very literal junior researcher who needs a real brief.

This is where the FAST model came from. A simple four-part structure that upgrades almost any prompt instantly.

Below, I walk you through the exact system that turns AI from “overeager intern” into a reliable research co-pilot:

• The FAST model (the 4-part prompt structure that fixes pancake prompts instantly)

• Before/after examples that show what “good” looks like

• Copy-paste prompts for kickoff, decision-mapping, risk surfacing, and assumption-breaking

• Mid-study checkpoint prompts to stop projects drifting off a cliff

• Synthesis guardrails so you get support without handing over judgment or raw data

Exclusively for paid subscribers.

Read more

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

Scroll through ten random UX researcher LinkedIn profiles or portfolios. Now read their first sentence.

“I turn insights into impact.”

“I help teams make data-informed decisions.”

“I bridge the gap between users and business goals.”

“I’m passionate about understanding people.”

“I create human-centered products.”

They all sound identical. You could swap the names and nobody would notice.

That’s not because these people lack skill or originality, most of them are damn good at what they do. It’s because somewhere along the way, our field decided there was one “right” way to sound credible.

And that “right” way?

It’s safe, forgettable, and painfully generic.

How We Got Here

Research is one of the few jobs where humility is baked into the culture. We’re trained to center others, not ourselves. So when it comes time to talk about us, our work, our value, our strengths, we default to method.

We say things like:

• “I ran a diary study with 12 participants.”

• “I conducted a thematic analysis.”

• “I helped prioritize roadmap decisions.”

Unfortunately, that’s not a story. That’s a report.

Hiring managers aren’t looking for a walking method manual. They’re looking for someone who solves real problems in ways that matter to the business.

They want to know what happens when they drop you into chaos. What you notice first, what you fix first, what you never let slide.

That’s what makes you different, not how many frameworks you know.

Why You Sound Like Everyone Else

You’ve spent years trying to prove research is valuable so, naturally, you’ve learned to speak the company’s language: value, impact, ROI, decision-making.

The problem is, everyone else learned it too and now every resume sounds like a press release written by ChatGPT.

Here’s a quick test.

Pull up your LinkedIn headline or the intro on your portfolio and ask yourself:

1. Could another researcher copy and paste this, and it would still make sense for them?

2. Would a PM instantly know what kind of researcher you are, not just that you “do research”?

3. Would a hiring manager reading it think, “I’ve never met someone like this before” or “Ah yes, another empathy-builder”?

If you’re hitting yes on 1 and no on 2 and 3, congratulations, you’ve officially joined the Sea of Sameness.

But don’t panic. This is fixable.

How to Spot Your Generic Patterns

Before you can sound unique, you have to know what’s making you blend in. Here’s a quick, 15-minute exercise you can do right now:

Step 1: Copy the intro section from your resume, portfolio, and LinkedIn About.

Throw them into one document. Don’t edit yet.

Step 2: Highlight every phrase that could apply to almost anyone.

These usually sound like:

• “I’m passionate about understanding users.”

• “I help teams make user-centered decisions.”

• “I collaborate cross-functionally.”

• “I use mixed methods to uncover insights.”

• “I translate data into actionable outcomes.”

If you can find those phrases on ten other researchers’ pages, they’re not helping you.

Step 3: Circle every phrase that sounds like you.

These are rare, the lines that make someone pause and think, Oh, that’s interesting.

Maybe it’s:

• “I’m the researcher teams call when they’re completely stuck.”

• “I turn vague ideas into testable experiments.”

• “I specialize in getting stubborn stakeholders on board.”

Those are the lines worth keeping.

You’ll probably end up with a page covered in yellow (generic) and three sentences circled in green (specific). That’s a good sign because you’ve just found the starting point for your unique story.

The UXR Sameness Checklist

If you’re not sure how “blendy” your self-presentation is, run through this list.

Every “yes” answer means you’re still too safe:

• I describe my work using frameworks instead of outcomes.

• I talk about empathy more than decisions.

• I summarize projects like case studies, not stories.

• My portfolio could belong to a dozen other researchers.

• My headline sounds professional but says nothing new.

If you nodded along to at least three, you’re probably underselling yourself.

Why This Matters

Being a great researcher doesn’t automatically make you memorable. When a hiring manager screens 50 candidates, they’ll all have similar skills. What makes someone stand out isn’t what they do, it’s how they think and what problems they instinctively solve first.

That’s what you need to uncover and then communicate. And no, you don’t need to “personal brand” yourself into some loud influencer. You just need to show your research fingerprint, the unique way you bring order to chaos.

Below, I walk you through the full framework to stop sounding like every other UXR and start sounding like the person teams remember:

• The 3-layer “uniqueness” model (so you can name what you do that actually changes outcomes)

• The Career Audit Sprint (your evidence-first method to uncover repeatable patterns)

• The Researcher’s Value Equation (a simple way to translate your work into business value without corporate robot language)

• The 3-sentence core message formula (the version you can paste into LinkedIn, your portfolio, and interview intros)

• The Uniqueness Map (a one-page artifact that becomes your resume/portfolio/interview cheat sheet)

Paid subscribers get the full walkthrough, fill-in-the-blank templates, and the exact rewrites that turn “generic” into unmistakable.

Exclusively for paid subscribers

Read more

—

Brittany is a mid-career research leader based out of Portland, Oregon. She holds a Bachelor's degree in Industrial Design from the University of Oregon and a Masters in Information Science from the University of Michigan. She has worked with startups, nonprofits, mid-size and Fortune 100 companies as an independent contributor as well as a manager of research teams.

Currently, you can find her building a research practice (and team) at Chorus Innovations, a startup working to provide innovative behavioral healthcare solutions to agencies, counties, and states across the U.S.A. Before Chorus, she managed a large research team in an agency environment supporting topics related to consumer trust and privacy for big tech clients.

She firmly believes research and collaborative teams are at the heart of every successful business, and that everyone’s life story would make a great movie. When she isn’t working, she enjoys outdoor adventures and wellness activities, and spending time with loved ones.

In our conversation, we discuss:

• How strategic research actually plays out in early-stage companies, and why researchers shouldn’t wait for perfect briefs.

• Moving from research receiver to research requester and how that shift changes your role entirely.

• Coaching ICs to trust their instincts when they’re the only ones seeing a gap.

• What makes something “strategic,” and how to avoid wasting time on low-impact requests.

• How Brittany and her team adapt when projects get shelved, priorities flip, or research gets ignored.

Some takeaways:

1. No one will ask for what they don’t know exists. Waiting for research requests is a trap. If you’re seeing patterns, pain points, or opportunities, you might need to be the one raising your hand. The best projects often start when researchers pitch work that no one else thought to ask for.

2. Gut checks are data points too. If a product decision feels off, or you’re thinking “we should probably look into this,” that’s reason enough to pause and dig deeper. The instinct to question is part of the job. Lean into it instead of waiting for someone else to validate it.

3. Strategic research doesn’t always mean big projects. It can be a one-question survey. A reused screener. A short desk research doc. What matters is that it moves things forward, not that it looks impressive in a deck.

4. Blocked ≠ Wasted. Brittany’s team logs blocked work in a “vault” and revisits it later. When projects get paused or dropped, they reflect on what caused the stall. Sometimes it’s organizational. Sometimes it’s a signal that previous research wasn’t shared well enough. Either way, it’s fuel for doing better next time.

5. Every team needs a vision even if it only lasts six months. In startup settings, long-term planning is a luxury. Brittany meets with her team every 3-6 months to reset direction, recheck learning goals, and match priorities to what’s actually happening across product and design. It keeps the team from floating aimlessly when the org shifts.

Where to find Brittany:

• LinkedIn

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 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.

Subscribe now

P.S. Paid subscribers get access to full archive, all content, a private Slack community, Substack lives, and a hub of templates, scripts, and mini-courses

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

Learn exactly how I’ve set up many a repository in Notion — I use this set up for in-house, consultancy, and advisory clients. It’s one of my most popular set-ups and I highly recommend trying it and getting feedback from your stakeholders.

Let me know if you have any questions!

Link to the Notion page

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!

—

Wolfram is a Senior UX Designer and Researcher and has been working at TeamViewer for eight years.He has been driving and advancing UX Research at the company for nearly two years, developing it further together with a young but highly talented and motivated team. He has been deeply involved with Jobs-to-Be-Done for over a decade and considers himself a pragmatic JTBD practitioner.

Before joining TeamViewer, he spent almost ten years in the Enterprise Content Management space and have been focusing on Multi-Device Experiences since the mid-2010s. He is the author of “Multiscreen UX Design” and has been passionately engaged in UX and design for around 25 years. His expertise lies in Jobs-to-Be-Done, hands-on and pragmatic UX research, as well as content design and content management. He regularly and enthusiastically participates in webinars, meetups, and conferences.

Beyond UX and design, he enjoys photography, particularly nature and bird photography, and loves spending time with his family. In the past, he was an avid groundhopper, traveling across Europe with friends to attend football matches.

In our conversation, we discuss:

• Why it helps to think of every user action as a “job” with a real outcome, not just a task or step.

• The messy overlap between jobs, goals, use cases, and what stakeholders think they want.

• Why most teams start in the solution space and how to bring Jobs thinking in without derailing the train.

• What an actual “job” sounds like in the wild, and how to spot one inside complaints, workarounds, and feature requests.

• Why Wolfram keeps outcome-driven language like “minimize the time it takes to…” as a rule and how it makes your findings way more usable.

Some takeaways:

1. Jobs to Be Done is a lens. Wolfram doesn’t wait for permission to use JTBD thinking. Whether he’s asked for a usability test or feedback on a feature, he still pulls out the job behind it. Why? Because understanding the job gives you reusable insights that don’t die with the feature.

2. Stop obsessing over the perfect term. Stakeholders just need to get it. Wolfram avoids technical jargon like “JTBD” when introducing the concept. He uses terms they already know, like “use cases” or “problems,” so they’re not thrown off. The focus is clarity, not vocabulary.

3. Your users are already giving you jobs, you just have to listen for them. Complaints, feature requests, emails, even rants. All of these hold clues about what someone was trying to do. If you dig in with curiosity (and a few “tell me more”s), you can usually find the real goal underneath the noise.

4. Do it late if you must but do it anyway. Sometimes research doesn’t happen until the build is already underway. That doesn’t mean you skip the problem space. Wolfram brings in JTBD insights midstream, not to stop the train, but to nudge it toward stronger value delivery and set up better decisions next time.

5. Your feature might flop but your jobs research won’t go to waste. If the solution turns out to be unworkable or doesn’t land, you don’t have to throw away the research. JTBD insights stay valid. They’re reusable, solution-agnostic, and can fuel the next iteration or a totally new idea.

Where to find Wolfram:

• Multiscreen UX Design (book)

• Website

• LinkedIn

• Twitter/X

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 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.

Hey. Welcome to the real user research party. We’re basically best friends now.

If you thought this was gonna be another polished UXR newsletter from someone with a perfect ponytail and zero scars, oh honey, wrong door.

I’ve been the 2am wine-fueled Google warrior screaming “insights that don’t suck!” into the void. The team of one. The ignored deck. The researcher watching “leadership liked it anyway” launch the dumb thing.

Now I help 14k+ UXRs ship research that actually changes roadmaps. Not with theory. With scripts that work on PMs you’d like to scream at (hey, I’ve been there). Templates from my real work. ROI math that saves your budget.

This isn’t “best practices.”

It’s the Research Influence System, the messy, battle-tested shit I built from my own beautiful disaster.

Subscribe now

Free: The good stuff

• 1 article every two months

• 1-2 Podcast epis/vids every month

Paid: The full survival kit

Everything in free+

• Substack Hub: my Notion brain dump with 40+ templates, scripts, mini-courses. Copy-paste your way out of blank-page hell.

• Private Slack community (I actually show up)

• UXR Tools Bundle

• Full Substack archive

• Weekly actionable as hell post via either an article, video, or audio

Your current sh*tshow? Pick one.

Stakeholders ignoring you

• How to Use the Pyramid Principle to Write Research Reports

• Deliver research insights that demand action, with zero guesswork

• Prioritize Qualitative Research Insights with the Opportunity Gap Survey

• Write impactful user research insights

• Activate Your Insights

Studies without the meltdown

• How To Run a Qualitative Usability Test

• The Subjectivity of Surveys

• Analyze & Synthesize Generative User Research

• How to run a quantitative usability test

• Have You Met TED(W)?

Prove ROI yesterday

• Use these simple formulas to show research ROI

• How to Track the Impact of Your Research

• Nailing your UXR OKRs - A framework for maximizing research impact

• “Great Insights!” Isn’t a Metric

Career/promotion chaos

• A UXR resume journey

• Write Your Best UXR Cover Letter Ever

• Create and present an impactful user research case study

• Watch me rip apart my UXR case study

• Assess and Advance Your Career as a User Researcher

Stop being the org’s dirty little secret.

Start shipping research that ships.

It’s great to have you here. Now we’re best friends. (Or, we will be anyway, if you subscribe!)

I’ll see you in your inbox shortly, hope you like unsolicited opinions on stakeholders, because it’s (almost) too late now.

Subscribe now