Subscribe now

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

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

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

Most researchers I talk to land in one of three camps:

1. You’ve never touched AI and you’re a little suspicious of the whole thing, which is fair

2. You use ChatGPT for the occasional email and you assume Claude is the same product with a different coat of paint

3. You’ve watched another researcher rave about Claude in a Slack channel and you’ve been meaning to try it for about four months.

This guide is for all three of you (and anyone else!), and I wrote it because most “intro to AI” pieces are useless for our work. They teach you to write a haiku or plan a trip to Lisbon, and then leave you to figure out the part that actually matters, which is how a tool that makes things up fits into a discipline built on evidence.

I’m going to teach you how Claude works, in a way that lets you predict when it will help you and when it will quietly hand you a fabricated quote with a straight face. I’ll show you how it compares to the other tools so you know what to use it for. I’ll walk you through getting set up safely, with the privacy settings that actually matter when you’re handling participant data. Then I’ll take you stage by stage through the whole research process, with copy-paste prompts and the exact spots where your judgment is the thing that can’t be skipped.

One thing before anything else, please be deliberate with participant data. Before you paste a transcript with someone’s name, employer, diagnosis, or salary into any AI tool, check your organization’s policy, strip the identifying details, and treat consent the way you already do everywhere else in your practice.

Part 1. What Claude is and how it works

You can’t use this tool well until you understand one strange fact about it. Claude doesn’t know things the way a database knows things. It predicts text.

When you type a question, Claude generates an answer one piece at a time, each time predicting the most likely next word based on patterns it learned from an enormous amount of writing. It’s doing this at a scale and speed that genuinely feels like thinking, and a lot of the time the output is excellent. but the underlying mechanism is always the same. It is producing the most plausible-sounding continuation of your text.

Pause for a second, because this explains every wonderful and dangerous thing AI will ever do for you. When you ask it to rewrite a clunky insight, “plausible continuation” gives you a sharp, well-structured insight, which is great. When you ask it to pull a quote from a transcript and the transcript doesn’t contain a clean one, “plausible continuation” gives you a quote that sounds exactly like something your participant would say, except they never said it.

Treat Claude like a brilliant, fast, eager junior researcher who has read almost everything, has no memory of your specific study, and has no personal stake in being right. Brilliant and fast means it can save you hours. No memory of your study means it only knows what you put in front of it. No stake in being right means it will hand you something confident and wrong as cheerfully as something confident and correct, and it’s your job to tell the difference. You would never let a junior put unverified quotes in a stakeholder deck. Same standard here.

A few behaviors follow from how the machine works, and understanding them is most of the battle.

It is confident whether or not it is correct

Claude produces fluent, well-organized text by default, so it sounds authoritative all the time. The tone is identical whether it’s quoting a fact it has seen a thousand times or inventing a statistic on the spot. There is no tell. It will not hedge unless you ask it to, and even then it hedges in the same smooth voice. For us, this means the fluency of an answer tells you nothing about its truth. A beautifully written synthesis can be built on a miscount and a perfectly phrased quote can be fictional. Your verification habits are the core of using this tool responsibly.

It wants to agree with you

Claude is trained to be helpful, and “helpful” gets nudged, over millions of training examples, toward “agreeable.” So if you walk in and say “I think the main problem is onboarding, what do you see in this data,” Claude has a pull toward finding evidence that you’re right. It’s simply predicting the response that best fits the framing you handed it, and you handed it a conclusion to support. No malice, no flattery, just the machine following your lead.

You already know why this is dangerous, because you spend your career fighting it in yourself and your stakeholders. It’s confirmation bias, and Claude can run it at high speed with total confidence. The fix is to never ask Claude to confirm, but to instead ask it to challenge.

It has a finite memory, and long chats go foggy

Claude reads and writes in chunks called tokens, where a token is roughly three quarters of a word. Every conversation has a fixed budget of tokens it can hold in mind at once, called the context window. Your prompt, every file you upload, and every reply all spend from that budget. A page of text is around 500 tokens, and a full study of transcripts can run to tens of thousands.

When a conversation gets very long, the window fills, and Claude starts losing track of things you told it earlier. The classic experience is a synthesis chat that was sharp an hour ago and is now contradicting itself and forgetting your research questions. That’s the context window overflowing. When a chat starts going AWOL, ask Claude to condense the important details into a handover document and start a new chat with the condensed context.

What it simply cannot do

Knowing the hard limits up front saves you a lot of frustration. Claude does not know what happened after its training cutoff unless you turn on web search, so it’s blind to last week’s news, your company’s internal updates, and anything proprietary it was never shown. It cannot do reliable arithmetic across a long document by eye, so any precise count needs it to run code. It cannot generate images, only read and analyze them. And it cannot watch a video or listen to an audio file directly, which matters for us, since a session recording has to be transcribed first by another tool before Claude can work with it. None of these are dealbreakers once you know them, they just tell you which jobs to hand it and which to prep first.

Part 2. Claude vs the other AI tools

You don’t have to pick one tool and marry it. Most researchers I know run two or three, each for what it’s best at.

ChatGPT is the one everyone’s heard of, and it’s the closest comparison. It’s strong, its voice mode is genuinely better than Claude’s, it generates images, and its quick web search feels snappy. Claude tends to write in a less robotic voice out of the box, holds very long documents together better, and works with your local files in a way ChatGPT doesn’t match yet. Claude for writing and heavy document work, ChatGPT for voice notes, images, and fast lookups.

Google Gemini is good, deeply tied into the Google ecosystem, strong on images, and handles long context well. If your whole world is Google Docs and Sheets, it’s worth a look.

Microsoft Copilot lives inside Office and is convenient if your org is all Word, Excel, and Teams, though for nuanced research writing I still reach for Claude.

NotebookLM deserves a specific mention for researchers, because it does one thing we care about really well. You give it a fixed set of sources, your transcripts, a report, a stack of papers, and it answers questions grounded only in those sources, with citations back to the exact passage. For desk research, literature reviews, or “what did participants say about X across these twelve files,” it’s excellent precisely because it stays inside your documents and shows citations.

Claude genuinely stands out at writing in your voice once you’ve shown it examples, reasoning over very long documents without losing the thread, working directly with the files on your computer, and running multi-step jobs through Cowork that other tools don’t really attempt. Use it for those, lean on the others for voice, images, grounded-citation Q&A, and in-repository tagging, and stop feeling like you have to be loyal to one logo.

Part 3. Getting set up the right way

Accounts, browser, and the desktop app

Go to claude.ai and sign up with your email. You can use Claude in your browser, which is fine for quick chatting, or as a desktop app you install on your Mac or Windows machine. For research work, install the desktop app, because it’s the only version that can see the files on your computer and the only place the more powerful modes live.

Plans, pricing, and managing usage

Free works in the browser with a limited number of messages a day and no Cowork, and it’s a fine way to test for a couple of weeks.

Pro, around 20 USD a month, gives you the smartest model, much higher limits, and the desktop features including Cowork. This is where most researchers land, and it’s the same price as ChatGPT Plus.

Max, at 100 to 200 USD a month, is for people running long, heavy jobs every day who keep hitting Pro’s ceiling. Team and Enterprise plans exist for organizations, and they matter for data handling, which I’ll come to in a moment.

Your usage is metered, and on the paid plans you get a generous but finite number of messages in a rolling window. If you hit the ceiling mid-task, you’ll be asked to wait a few hours or switch to a lighter model. The practical move is to save the most powerful model for the work that needs it and use a faster one for everyday drafting, which brings us to the models.

The models: Opus, Sonnet, Haiku

Claude comes in three sizes, and you pick from the selector in the composer.

1. Opus is the most capable, and it’s what you want for synthesis, nuanced insight writing, and anything where being right and subtle matters.

2. Sonnet is faster and lighter, a strong everyday workhorse for drafting, summarizing, and quick rewrites.

3. Haiku is the quickest and best for simple, high-volume tasks.

Reach for Opus when the thinking is hard or the stakes are high, drop to Sonnet when you want speed on routine work, and don’t overthink it beyond that.

Privacy and data settings, the part your legal team cares about

This is the section to read slowly, because it’s the one that determines whether you can responsibly put research data anywhere near this tool.

Two things to do:

1. First, in settings, find the controls for whether your conversations can be used to improve the models, and turn them off when you’re working with participant data.

2. Second, understand your plan. The consumer and Team and Enterprise plans handle data differently, with the business plans generally offering stronger guarantees, admin controls, and options some organizations require for sensitive data. I’m deliberately not quoting you exact policy language, because it changes and you should not run your ethics on my memory of a setting. Open your account’s privacy settings, read what they actually say today, and for anything regulated, get your organization’s answer in writing from whoever owns your data policy.

Turn training off for research data, prefer a business plan if your org handles sensitive participant information, and when in doubt, don’t put it in.

Teach it how you work, once

In settings there’s a space, often called “Instructions for Claude” where you describe yourself and how you want Claude to respond. Use it. Tell it you’re a UX researcher, that you write insights as key learning, why, and consequence, that you keep participant quotes verbatim, that you want it to flag anything unverified, and that you’d rather it challenged your assumptions than agreed with you. That short paragraph shapes every conversation from then on, so you stop repeating yourself.

If you want to go even deeper into this, you can create an about me markdown file which you give it access to in every project.

Part 4. The surfaces, modes, and building blocks

Claude is more than a chat bot, and the reason most people plateau is that the chat box is all they ever use. It’s really a set of pieces that fit together: modes, files, projects, artifacts, connectors, skills, and plugins. Here’s each one, what it actually is, why it matters for research, and how to use it. Learn these and you’ve learned most of what the so-called power users know.

Chat, Cowork, and Code

Chat is your fast thinking partner. You type, it answers, you go back and forth. Reach for Chat when the task is one contained piece of thinking that lives inside the conversation. Sharpening a single insight. Rewriting a finding three ways for three audiences. Drafting interview questions. Talking through whether your method fits your question. It’s quick, forgiving, works on free, and it’s where to spend your first week.

Cowork is your research assistant that does the work. You point it at a folder on your computer, describe a multi-step job in plain language, and it plans the steps, reads your files, writes new files, and checks in along the way. Reach for Cowork when the work spans several files, produces a real deliverable, and would normally cost you an afternoon. Tagging fourteen transcripts, building a synthesis matrix, cleaning a thousand survey open-ends, or drafting a readout from raw notes. This is the mode that gives researchers their time back, and the reason the desktop app is worth paying for.

Code is for engineers, with one rare exception for us. Claude Code runs in a developer’s terminal. If you don’t code, skip it. The only research case where it surfaces is genuinely heavy quantitative work, and even then you don’t open Code yourself, because Cowork can write and run the code behind the scenes and hand you the result. You can also use Claude Code to mock up visual representations of your findings like prototypes, but Cowork also has these capabilities. I recommend getting familiar with Cowork before moving to Code.

Uploading files, and what it can read

You can hand Claude files directly by dragging them in or clicking the attach button. It reads PDFs, Word documents, text files, CSVs and spreadsheets, slide decks, and images like charts, whiteboard photos, and screenshots. This is the everyday way you work with your own material: drop in a report and ask for a summary with page references, drop in a transcript and ask for themes, drop in a screenshot of a survey result and ask what stands out.

There’s a cap on how many files and how much total text you can attach to one chat, so for a big study you’ll want Projects or a Cowork folder rather than stuffing everything into a single message. And remember from Part 1 that it can’t process audio or video, so a recording has to be transcribed first by your notetaker or repository before Claude can touch it.

Projects: a saved workspace for a study

What it is. A Project is a saved workspace that bundles files, standing instructions, and a set of related chats in one place, so Claude carries the same context across every conversation inside it. Picture a room dedicated to one study, where everything you’ve pinned to the walls stays up between meetings.

Why it matters for you. A normal chat forgets everything the moment you close it, so you re-explain your study every time. A Project remembers, which means every chat inside it already knows your research questions, your transcripts, and how you like insights written.

What goes inside one. Two things. Project knowledge, the files every chat in the project can see, like your discussion guide, your anonymized transcripts, your screener, and your last report. And custom instructions, a standing brief for how Claude should behave in this project, like your insight format, your voice, and your guardrails.

How to set one up. Create a project, name it for the study, drag your files into project knowledge, write your insight format and guardrails into the instructions, then start your synthesis, insight, and readout chats inside it.

When to use which: a one-off question is a plain chat, a whole study you’ll return to over days is a Project, and a big multi-file job that produces deliverables is a Cowork folder. It’s one of the most useful features for researchers and one of the least used.

Artifacts: the panel where Claude builds things

What it is. When Claude makes something substantial, a document, a table, a chart, or a small interactive page, it opens that thing in a panel beside the chat called an Artifact, so what you’re building has its own space separate from the back-and-forth conversation.

Why it matters and how to use it. You can edit an artifact, ask for revisions in plain language (”make the recommendation sharper,” “turn this list into a table,” “add a column for the so-what”), and copy or export it when it’s ready. For us it’s where a readout draft lives while you refine it over several turns, or where an interactive, clickable view of your themes opens for a share-out instead of a flat slide.

Connectors: plug in the tools your research lives in

What it is. A Connector is a secure link between Claude and another app, like Granola, Google Drive, Notion, Slack, Gmail, or Zoom, that lets Claude read information straight from that tool so you don’t have to export and paste. You grant permission once, the same way you’d let one app connect to another.

Why it matters for you. Your research already lives in these tools, so a connector means Claude can pull a transcript from Drive or your notes from Granola without you copying anything across.

MCPs The open standard that makes connectors possible is called MCP. You’ll see the acronym thrown around, and you never have to touch it. A connector is just an MCP working quietly under the hood. Connecting a tool gives Claude permission to read from it, so think about what’s in there first, especially anything with participant data or confidential stakeholder threads, and follow the same data rules from Part 3.

Skills: your saved workflows

What it is. A Skill is a saved, named instruction set, a workflow you trigger by typing a slash and its name. Inside a skill is the same kind of thing you’d put in a really good prompt, your method spelled out, your format, your examples, sometimes a sequence of steps, packaged so you never have to retype it.

Why it matters for you. Most of us run the same handful of processes over and over: writing insights a certain way, pressure-testing a report, structuring a readout, building a screener. A skill captures one of those processes once and runs it on command, in your voice, the same way every time.

A research example. A /insight-writer skill might take raw findings and return them as key learning, why, and consequence, with a so-what check built in. A /screener-builder skill might turn a study brief into a recruitment screener with the disqualifying logic already worked out. Part 10 shows how to build your own library from the prompts that work for you.

If you’re looking for Claude Skills for user researchers, I highly recommend my 53-skill bundle based on 12 years of user research work.

Plugins: bundles you install

What it is. A Plugin is a bundle of skills and connectors packaged together, like a small app you install in one click, so you get a whole set of related workflows at once instead of assembling each by hand. You will also hear Plugins called Agents, which is an AI that plans and carries out multi-step work on its own, rather than answering one question at a time.

If you’re looking to install some UXR agents, check out my 7 highly trained user research agents.

Other surfaces

There’s a mobile app, good for capturing a thought or a quick ask on the go. There’s Claude in Chrome, a browsing agent that can move around websites and pull things up for you when there is no tool connection available (ex: Dropbox). And there’s Claude in Excel, for spreadsheet-heavy work. They’re all useful once you’ve got the fundamentals, and none of them is where you start.

The context folder that makes Cowork smart

One setup move pays off more than any other. Cowork gets dramatically sharper when the folder you point it at also holds context about how you work. Make a folder with three subfolders: an “about-me” folder with how you write, what a strong insight looks like to you, and the words you never want in a report; an “outputs” folder so Claude has a consistent place to save its work; and a “templates” folder with your best guide, readout, and insight format. Once that exists, your prompts get short and your outputs get sharp, because you’re not re-explaining yourself every time.

Part 5. How to talk to Claude

Most disappointing Claude sessions come down to a vague prompt. The instinct you already have, that a sloppy research question produces sloppy findings, is exactly right here. A prompt is a brief so you have to write it like one.

Here’s a skeleton I use for almost everything. You won’t need all of it every time, but when an output disappoints you, the fix is usually a missing piece.

Context:    who I am, what study this is, what decision it feeds
Task:       exactly what I want, as specific verbs
Source:     the data, file, or example to work from
Format:     how I want the answer structured
Guardrails: what to avoid, and what to do when unsure

That last line is the one researchers forget and need most. “If a verbatim quote isn’t an exact match, leave it out” and “if the reason isn’t in the data, tell me it’s a hypothesis” are the sentences that keep Claude honest.

Five habits that make every prompt better

1. Be specific, because “help me with my guide” gets you generic and “flag every leading question in this guide and rewrite it neutral” gets you usable.

2. Give it an example of your voice, because it learns faster from one good sample than from paragraphs of description, so paste a report you’re proud of and say “write like this.”

3. Say what you want rather than what you don’t, because “write it the way I’d explain it to a designer I like” beats “don’t be so formal.”

4. Build up rather than front-loading, since two sentences and then steering (”keep the exact words,” “cut it in half,” “add the workaround three people mentioned”) beats trying to write the perfect prompt in one go.

5. Start a fresh chat when one goes foggy, because a clean window thinks more clearly than a cluttered one.

A few advanced moves worth knowing

• Give Claude a role, since “act as a skeptical research lead” or “act as a participant who’s skeptical of new tools” changes the whole frame of the answer.

• Give it a rubric, since “score this guide against these five criteria” gets you something more rigorous than “is this good.”

• Ask it to think step by step for hard analysis, which genuinely improves its reasoning on tangled problems.

• Ask it to ask you questions first, with “before you answer, ask me anything you need,” which surfaces the gaps in your own brief.

• And ask it to calibrate, with “how confident are you in that, and what would change your mind,” which is a fast way to find the soft spots in its reasoning.

Real prompts for real research tasks

Steal these, adapt the specifics, and notice the pattern so you can write your own.

Reviewing a discussion guide for leading questions, one of the safest high-value uses because there’s no participant data in it:

I'm attaching my discussion guide for a study on why mid-market
customers churn in their second month.

Do three things:
1. Flag every leading or double-barreled question and rewrite each
   one to be neutral and open.
2. Point out where I'm asking people to predict the future or
   explain someone else's behaviour, since they're unreliable at both.
3. Suggest three follow-up probes I'm missing in the moments where
   the real story usually hides.

Leave my warm-up and closing as they are. No jargon.

Coding open-ended survey responses, where the discipline matters as much as the speed:

Attached is a CSV of 480 responses to the open-ended question
"What almost stopped you from signing up?"

Group them into themes. For each theme give me:
- a short label
- the count and rough percentage
- two responses copied word for word, not paraphrased
- a one-line so-what

Then list anything that didn't fit a theme. Do not invent or tidy
quotes. If a verbatim isn't an exact match, leave it out. If you're
unsure of a count, say so rather than guessing.

Spot-check a few verbatims against the CSV, and if exact numbers matter, ask Claude to count by running code rather than by eye.

Turning a flat finding into a real insight, the step where stakeholders are won or lost:

Here's a flat finding from my onboarding study:
"Users don't read the tooltips."

Rewrite it as a proper insight with three parts:
- the key learning: what we now understand about the behaviour
- the why: what's driving it, grounded in the evidence below
- the consequence: what it costs us if we ignore it

Use only what's supported by the quotes I'm pasting below. If the
"why" isn't in the data, label it a hypothesis instead of asserting
it as fact.

[paste 4 to 6 quotes]

Triaging a vague stakeholder request into the real question:

A PM just sent me this: "Can you run a quick survey to find out if
users want dark mode?"

Act as a skeptical research lead. Tell me:
- the real decision hiding behind this request
- the assumptions baked into it
- whether a survey is even the right method here
- two sharper questions actually worth answering

Be direct and disagree with me where it's warranted. Red-team this request.

Red-teaming your own interpretation, the antidote to the confirmation-bias problem and maybe the most valuable prompt here:

Here's my main insight and the three quotes I'm leaning on:
[paste]

Now argue the opposite. Using the transcripts I've attached, find the
disconfirming evidence, name the participants who don't fit the
pattern, and tell me honestly where I might be seeing this pattern
because I want to. Don't reassure me. Try to break it. 

Part 6. Where Claude fits across the research process

This is the part the generic guides skip, and it’s the part that matters. Claude threads through the whole research process, showing up at every stage with real help to offer and a checkpoint where your judgment stays non-negotiable. Here’s the honest map, stage by stage.

Intake and scoping

Claude is a sharp partner for turning a vague request into a real research question, surfacing the hidden assumptions, and naming the decision the research is meant to inform. Drop in the Slack message or the meeting notes and ask what decision this feeds and what’s being assumed. The stakeholder-triage prompt lives here.

You still have to decide whether the research is worth doing, and what’s really at stake politically, is yours. Claude can frame the question. It can’t read the room.

Study design

Claude can recommend methods, draft a discussion guide or screener, and pressure-test whether your method actually answers your question. The guide-review prompt is the workhorse. It’s good at catching the design mistakes we all make under time pressure, like asking people to predict their own future behavior.

The method choice is yours, because it depends on constraints, politics, and prior knowledge Claude doesn’t have. Use it to draft and stress-test, not to decide.

Recruitment and screening

Claude drafts screeners from a brief, writes recruitment and scheduling messages, and spots screener questions that telegraph the “right” answer to people angling to qualify. Low risk, high time saved, since there’s no participant data in it yet.

The criteria, the quotas, and who counts as a real user versus a professional survey-taker is still your expertise.

Fieldwork

Right after a session, Claude is useful for a fast debrief. Paste your rough notes and ask for the three things that surprised you, the moments worth revisiting, and the questions to sharpen before the next session. It keeps you analytical across a long week instead of saving all the thinking for the end.

Synthesis

Point it at a folder of transcripts and it will tag against your research questions, cluster the tags into candidate themes, pull representative quotes with their source, and draft a first-pass insight list. What used to be a two-day wall of sticky notes becomes a first pass you can react to in an afternoon.

Your checkpoint of deciding what the data means is the irreducible core of our job, and it stays with you. Claude can surface a pattern. Whether that pattern is signal or noise, whether it matters, what it implies for the product, that is judgment built on having sat in the room, and it does not transfer to a machine. Verify every quote against the source. Recount anything stated as a number. Treat the first-pass themes as raw material, not conclusions.

Insight writing and reporting

Claude is a strong writing partner for turning findings into structured insights, drafting an answer-first readout, and rewriting the same insight for different audiences. The insight prompt belongs here, and so does asking it to run a so-what check on a draft the way a skeptical stakeholder would.

The recommendation is yours. Claude can structure the argument and sharpen the language, but standing behind “here’s what we should do,” with your name on it, is the researcher’s responsibility.

Activation and the repository

After the readout, Claude helps keep insights alive, drafting the research newsletter, the Slack update, the one-pager for a leader who won’t read the full deck. It’s also useful for repository work, suggesting a tagging taxonomy, writing consistent summaries so past studies are findable, and helping you spot when a new question has already been answered by old research.

The pattern across every stage is the same. Claude is fastest at the drafting, the structuring, the first pass, and the tedious middle. You stay in charge of the judgment, the meaning, and the decision. Used that way, it protects your craft by clearing the busywork, leaving you more room for the part that was always yours.

Part 7. The full menu of UXR use cases

To make the breadth concrete, here’s a scannable catalog of things researchers actually use Claude for, grouped by phase.

• Planning and design:

  • Turn a stakeholder request into a research question

  • Write a research brief

  • Choose a method, draft a discussion guide

  • Write a screener

  • Design survey questions

  • Draft a consent form starting point

  • Build a recruitment message and scheduling emails

  • Pressure-test a study plan

• Desk and secondary research:

  • Summarize a long report with page references

  • Compare several vendor or competitor studies

  • Pull the relevant findings out of a stack of papers

  • Synthesize your own past research on a topic before you run anything new

• Synthesis and analysis:

  • Tag transcripts against research questions

  • Cluster tags into themes

  • Build a synthesis matrix

  • Code open-ended survey responses

  • Draft an affinity structure

  • Surface patterns you might have skimmed past

  • Fnd the disconfirming evidence against your read

• Insight and reporting

  • Turn findings into structured insights

  • Run a so-what check

  • Draft an answer-first readout

  • Write an executive summary

  • Rewrite an insight for a PM, a designer, and an exec

  • Draft speaker notes for a share-out

• Modeling and artifacts:

  • Draft an evidence-based persona from your data

  • Sketch a dynamic journey map

  • Build an interactive chart or theme view for a readout

• Operations and activation:

  • Design a repository tagging taxonomy

  • Write consistent study summaries

  • Draft the research newsletter or Slack update

  • Prep a stakeholder Q&A before a readout.

Part 8. Verifying Claude’s work

Verification is the price of using this tool in a discipline built on evidence, and it belongs in your habits rather than bolted on at the end. The good news is you already do this for junior colleagues, so it’s a habit you have, just pointed at a new source. Here’s the checklist I run before anything Claude produced goes anywhere with my name on it.

Check every quote against the source, by searching the transcript for the exact words. If you can’t find it verbatim, it doesn’t go in. Recount every number, and for anything that matters, have Claude count by running code rather than trusting an eyeballed total. Watch the magnitude words, because “some,” “many,” and “most” can drift, and “a few participants” quietly becoming “participants” changes the strength of your claim. Trace every claim back to evidence, and if a “why” or a recommendation isn’t grounded in the data, mark it as your hypothesis, not a finding. Turn on web search and double-check any external fact, date, name, or statistic. And read the whole thing once as yourself, asking whether you’d stake your credibility on it, because in the readout, you are.

The more consequential the claim and the harder it is for a reader to check, the more you verify. A reframed sentence in a brainstorm needs a glance. A participant quote on a slide in front of leadership needs to be confirmed word for word.

Part 9. The risks and ethics you own as a researcher

Every tool has tradeoffs, and the responsible thing is to know exactly where this one can hurt you. These matter more for us than for almost any other profession, because we handle people’s private words and we put our names on claims about what those words mean. Read this section twice.

It fabricates quotes and patterns that sound completely real. This is the headline risk. When Claude can’t find a clean quote, it can generate one that reads exactly like your participant, and when a pattern is thin, it can present one participant as a theme. It’s doing the only thing it ever does, producing plausible text, and a plausible quote is exactly its specialty, so a thin spot in your data gets filled with something that merely sounds right. Verify every generated quote against the transcript, and recount every number, before any of it reaches a slide. A fabricated quote in a readout is the kind of mistake that costs you years of credibility in one meeting.

It miscounts, and “some” becomes “all.” Claude is unreliable at precise counting across long text, and the magnitude drift is subtle. For anything where the number carries weight, have it count by running code, and check the strength words yourself.

It agrees with you, which is confirmation bias with a turbocharger. Never ask it to confirm your read, ask it to break it. Use the red-team prompt. The moment you’re most confident is the moment to invite the disconfirming evidence.

Confidentiality and consent are on you, not the tool. Anonymize before anything goes in: strip names, employers, exact job titles, locations, and any rare attribute that could identify a person, and replace them with labels like P04. You can even ask Claude to help anonymize a transcript, but then verify it caught everything, because a missed surname is still a breach. Check that your participants consented to their data being processed this way, and if your consent form predates AI tools, it almost certainly needs updating to cover them. And remember some data simply shouldn’t go into an external tool at all, regardless of how careful you are.

Data residency, retention, and IP are real questions for your organization, not for you to guess. Where your data is processed, how long it’s kept, and whether it can be used to improve models depend on your plan and your settings, covered in Part 3. Get the answer from your data owner in writing for anything regulated, rather than assuming.

The model carries bias, like any system trained on human writing. It can flatten an unusual viewpoint toward the average, or describe a group in stereotyped terms. For us that means watching that it isn’t smoothing away the very outlier or edge-case voice that often holds the most important insight. You are the check on that.

The deskilling worry is legitimate, and worth naming. If you let Claude do your synthesis and never look closely at your data, your analytical muscle weakens, and you become unable to catch the tool when it’s wrong. The way through is to use it for the first pass and the busywork while keeping your hands on the judgment, the meaning, and the verification. It’s a power tool, and the craft is still yours to keep sharp.

None of this is a reason to avoid the tool. It’s the operating manual. Researchers who internalize these risks use Claude with confidence, because they know exactly which parts to trust and which to check. The ones who get burned treated a fluent answer as a true one.

Part 10. Building your Skills library

I defined Skills back in Part 4, which are saved, named workflows you trigger with a slash. This is where you build your own, because that’s the move that takes Claude from a handy chatbot to a tool that runs your actual process on command.

The method is simple and it compounds. Once you’ve written a good prompt twice, stop rewriting it and turn it into a Skill. Keep a running note called prompts-that-worked, and every time something lands, the guide review that nailed it, the insight format that finally sounded like you, the so-what check that caught the weak finding, paste it in. After a couple of weeks you’ll have a personal library of your own best thinking, and the strongest of those become Skills you call by name: /insight-writer for your insight format, /so-what-checker to pressure-test a draft, /screener-builder to turn a brief into a screener.

The difference between a casual user and someone who genuinely relies on Claude usually comes down to this. The casual user retypes a paragraph of instructions every time. The committed one types /insight-writer and gets their exact method, in their voice, every time. Every good prompt you save is a piece of your craft you never have to rebuild, and that library will be worth more to you than any prompt pack you could buy.

Part 11. The directory

Prompt. The text you send Claude. Write it like a research brief, specific in, specific out.

Model. The version of Claude doing the thinking. Opus is the smartest, with faster, lighter Sonnet and Haiku underneath. Opus for synthesis and insight work, Sonnet for everyday drafting.

Token. The chunk Claude reads and writes in, roughly three quarters of a word. A page is about 500 tokens, and your limits and memory are measured in them.

Context window. The total Claude can hold in mind at once, in tokens. It’s what lets you load a whole study, and when it fills, Claude gets forgetful, so start a fresh chat.

Knowledge cutoff. The date the model’s training stops. It doesn’t know anything after that, or anything internal to your company, unless you provide it or turn on search.

Hallucination. When Claude states something false with full confidence, including invented quotes and miscounts.

Sycophancy. Claude’s trained tendency to agree with you.

Chat. The conversational mode where you type and it answers, for fast thinking, drafting, rewriting.

Cowork. The mode where Claude works for minutes to hours on a multi-step task, reading your files and producing deliverables, for synthesis, readouts, screeners, the afternoon-eating jobs.

Claude Code. Claude in a developer’s terminal. Mostly skippable, and Cowork can run code for you when needed.

Desktop app. Claude installed on your computer that sees your local files and unlocks Cowork, so this is the one to install.

Artifact. The side panel where Claude opens a document, table, chart, or small interactive thing it built.

Project. A persistent space that remembers files and instructions across many chats, a per-study workspace that keeps your method and voice on hand.

Project knowledge. The files and instructions every chat in a project can see like your guide, transcripts, and insight format.

Skill. A reusable instruction set you trigger by name.

Connector. A link between Claude and another tool like Granola, Drive, Notion, Slack, or Zoom.

MCP. The technical plumbing behind connectors.

Plugin. A bundle of skills and connectors, like a small app store.

Agent. A general term for an AI that plans and carries out multi-step work on its own.

Extended thinking. A setting that lets Claude reason longer before answering, worth turning on for genuinely hard analysis or design problems.

Web search. A tool you switch on so Claude can read the live internet, on for current facts, off when working strictly inside your own data.

Vision. Claude’s ability to read and analyze images you upload.

Custom instructions. A saved description of you and how you want Claude to respond.

Hallucination guardrail. A line in your prompt telling Claude what to do when unsure, like “leave it out” or “label it a hypothesis.”

Part 12. FAQs

Will it train on my participant data? It depends on your plan and settings, which is why part three matters. Turn off training in settings when handling research data, prefer a business plan for sensitive work, and get your org’s policy in writing for anything regulated.

Can I trust the quotes and counts? Not without checking. Verify every quote against the transcript and recount anything that matters, ideally by having Claude run code. This is the single most important habit in this guide.

Can it join my Zoom call or transcribe my recording? Not directly. It can’t listen to audio or watch video. Transcribe with your notetaker or repository first, then bring Claude the transcript.

Is it ethical to use AI on research data? It can be, with anonymization, consent that covers AI processing, and a plan that protects your data. It stops being ethical the moment you skip those or stop verifying what it produces.

Will it replace user researchers? It replaces the tedious middle of the work, not the judgment. Deciding what data means, choosing what to study, reading a room, and standing behind a recommendation are the job, and none of that transfers to a tool. The researchers who thrive use it to do more of the thinking, not less.

How is it different from the AI in my repository tool? Your repository’s AI is great for transcription and tagging where your data already lives. Claude is stronger for writing in your voice, reasoning across long documents, and multi-step jobs. Many researchers use both.

What’s the one thing to get right first? Verification. Everything else is upside. That one habit is what separates using this tool well from getting embarrassed by it.

Part 13. Your first two weeks

Don’t try ten random things. Ramp deliberately, so each step builds real intuition. Keep your data hygiene on the whole way by anonymizing before you paste, checking your settings, and checking your org’s rules.

Week one, stay in Chat and learn how it thinks. Set up your personalization paragraph first. Then on day one, paste three insights you’ve written and loved and ask Claude to rewrite three weaker ones in that voice. Day two, upload a long report and ask for a one-page summary with page references, then check two of them. Day three, run the guide-review prompt on a real discussion guide. Day four, run the stakeholder-triage prompt on a real request in your inbox. Day five, take one finding and ask for the insight three ways, for a PM, a designer, and an exec.

Week two, move to Cowork and Projects and feel the time come back. Build your context folder, and set up a Project for a current study with its files and your insight format. Point Cowork at a folder of anonymized transcripts and ask it to tag against your research questions and propose themes, then spend your time checking its work. Run the red-team prompt on your main insight. Ask it to draft an answer-first readout from your verified insights. And save the two prompts that worked best as the start of your Skills library.

How the pros use Claude: one command, a full readout

For everyone still with me, here’s what this can look like, without writing a line of code. I’d just wrapped a discovery study which included twelve transcripts, a pile of Granola notes, and a research plan with research goals and outcomes.

I didn’t write a long prompt. I’d already built a Skill that holds my entire readout process, so I typed one command and a single line of context.

In the few minutes I was gone, Claude read all twelve transcripts and tagged them against the research goals. It clustered the tags into candidate themes and pulled supporting quotes for each, with the participant ID and the spot in the transcript so I could check every one.

It ran my insight process, turning the strongest themes into structured insights, each with the key learning, the why, and the consequence. I’d built a so-what check into the same skill, so it pressure-tested every insight and flagged the two too thin to survive a stakeholder. Then it asked me the framing questions I should have been asking myself like which decision does this feed, who’s in the room, lead with the answer or build to it.

With my answers, it assembled an answer-first readout with the headline recommendation up top, the insights beneath it, the evidence underneath each one, every finding traceable to a quote, a recommended next step attached to each.

It didn’t decide what the findings meant, talk to the participants, or replace my read of which patterns were signal and which were noise. I verified every quote and every count, rewrote the insights in my own voice, and cut the threads that didn’t hold. What it gave me back was time to think, frame, and make important judgement calls.

Where to start

You can’t master this in a day, so don’t try.

Block 30 minutes this week.

Install the desktop app, set your personalization paragraph, and spend your first sessions in Chat teaching it your voice with examples of your own work. Run one of the prompts from part five on something real and sitting on your plate. When you’re ready for Cowork, build your context folder, set up a Project for a live study, and hand it one genuinely tedious job, a synthesis, a screener, a readout draft, and watch what comes back.

Verify everything, anonymize your data, mind your settings, and keep your judgment in the driver’s seat. Do that, and Claude stops being one more tool you feel vaguely guilty about ignoring, and becomes the research assistant you didn’t know you were allowed to have.

Open it tonight. I’ll be glad I talked you into it.

Stay curious,

Nikki

I’m so excited to be hosting a live Introduction to Claude Skills for User Research on July 8th from 3:00pm - 5:30pm BST (UK time)! This is a beginner level session where I will break down exactly what a skill is, when you need one, and how to build one with real examples I use in my work every single week. You will get all the materials from the sessio…

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 weeks ago, about thirty seconds before a discussion guide left my hands for a client, I typed three words into Claude, “red team this,” and it handed me back three leading questions I’d read straight past a dozen times without noticing. I fixed them on the spot, sent the guide, and ran those sessions without the usual little voice in the back of my head asking what I’d missed.

That tiny moment is the whole reason I’m writing this, and what I’ve come to value most about Claude is having a second set of eyes sharp enough to catch the things I’ve gone blind to in my own work, the leading question I can’t see anymore, the survey set up to hand me bad data, the number in my readout I can’t quite explain. I have a folder on my phone called “AI stuff” that is a graveyard of saved prompt lists I never once opened, and not a single one of them ever did for me what two words typed into Claude did that afternoon.

What actually changed how I work with Claude was a small handful of frameworks I could point at anything, a discussion guide, a slippery stakeholder request, a repository nobody’s opening, a readout I’m half-convinced will get skimmed and forgotten. Once I had the framework, I stopped reaching for the prompt lists entirely.

So these are the ten I keep coming back to, written for the work we actually do all day. The first five turn Claude into a sharper thinking partner. The last five help you find the holes in your work before a stakeholder finds them for you, and if you’ve ever sat through a readout where someone poked the one weakness you didn’t see coming, you already know in your body why I care about it this much.

None of them need a perfect prompt, which is sort of the whole point, since you type a couple of words and the thing on the other side shows up completely differently.

01. Interview Me

Type “interview me” before any big task and Claude asks you questions before it starts, instead of charging ahead and guessing like an over-eager intern who didn’t want to seem unsure. The questions it fires back at you are the brief you never wrote down, the scope you hadn’t pinned, the audience you waved your hand at and hoped for the best on.

I use this before almost every discussion guide I build now. The version of Claude that asks me six sharp questions first, who’s the participant, what decision is riding on this, what have you already tried, hands me a draft that’s ten times closer to usable than the version that fills in the blanks on its own with whatever it assumed I meant.

Interview me before you write anything. Ask me everything you need to know to build a discussion guide for a generative study on how freelancers manage irregular income, then write the guide once you have what you need.

It works on anything that starts from a blank page, a research plan you’ve been avoiding for a week, a screener you keep getting subtly wrong, or the vaguest gift of all, the stakeholder who drops “can we do some research on the new dashboard” into your Slack and then evaporates. I let Claude interview me to turn that one sad little sentence into a real scope before I write a single word back to them.

Interview me before we scope this. My PM asked for "some research on the new dashboard" and gave me nothing else. Ask me the questions that will turn that into a real research plan with a clear decision, a method, and a timeline.

We are researchers. Being interviewed before the work starts is the most natural thing in the world to us, so do yourself a favor and let Claude do to you what you do to your participants every week.

02. Socratic

Type “teach me this using the Socratic method” and instead of dumping the answer in your lap, Claude teaches by asking you questions until you walk yourself to it. Anthropic built a whole Learning mode around this, because it’s how the thing actually stays in your head past Tuesday.

I reach for this with the corners of research I never formally trained in, the stats most of all. When Claude just hands me a sample-size formula, I forget it by the next study and have to go looking for it again like keys I swear I left on the counter. When it walks me there through questions, I remember it well enough to defend it when a data scientist raises an eyebrow at me across the table.

Teach me how to calculate the sample size for a benchmarking usability test using the Socratic method. Ask me questions instead of handing me the formula.

I use it before I run a method for the first time too, when I’d rather understand the analysis than fake my way through and pray nobody asks a follow-up. You can tell Claude to pause and check your understanding as it goes, which keeps you honest about whether you genuinely followed or just nodded along the way we all do in meetings we’ve mentally left.

I'm setting up my first card sort and I'm shaky on how to analyze the results. Teach me how to read the output using the Socratic method, and pause to check I'm following before each new concept.

The real gift here is retention. A formula Claude hands me lives in a Slack message I will never find again, and an idea it walked me to lives in my head, ready and waiting for the exact meeting where someone asks me to explain myself.

03. Ultrathink

This one only works in Claude Code, so tuck it in your back pocket for when you’re in there. Type the word ultrathink anywhere in your prompt and Claude’s thinking budget jumps to roughly eight times its normal amount before it answers, which buys you its deepest reasoning on the genuinely hard problems instead of the quick first thing that pops into its head.

I save it for the design decisions where I can feel three tradeoffs pulling against each other like dogs on three different leashes, and I want every one of them named before I commit to anything.

ultrathink, help me design the analysis approach for a mixed-methods study where I have 14 interviews and a 600-response survey, and flag every tradeoff in how I combine them.

The other place it earns its keep is when two data sources flatly disagree and I need to reason carefully about which one to trust and why, the kind of problem where a fast answer will march me somewhere confident and completely wrong.

ultrathink, my survey says users are satisfied with onboarding but my interviews say they're frustrated and confused. Help me work through every reason these two could disagree, and how I should weigh them in my readout.

I don’t reach for it on the small stuff, though. Asking Claude to ultrathink a simple screener is like booking a moving truck to carry one kitchen chair. On the messy structural problems, the extra wait pays for itself.

04. Second Order

Add “second order” before a decision and Claude tells you what happens next, and then what happens after that, the downstream stuff most of us sail right past when we’re staring at the immediate win.

This earns its keep around democratization, where I keep watching researchers make a call that looks fantastic on Monday and detonates a quarter later when nobody’s looking.

Second order, if I hand my PMs a self-serve usability testing tool so they can run their own sessions, what happens next, and then what happens after that?

What I’ve found is that the first-order answer is always “more research gets done, great,” and the second-order answer is where you meet the person who’s going to be cleaning up all the bad data, and that person, plot-wise, is you.

I run it on the quiet process decisions too, the ones that look harmless in the moment and grow teeth later. The faster method that saves you a week now and costs you a re-do in three. The incentive you trim to protect your budget that craters your show-rate. The report template you standardize until every readout looks identical and reads like wallpaper. Second order is how I catch those while they’re still hypothetical and cheap.

Second order, if I switch from moderated to unmoderated testing to save time this quarter, what happens next, and then what happens after that, to the depth of what we learn and how stakeholders treat our findings?

05. Inversion

Instead of asking Claude how to make something work, you flip the whole thing over and ask how it could fall apart. Claude maps out every way the thing fails, and you walk off with a checklist of exactly what to avoid, which is a much more useful object than a vague pep talk about doing your best.

I run this on readouts constantly, because the question I actually care about isn’t “how do I make a good presentation,” it’s “how does a perfectly good presentation still end up ignored by Thursday.”

Invert this. I want stakeholders to act on this readout. List every way this presentation could get nodded at in the room and then completely forgotten by Thursday.

It’s just as good on the work where the failure stays invisible until it’s far too late to fix. A survey can pull six hundred responses and still be worthless if the questions were leaking or the wrong people wandered in, so before I launch one I ask Claude to invert it and tell me every way it plans to betray me.

Invert this survey. I want clean, trustworthy data on why users churn. List every way this survey could hand me garbage, leading questions, the wrong respondents, scales people misread, and tell me what to fix before I send it.

The whole trick with inversion is treating the failure list as your to-do list. Every item Claude names is a thing you go fix, one by one, before the work ever leaves your hands.

06. ELI5

Short for “explain like I’m 5.” Add it to any prompt and Claude breaks the most intimidating thing into the smallest, plainest possible words. I use it on the things I’m a little embarrassed to admit I’ve been nodding along to for months, the p-value my data scientist drops in Slack like it’s obvious, the SQL my analyst keeps referencing, the clause in a research vendor contract I definitely signed a year ago and definitely did not fully read.

ELI5, what does a p-value of 0.03 actually mean for the A/B test my data scientist just shared, and what can I honestly say about it in my readout?

I recommend this one hard if you came into research from a non-quant background like I did. There is no shame in not knowing something, there’s only shame in standing up in a readout and presenting a number you couldn’t explain if someone gently asked.

The move I love even more is flipping it around and asking Claude to ELI5 my own finding for one specific stakeholder, because if I can’t get my insight down to something a busy exec grasps in a single read, I usually don’t understand it half as well as I’d been telling myself.

ELI5 this finding for a VP of Product who has 30 seconds and cares mostly about revenue: "Users abandon checkout because the trust signals are buried below the fold and they don't believe their card is safe."

The day I can’t ELI5 my own finding is the day I know in my gut it isn’t ready to leave my laptop.

07. Pre-Mortem

Drop this in front of any plan and Claude pretends the project already cratered six months from now, then works backward to tell you exactly why. It surfaces the blind spots while they’re still cheap, before you’ve poured a quarter of real, unrecoverable time into them.

I wish I’d had this before the first research repository I ever set up, the one I lovingly tagged and color-coded and organized into oblivion, and then watched nobody open for the better part of a year.

Pre-mortem this. I'm about to launch a research repository for a 50-person product org. Pretend it's six months from now and nobody is using it. Walk me through exactly why it failed.

The failures Claude names are the ones I’d have sworn on my life wouldn’t happen to me, which is precisely why I needed to hear them out loud before launch instead of after, when they’re just called regret.

Pre-mortem and inversion are close cousins, and I use them for different sizes of bet. Inversion gives me a cold list of ways an artifact could fail, perfect for a survey or a deck. Pre-mortem tells me a whole story about a future where my big commitment already collapsed, which is the version I want before I sink real time into a repository, a research roadmap, or a democratization program I’m about to sell to leadership with my name on it.

Pre-mortem this. I'm about to pitch leadership on a democratization program where trained PMs run their own usability tests. Pretend it's a year from now and it's blown up in our faces. Tell me the story of how.

08. Steelman

Tell Claude to “steelman the other side” and it builds the strongest, smartest version of the argument you disagree with, the one that’s actually hard to swat away. It’s uncomfortable in the useful way, the way a good editor is uncomfortable, because it shows you exactly where your own thinking has gone soft.

I use this to prep for the stakeholder who wants to skip research and ship yesterday. If I can only argue against a cartoon version of their position, I lose the room in about ninety seconds, and if I’ve already heard the best possible version of “we don’t have time for this,” I can walk in and meet it head on.

Steelman the case for skipping research on this feature and shipping now. Give me the strongest version of my PM's argument so I can actually respond to it in our planning meeting.

The braver use is turning it on myself. When I catch myself dismissing a method out of hand, I ask Claude to steelman it, and every so often it changes my mind, which is embarrassing and also the entire point of asking.

I've been dismissing surveys for this question because I think it needs depth. Steelman the case that a well-designed survey is actually the better method here, and be convincing.

I run it on my own conclusions before a big readout too, asking Claude for the strongest possible case that my data says the opposite of what I’ve decided it says. I would so much rather find the hole in my story at my own desk, in my pajamas, than have a VP find it for me in front of the room.

09. Red Team

Add “red team this” before any plan, guide, or deck and Claude attacks it from every angle a critic would, like handing your work to a panel of professional skeptics who give you their honest notes in thirty seconds flat. You find the holes before the room does, which is the only good time to find them.

This is my last pass on every discussion guide I write. Leading questions hide so well from the person who wrote them, smiling and looking reasonable, and Claude is very good at catching the ones I’ve gone completely blind to.

Red team this discussion guide. Show me where my questions are leading, where I'll get shallow socially-acceptable answers, and where I'm asking people to predict their own future behavior.

I’ve started running it on the readout deck itself before big presentations, asking Claude to sit in the chair of the most skeptical person in the room. The VP who’ll ask “you only talked to eight people?” before you’ve finished your second slide. The engineer who distrusts anything qualitative on principle. The PM hunting for a reason to do the thing they already wanted to do. Hearing all of their objections a day early means I walk in with answers instead of standing there blinking.

Red team this readout deck. Sit in the seat of a skeptical VP and a data scientist who distrusts qualitative work. Where will they poke holes, question my sample size, or wave off the findings, and how should I answer each one?

10. First Principles

Add “break this down from first principles” and Claude stops parroting the conventional wisdom back at you and rebuilds the answer from what’s actually true. This is the one Elon Musk won’t stop talking about at parties, and the reason I love it for research is that so much of what we do is inherited habit nobody has questioned since before we got here.

Break this down from first principles. Do I actually need to recruit 5 users for this usability test, or is that just a number we all repeat because we read it once and it sounded official?

Half the time the first-principles answer brings me right back to the convention, which is fine and good, because now I’m doing it on purpose with my eyes open instead of on autopilot. The other half, it frees me from a rule that never fit my situation in the first place and was just along for the ride.

I aim it at the rituals I’ve stopped even noticing, the ones surviving on pure momentum because the last researcher did them this way and the one before that. The 60-minute interview that could have been 35 and everyone’s relieved. The full slide deck nobody asked for when a one-page memo would have moved twice as fast. The quarterly cadence we follow without ever once choosing it on purpose.

Break this down from first principles. We run a 60-minute interview and a full slide deck for every study out of habit. What is each of those actually for, and what would I do if I designed our process from scratch today?

Asking “what is this for, from scratch” is how I find the work I’m allowed to stop doing, and for most of us drowning in requests, that’s the most valuable answer there is.

Stack them

These get properly dangerous when you combine them, and stacking is where the real thinking-partner magic shows up.

Pre-mortem this research repository rollout, then steelman the strongest reason a team would refuse to use it, then give me the 3 changes I should make before launch.

Mix and match based on whatever you’re trying to figure out. Inversion plus red team for a survey you’re nervous about. Second order plus steelman before you walk into a democratization conversation you suspect will get tense. Interview me, then first principles, when you genuinely have no idea what you’re even solving yet. Or red team your readout, then ELI5 the fix for every objection it surfaces, so you can say each one out loud in the meeting without fumbling for words.

The one thing I’d love for you to take from all this is exactly where I started, treating Claude less like a search bar you fire questions at and more like the sharp, slightly skeptical colleague who reads your work before anyone important does. I didn’t need a folder of 500 saved prompts to get that second set of eyes, I needed about ten small moves and the nerve to point them at the work that actually scares me.

So if you do one thing with this, make it small and make it this week. Open the messiest thing on your plate right now, the discussion guide you’ve been avoiding, the survey you’re unsure about, the readout you’re presenting on Thursday, and before it leaves your hands, run one of these on it. Red team the guide, invert the survey, pre-mortem the launch, whichever one matches the part you’re most afraid of getting wrong, and let Claude find the hole while it’s still cheap to fix.

Come tell me in the comments which one you reached for first, and what it caught.

Stay curious,

Nikki

Want to become a Claude master (think Pokemon master but for Claude), check out my resources:

• 53 Claude Skills built for user researchers

• 7 Claude Agents to scale your research workflows

• Join my live Claude workshops

• Bring me to your company!

Subscribe now

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

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

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

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

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

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

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

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

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