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

Subscribe now

If you’ve ever sat in a strategy meeting and watched the PM, the head of product, and the leadership team trade views on where the company should be in three years, and waited politely for someone to turn to you and ask the “user perspective” question, you’re not alone.

You probably know more about your users than anyone else in that room. You know the gaps in the product, the workarounds people have been building, the unmet needs that have been showing up in interviews for the last four quarters and that nobody has acted on yet. But none of that translates into “where should we be in 2030,” and I don’t think it’s because you don’t know enough. I think it’s because you’ve been pinned to a completely different kind of question for so long that the strategic muscle has gone unexercised.

The roadmap is loaded, the stakeholders need a usability test by Friday, the PM wants to know if the new flow tested cleanly, and there’s another tactical question on your desk before this one is finished. That’s been the whole job, every quarter, for years. The “be more strategic” feedback keeps showing up in performance reviews, the strategy offsite invitation keeps going to product, and you keep getting looped in only when something has already broken.

I think the frustrating part is that we, as user researchers, are the most under-utilised strategic foresight resource in any company. We already do half the futurecasting job by training and instinct, but we just have only ever been allowed to point those skills at next quarter.

Why user researchers were trained for this work

I want to make a case I haven’t seen anyone make clearly enough yet, which is that user research methodology is, structurally, the foundation of futurecasting. We don’t think of it that way because nobody has framed it that way for us, but once you see it, the whole career path opens up.

Here’s what I mean.

We study the past to understand the future

Every method in our toolkit is retrospective. Interviews ask people about past experiences and past behaviors. Diary studies capture recent past behavior. Behavioral analytics is, by definition, a record of what already happened. Journey maps reconstruct past sequences. Usability tests reveal how users have learned to interact with patterns over time. We are trained from day one to extrapolate forward from observed past behavior, which is exactly what futurecasting requires at its core.

When I conduct a generative interview about how someone manages their finances, I’m not really asking about today, I’m building a model of how their behavior has evolved over the last 5-10 years and using that trajectory to predict what they’ll need next. That’s futurecasting, just at the individual user level. The strategic version simply scales it up to the population, the segment, the industry.

We already make defensible calls under uncertainty

Every research recommendation we make is a forecast. “Users will struggle with this flow” is a forecast. “This concept will resonate with mid-market buyers” is a forecast. “The drop-off here will increase if we don’t address X” is a forecast. We just don’t call them forecasts, we call them findings, and futurecasting is the same skill applied to longer time horizons.

We are signal-trained

Researchers spot weak signals in qualitative data for a living. The unprompted aside in interview number seven that becomes the seed of an insight three weeks later, the comment three different participants make in slightly different ways, or the friction users describe but cannot quite name. We are pattern-matchers by craft, which is the single most valuable skill in foresight work.

We have direct access to the most valuable signal source in any futurecasting model

Qualitative user truth, gathered first-hand, is something no industry analyst report can replicate. Most foresight practitioners get qualitative input through commissioned panels and second-hand transcripts. We have it as our day job, which is a structural advantage we have never used at strategic scale.

The reason we haven’t been doing this work is not that we can’t, it’s that we’ve been too busy.

What AI actually changes for researchers

I want to be careful here because I think synthesis is one of the worst use cases for AI. Synthesis is interpretation, and interpretation is the job. The moment we hand interpretation over to a tool, we lose our edge.

What AI actually changes is three different things.

The from-scratch tax goes down

Every research project used to start from a blank page. New discussion guide, new screener, new analysis structure, new readout template, new stakeholder briefing format. With AI, you build the scaffolding once, save it as a reusable skill or prompt, and never start from scratch again. That gets you 2-4 hours back per project, which compounds into days you didn’t have before.

Smarter democratization eases the bottleneck

Custom agents and trained skills mean a PM can run a first-pass usability review or a screener draft without me, which gets me out of the queue and into the strategic seat. I’m not training stakeholders less, I’m training them better, with agents that hold the rigour I’d want them to hold even when I’m not in the room.

AI brings together radically more signal types than one researcher could process by hand

This is the actual unlock for futurecasting, and it’s the one nobody is talking about enough. Doing the work futurecasting requires (interviews plus behavioral analytics plus market trend reports plus competitor product moves plus regulatory shifts plus macroeconomic indicators plus public conversation in customer communities plus adjacent-industry signals) has been functionally impossible at the individual researcher level. AI changes that, because it can hold many signal types in working memory at once, surface cross-source patterns, and let you read the clusters and form your own interpretation.

To be clear, AI is the cross-signal-bringing tool, not the meaning-making tool. We still do the interpretation, the calls, the recommendations.

What futurecasting actually is

Futurecasting is a discipline that generates actionable strategic data for organisations by extrapolating from past and current large-scale trends in a given industry or operating sector. The output isn’t a prediction, it’s a set of plausible scenarios, each with named landmarks the organisation can watch for to determine which scenario is becoming the actual future. The point is to help the organisation prepare for, weather, or thrive through the futures it’s most likely to face.

Three things separate futurecasting from “trend-watching” or “predicting the future.”

Rigor. Futurecasting builds models with structured inputs across past, present, and projected signals. Trend-watching is reading newsletters and forwarding interesting articles. The difference is the same as between a research plan and “let me just chat with some users.”

Scenarios, not predictions. Futurecasting generates multiple plausible futures rather than one bet, because single-point predictions at strategic horizons are reliably wrong. The UXR analogue is the difference between a hypothesis you test and a guess you defend.

Revisitability. Futurecasting models are living documents you revisit quarterly, marking landmarks and updating scenario probabilities as events unfold. Trend reports are dead the moment they ship. The UXR analogue is the difference between a journey map you maintain and a journey map that lives forgotten on a Confluence page.

The reason user researchers are particularly well-positioned for this work is that each of the four points I made in the previous section maps to a specific stage of the futurecasting method. Past-behavior training maps to model-building. Defensible calls under uncertainty map to scenario generation. Signal-spotting maps to the quarterly revisit. Direct access to qualitative user truth runs through every stage.

A short example of what this could look like. A B2B SaaS researcher I worked with noticed across six months of interviews that buyers kept asking variants of the same question, “How do I know your AI features are actually saving us time?” That single weak signal, layered against support ticket data showing rising requests for ROI dashboards and a Gartner trend report on outcome-based pricing, became a futurecasting topic about how mid-market buyer trust in AI-generated work would shift between 2026 and 2029. The model produced three scenarios, the leadership team picked one as the North Star, and the product roadmap shifted from feature-led to outcomes-led six months ahead of any competitor in the space. That’s what this method produces when it’s done well.

If “be more strategic” has been the feedback you keep getting in performance reviews, and you’ve never had a clear path to actually do it, this is the path.

Below, I walk you through the full 5-stage futurecasting method I use as a researcher, with the templates, prompts, and worked examples you can copy this week:

• The futurecasting topic-selection framework (the 5 questions I ask before I commit to a topic, plus the worksheet I use to test whether my topic is actually viable)

• The 3-layer model template (past, present, projected, with the exact 8 signal categories I include and the spreadsheet structure I use to organise them)

• A step-by-step scenario generation process for your specific industry, with worked examples across B2B SaaS, healthcare, consumer fintech, and internal productivity tools

• The North Star workshop format (the 90-minute agenda, the slides, and the “likely vs desirable” voting move that surfaces the strategic disagreement nobody usually names)

• The landmark log template I use to revisit models quarterly and track which scenario is becoming the actual future

• 12 Bad/Better rewrites you can copy across topic, model, scenario, workshop, and revisit stages

• The minimum viable futurecasting practice (how to start with two hours next week)

If you’ve been waiting for a method that turns “more strategic” from a vague performance review note into a real practice, this gives you one.

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-cour…

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-cour…

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

I have been thinking a lot lately about the part of research that I find genuinely the hardest, which is not the research itself but the translation work that happens after, where we take what we learned and try to turn it into something a designer can prototype, an exec can act on, or a product team can build into their next sprint. Most of us know what good research looks like, and I think most of us could write a clear interview guide in our sleep at this point, but the harder skill is being the connective tissue between what we found and what the team does about it, and that is the part of the work I keep wanting to get sharper at.

This video is a walkthrough of three workflows in Askable that I have been using to make that translation faster and more directly tied to the metrics stakeholders care about.

What I cover:

1. Designer briefs that turn findings into something a designer can actually prototype. I walk through the prompt I use to generate a designer brief that includes the top three to five most impactful unmet needs, the core user problem, specific behavioural improvements I am hoping to see, and the open questions a prototype could test, all tied back to business and team metrics. What I love about this workflow is that Askable has buttons that push the brief directly into Figma Make, Lovable, or Replit with the evidence cited inline, so designers stop sitting in the in-between state of “what do I do with this?” and can start exploring concrete concepts they can test. I find that this part of the workflow has been one of the bigger bottlenecks in my own practice for years, and being able to remove it has changed how quickly research turns into something tangible.

2. Executive summaries that respect how little time execs actually have. I have lost count of the number of times I have sat down with an exec, prepared what I thought was a tight presentation, and watched them check out by slide three, so the prompt I walk through here is built around getting to the point quickly, with three insights, each one including the problem, the business impact, the supporting evidence, the next steps, and why it is prioritised, tied back to metrics the company cares about. When I do not know the specific metrics a team is tracking, I default to the pirate framework, acquisition, activation, retention, referral, and revenue, since I find that those tend to work as a reliable shared language across almost every product team I have worked with. I also walk through how to layer in industry benchmarks without fabricating numbers, which matters a lot when you are presenting to stakeholders who will go and check your sources.

3. Customised reports for different stakeholders without writing the report ten times. One report has never really served everyone, and I think most of us know that, but most of us also do not have the time to write a tailored version for each team in the company. The workflow I walk through here lets you drill a single research study into different views for different audiences, so the loyalty team gets the loyalty cut, the IA team gets the IA cut, and execs get the strategic overview, all without starting from scratch each time. This part of research has historically been a capacity problem for me and for almost every researcher I know, and being able to address that with a workflow rather than with overtime is something I have genuinely appreciated.

4. The link between prototype opportunities and real metrics is what makes research stick. One of the things I appreciate most about this workflow is that every prototype opportunity is scored on complexity and evidence strength, and tied to specific business outcomes through the pirate framework. The reason that matters is that the hardest sentence for any researcher to earn the right to say is “my research directly moved these metrics,” and when the opportunities in your report are already mapped to the metrics your team is tracking, that sentence stops being aspirational and starts being something you can say honestly in a stakeholder meeting. I think a lot about how to make research feel less disconnected from the business, and this part of the workflow has been quietly useful for me on that front.

5. AI is the glue, not the replacement. The thing I keep coming back to in my own work is that researchers are the connective tissue between evidence and decisions, and I do not believe AI is going to take that role from us. What I do think is happening is that AI is making the production work faster, the briefs, the summaries, the reports, the reformatting for different audiences, so we can spend more of our time on the translation, the storytelling, and the strategic framing that no model can really do on our behalf. Using Askable across these three workflows has reinforced that view for me rather than undermined it, and I am sharing it here because I think it is the most important thing for researchers to keep in mind when we are trying out new tools.

Watch the full walkthrough above, and give Askable a try

Want to see how UX research teams at Google, Mastercard, BBC, Volvo, DHL, and American Express are making their work impossible to ignore? Join UX360 Europe, from June 23-24 in Berlin, for two days built around the central challenge of moving UX research from invisible to indispensable. Expect real case studies, honest conversations about influence and impact, and sessions that tackle what it actually takes to lead research at scale in 2026.

Whether you’re building a research practice from scratch or rethinking how your team demonstrates value, this is where Europe’s UX research community comes to think forward. 🎟️ Get 10% off your ticket with The UX Research Strategy community perk: TUR10

Register today!

I sometimes feel bad for personas because they can get such a bad reputation. Well, to be fair, all research deliverables can fall into a bad reputation, from customer journey maps to reports to charts.

However, I will say this:

It 👏🏻 is 👏🏻 not 👏🏻 the 👏🏻 persona’s 👏🏻 fault 👏🏻

(I’m really loving this whole clapping at every word thing recently - what an age we live in that emojis bring emotion to text 😜).

Personas (and other deliverables) are often set up for failure due to many different reasons:

1. They aren’t created with the right information, so they aren’t actionable (I know, I hate that word too and I’ll explain it better later)

2. There are too many created at once, so no one knows which to use when

3. There isn’t enough deep research done to create them, resulting in shallow information

See? The problem doesn’t come inherently from the persona as a deliverable.

So, what is the problem?

I’ve created and seen many personas in my career, and the number one problem, the number one reason people hate them, is:

No one uses the persona after it’s created.

We do all this work for the persona to sit in a corner, sad, alone, and unused. It’s like someone who doesn’t get picked for the dodgeball team. And then we (and others) think:

“What a colossal waste of time!”

And, yes, if the persona goes unused, it is a huge waste of time and energy, not only for you as the researcher but for your team and also your participants. It can be hugely frustrating to create an deliverable that goes unused but, when one takes such a large effort, it’s even more disappointing.

With the personas I have seen, I’m not surprised product/tech people dislike them. So, let’s look at a few of my previous unideal personas* before I bring you through my process of building better personas.

*Please don’t get discouraged if your personas look like this. We all start somewhere and it’s about improvement!

Before we rip apart my previous work (kill your darlings), I just want to remind us what the point and goal of a persona is:

Personas are a tool to help our teams more deeply understand the context of our users so that the team can make better decisions on:

1. What types of features/products/services to focus on

2. What to improve in the current features/products/services

3. What to create next that aligns with users’ needs, pain points, and goals

Ultimately, personas are about alignment. They aren’t magical unicorns that will give us answers to all our questions. We still need to answer the questions, but personas give us data to better answer those questions in a more informed and user-centric way.

My first-ever personas

My first ever user research personas

Aw - good memories. I created these personas in 2014, and they were the first I had ever created (as you may be able to tell).

This was a personal project I did as a case study for applying to user research jobs. The project was about how to rehome animals from shelters better by connecting people who needed to rehome their pets directly with those who wanted to adopt pets. Great concept, in my humble opinion.

However, looking at these personas, and going back to what I mentioned above as the point of personas, you might see where they fall short.

Although I did put in a little story (which I actually like to do now too), there is such limited information in these personas. If I gave these to a team and asked them to make decisions based on them, I wouldn’t be surprised if they told me that they couldn’t do so. In fact, I’d be blown away if anyone said they could make more informed decisions about the topic with these personas.

So, what really doesn’t work about them?

The information in these personas is incredibly vague and shallow. Look at some of the frustrations and pain points for Regina:

• “In a time crunch”

• “Not finding helpful resources”

And now for Adam:

• “Application process very difficult and uninformed”

WHAT DO THESE MEAN?

Absolutely nothing. If I gave you this information and told you to make a product, you’d look at me like I’m Fluffy from Harry Potter (although I think Fluffy is cute). There is absolutely no context, no supporting information. Time crunch? Everyone’s in a time crunch. Helpful resources? Which ones? HOW IS THE APPLICATION PROCESS DIFFICULT?

Also, what do someone’s hobbies, job, and personalily attributes have to do with this topic? Regina is “stubborn” (lol). HOW DOES THAT HELP US MAKE DECISIONS? It doesn’t.

Ah, it hurts me a little bit to see this persona, but IT’S OKAY. We live and learn.

Personas like these exist, and it’s no wonder that people hate them. As a tool, this is completely useless. It’s like, instead of a hammer to hit a nail, I just gave you a stick I found from a tree. A broken stick that’s been run over. These personas aren’t making anyone’s life easier.

My second try

You might recognize this format from my first resume 😂 If you couldn’t already tell, I am not a designer by trade.

But, really, personas don’t have to be pretty. They need to be filled with actionable and contextual information that help your team make better decisions. The sad part is, this persona wasn’t a personal project, it was something I took MONTHS to work on at my first role as a user researcher.

This persona was based on a hospitality platform that hotel staff had to use.

So, let’s break down what isn’t working in this:

• Sliders. No. Just no sliders on anything. Sliders aren’t helpful and usually convey data that is useless or made up. We aren’t here to take a personality test and score on the Myers-Briggs, so why does it matter putting thinking/feeling or perceiving/judging? This gives us NO useful data on users and takes up a good chunk of the deliverable

• Again, all of the information is SO shallow and not at all contextualized for our teams:

  • What does it mean to keep a team functioning happily?

  • What kind of data do they need about staff?

  • What resources are pain points and why?

  • WHAT PRODUCT CRASHES/BUGS? THAT’S A USABILITY ISSUE, NOT A PERSONA!!!!!!!

• Why does it matter if they are on social media? AND WHAT DOES A PARTIAL BAR OF SOCIAL MEDIA EVEN MEAN?

Nothing in this persona screams deepening empathy or helping teams make better decisions. It’s just full of fluffy information.

Again, I have seen a lot of personas that look like this. They completely fail product teams because of the lack of actionable information.

Below, I walk you through the full process I use to build personas that teams actually use (and keep using):

• The reverse-engineered persona workflow (so you stop guessing what belongs in a persona)

• The two workshops that make personas useful (information-gathering + proto-personas)

• Segmentation that doesn’t collapse into demographics (how to pick segments that guide product decisions)

• The research + synthesis system for 20+ interviews (debriefs, mini-synthesis sessions, and what to prioritize)

• Activation that prevents “persona poster syndrome” (how to embed personas into planning, ideation, and decisions)

Exclusively for paid subscribers

Read more

Free webinar with Qualtrics | Thursday May 14, 12 PM EST

Take one hour to learn when synthetic research makes your studies sharper, when it falls apart, and how to fold it into your workflow without sacrificing depth. I'll walk through real use cases and the RISE framework I built for interpreting synthetic results. This will be an honest conversation with someone trying out these tools because we need to get ahead of them, and learn how to use them with intention.

Grab your spot

I gave Claude two screenshots of an old journey map and a garbage prompt. He gave me back something I genuinely wish I’d had ten years ago.

Deliverables suck.

I’m going to start there because I think it’s the most honest thing I can say about the job. I’m a researcher. I do not have a design bone in my body, not even a pinky bone. I am good at words. I am very, very not good at visualisations. I will write you a very clear report. I will not make you a beautiful journey map. And yet somehow, half my job is making beautiful deliverables.

So when a few clients recently started asking for dynamic deliverables, my honest internal reaction was that I don’t even like static deliverables. What am I going to do with dynamic ones?

I sat with that feeling for a few days, getting more dread-y about it every time it came up. And then one evening I opened up Claude Cowork, which I’d been hanging out in for a while and finding genuinely fun, and decided to just play around. No plan, no proper prompts, just throwing things at the wall to see what stuck.

Two screenshots of a journey map I made years ago at a now-defunct travel company. A prompt so bad I am embarrassed to share it and about an hour of messing around.

The thing that came out of that hour was not just “a better journey map.” It was an interactive, three-persona, scrubbable, non-linear timeline showing real backtrack loops, with every pain point linked to a Jira-style ticket and every gap marked as an opportunity. Sarah’s booking odyssey over 12 days, 7 sessions, and 5 backtrack loops. That sentence alone is more interesting to a stakeholder than my entire old journey map.

I made a mess of recording it (Substack Live broke, then Loom broke). Other things broke and I yelled at Claude (who is, in my head, a dude, I don’t know why). I burned through Lovable credits I was saving for actual work.

But what came out of that hour shifted how I think about deliverables. So I went back the next morning, and the morning after that, and ran the same loop again on personas, then service blueprints, then a research repository. I broke it and rebuilt it. I figured out the prompts that actually work and the ones that waste an evening.

The video was the messy proof-of-concept and this post is the version where I tell you exactly what to do, in what order, with which prompts, so you can build dynamic deliverables on a Tuesday night without burning your Lovable credits.

What Claude Cowork actually is

Cowork is Anthropic’s desktop product for working alongside Claude on files and projects rather than in a one-shot chat. The relevant difference for our purposes is that you can attach real artifacts (journey maps, transcripts, analytics exports), keep context across a working session, and have Claude build interactive outputs you can click around in, not just text replies.

If you’ve only used Claude.ai in the chat window, the best mental shift is that chat is for conversations while Cowork is for building things.

The promise of this guide

What I’m about to walk you through works for journey maps, personas, service blueprints, stakeholder maps, research repositories, opportunity solution trees, and most other research artifacts that have historically been static, image-based, and lightly engaged with by stakeholders.

The system has five phases. None of them are skippable. Phase 1 is the one most researchers want to skip and the one that decides whether the output is honest or hallucinated.

If you’ve ever spent three weeks on a journey map only to watch a stakeholder open the PDF, scroll once, and close it, you already know exactly the gap I’m trying to close here. Static deliverables are the format we inherited. Dynamic ones are the format we can now actually build, on our own, without begging a designer.

Below, paid subscribers get the full operating manual I now use for every dynamic deliverable I make:

• The pre-work checklist (the five questions to answer before you ever open Cowork because most failed deliverables fail here, not at the prompting stage)

• The reusable prompt template, with variable slots for journey maps, personas, blueprints, stakeholder maps, and research repositories (copy this and you have your first prompt for the next twelve months of work)

• The four-move iteration loop (Load → Sprawl → Realism → Connect, what each move does, the prompts that trigger it, and the sequence that actually compounds)

• The competitive intelligence layer (how to pull verified-source comparison data from places like Baymard, Nielsen Norman, and aggregated public reviews using Perplexity or Claude web search, the three-tier source model that keeps your deliverable defensible, and the integration prompt that overlays competitor context without hallucinating)

• Four full worked examples, end-to-end (a behaviourally-segmented persona, a service blueprint with department ownership, a searchable research repository, and a journey map with a competitive intelligence overlay, each with the data you bring, the prompts you use, what Cowork builds, and the iterations you’ll want to run)

• The polish-and-rollout playbook (when to stop iterating, how to handle off-brand output, how to demo dynamic deliverables to stakeholders without overwhelming them, and the 30/60/90 rollout that gets a team from “what is this” to “we can’t go back”)

• The six failure modes I hit and exactly how to fix each one (hallucinated data, sprawl, broken filters, off-brand visuals, stakeholders who don’t know what to click, and hallucinated competitive context)

• A short note on pricing this work for clients without accidentally torching your day rate (if you’re a consultant

If “make this dynamic” has been the thing you nod along to in client calls and quietly panic about afterwards, this is the guide I wish I’d had three years ago.

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

A few months ago, I asked a room full of researchers a simple question:

“Who here is using AI in their research practice?”

Every single hand went up.

I wasn’t surprised. AI is everywhere right now, and researchers are nothing if not curious, so I followed up with, “What are you using it for?” and got the following:

• Cleaning up transcripts

• Writing first drafts of screeners

• Summarising my notes before synthesis

• Tidying up my reports

Useful stuff, genuinely, but also not what I’d call AI fluency.

Almost every researcher in that room thought they were using AI well. And in a surface-level sense, they were. But when I started asking follow-up questions—how do you verify the output? what’s your approach when it gets it wrong? what’s your policy on participant data? have you disclosed to stakeholders how AI was involved?—the answers got much quieter.

Nobody had a actual clear framework. But, hey, it’s not surprising. Nobody has ever actually defined what AI fluency looks like for us specifically.

This is now showing up in your job description

Let me tell you what prompted me to actually write this down.

Companies are creating frameworks for assessing AI fluency in every single hire, across every function. They’re not just asking “do you use AI?” They’re assessing mindset, strategy, building, and accountability. They’ve raising the minimum bar so that candidates who can’t demonstrate AI embedded in their core work don’t make it through.

PMs are being assessed on it. Engineers. Designers. Customer success. Marketing. Finance.

The frameworks they’re building for each of these roles are specific. The PM version talks about writing SQL, building dashboards, generating working prototypes. The engineering version talks about shipping AI-powered features. The marketing version talks about building automated content pipelines.

Nobody has built the researcher version. So researchers are either being assessed against generic criteria that doesn’t account for what our work actually involves, or worse, they’re walking into AI fluency conversations with nothing concrete to say.

If you’ve been in a job interview recently and someone has asked you “how do you use AI in your research practice?”, you’ve felt this. The question lands and you have a few seconds to figure out whether “I use it to clean up my transcripts” is going to cut it.

It isn’t. Not anymore.

AI fluency is no longer a nice-to-have that ambitious researchers can choose to develop. It’s becoming a baseline expectation and companies are increasingly building tests to measure it.

So let’s build the framework for what it actually looks like for us.

Why research is different (and why the stakes are higher)

Before I get into the levels, I want to make one argument clearly, because I think it’s the most important thing in this entire piece. AI fluency for researchers is not the same as AI fluency for any other role and the reason is accountability.

If a researcher uses AI badly, they risk presenting fabricated or distorted insights to a product team who will then use those insights to make real decisions. That’s a pretty big mistake and it can cascade in ways that are genuinely hard to trace back to the source.

I’ve seen it happen. A researcher uses AI to synthesise interview transcripts, takes the themes at face value, builds a report around them. The themes look right, they’re plausibly written, but they don’t fully reflect what participants actually said. They reflect what the AI predicted the themes would be, shaped by its training data, which is not the same as your eight participants and their specific context.

This is the GIGO principle playing out in research: garbage in, garbage out. The terrifying version for researchers isn’t that you feed garbage in. It’s that you feed good data in, and the process quietly introduces distortion you can’t see.

That’s why accountability has to be the centerpiece of any AI fluency framework for us. It’s not the most exciting component but it’s the one that separates researchers who are using AI well from researchers who are just using AI fast.

The four levels of UXR AI fluency

I’m going to describe each level in detail, across the full scope of research work. Read through all four before you try to self-assess, because it’s easy to over-identify with a higher level until you see the specifics written out.

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

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

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 hate making deliverables. So I made Claude do it and accidentally built something better than any journey map I’ve ever made.

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

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

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

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

**With the recent updates on Open AI privacy, I want to highlight that you do not have to use ChatGPT to achieve this. I have showcased ChatGPT because that’s where all my agents currently live, but I will be migrating them to other LLMs.

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.