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 a long time, I treated Claude like the world’s most expensive copy-paste machine.

Every research project started the same way. I’d open up a new chat, and then I’d start pasting things in: the PRD from Confluence, the Figma prototype URL (which Claude couldn’t actually open back then, but I tried anyway), three Slack threads from #product, the half-finished brief I’d cobbled together in Notion, last quarter’s research report, a handful of customer quotes I’d pulled out of past interview transcripts, the discussion guide template I always use, and a couple of stakeholder emails for context.

By the time Claude had enough background to be useful, I’d already done about forty minutes of work, most of which I’d have to repeat the next time I started a fresh chat.

I knew there had to be a better way, I just didn’t have the language for it yet.

Then I started learning about MCPs, and the way I work with Claude shifted completely.

If you’ve been using Claude for research work and you keep running into the same friction (the context-pasting, the “Claude can you find that thing I mentioned three chats ago”, the wishing your AI assistant could just see your Jira board), this article is for you. I’m going to walk you through the ten MCPs I think every user researcher should know about, with worked examples for each, and the order I’d install them if I were starting over today.

What an MCP is

MCP stands for Model Context Protocol. The simplest way I’ve found to describe it is that an MCP is a bridge that lets Claude reach into a tool you already use without you having to copy-paste anything in.

Before MCPs, if I wanted Claude to help me synthesise findings from a study, I had to manually export the transcripts from Zoom, paste them into the chat one by one, then ask my question. Now, I can connect Zoom once, and Claude can pull the transcripts directly. The first time it worked, I felt like I’d unlocked a cheat code.

Every MCP exposes a set of tools that Claude can use on your behalf. The Slack MCP exposes tools like “search messages” and “send a message”. The Google Drive MCP exposes tools like “search files” and “read document”. The Zoom MCP exposes tools like “search meetings” and “get transcript”. You don’t have to know exactly which tools are available, you just ask Claude in plain language what you want, and it figures out which tools to call.

The thing I want you to take away: MCPs turn Claude from a smart chat partner into something closer to a colleague who has access to your actual work. The shift is bigger than it sounds.

What this unlocks for user researchers in particular

I think MCPs are useful for almost any knowledge worker, but I’d argue they’re especially valuable for UXRs because of how our work is shaped.

We pull from a lot of disconnected places. The PRD lives in Confluence or Notion. The prototype lives in Figma. The customer quotes live in a Google Doc transcript, or a research repository, or a Zoom recording someone hasn’t watched yet. The stakeholder context lives in Slack. The participant pipeline lives in a recruitment tool or a spreadsheet. The product roadmap lives in Linear or Jira. The voice of the customer signal lives in Intercom or Zendesk. The deliverables live in Google Drive.

When I was the first and only UXR at a hospitality platform years ago, I used to keep what I called my “research brain trust” tab group, a row of about fifteen browser tabs I’d open at the start of every project just so I could ping-pong between them. I’d spend the first hour of every kickoff just refreshing my memory on what was already known. That’s research work I’d have loved to automate, and that’s exactly the kind of context-gathering MCPs make trivial.

I also think there’s a second reason MCPs matter for us. Research is one of the most context-dependent jobs in a product org. A finding from one study is only as useful as your ability to connect it to what’s being built, what was previously researched, what stakeholders are worried about, and what users are asking for. MCPs let Claude actually do that connection work, instead of you doing it manually every time.

Paid subscribers, this is where the deep walkthrough starts.

If you’ve felt the copy-paste fatigue, the “Claude doesn’t know my world” fatigue, the “I wish my AI could just look at my Jira tickets” fatigue, this is the part that’s going to save you hours every week.

Below, I walk you through the ten MCPs I’d install in the order I’d install them, with worked examples for each:

• Zoom (how to turn a folder of interview recordings into a pattern map in under an hour)

• Notion (how to query your team wiki and stop hunting for old PRDs)

• Google Drive (how to use transcripts and old reports as live context, not dead files)

• Atlassian, Jira and Confluence (how to prep for a kickoff in five minutes instead of an hour)

• Slack (how to mine stakeholder context without scrolling for two days)

• Gmail (how to handle participant outreach without sounding like a robot)

• Google Calendar (how to schedule a cohort of interviews without losing your mind)

• Linear (how to link research findings directly to the feature pipeline)

• Figma (how to use the prototype as live context for your discussion guide)

• Intercom (how to mine support data for research questions you didn’t know you should be asking)

Plus the mistakes I’ve made setting these up (so you don’t have to), and a three-step starter approach you can run this week.

If “I should set Claude up better but I never have time” has been the thing on your list for six months, this is the path I’d follow.

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

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

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

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

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

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

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

2. Getting an additional perspective on something

3. Training others with more guardrails

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

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

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

Happy researching!

Subscribe now

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

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

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

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

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

Most UXRs are stuck in this loop:

• You give AI a tiny prompt.

• It gives you a tiny answer.

• You rewrite everything yourself.

• You decide AI isn’t ready.

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

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

You’ve tried using AI to:

• Clean up messy notes

• Summarize a long research plan

• Rephrase an insight for an exec

• Draft a kickoff email

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

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

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

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

Not because AI is bad.

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

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

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

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

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

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

Why Pancake Prompts Fall Flat

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

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

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

1. The “do everything for me” prompt

Example: “Write a usability test.”

What the AI hears: “Guess wildly.”

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

Example: “Help me write a kickoff doc.”

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

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

Example: “Suggest tasks for a survey.”

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

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

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

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

• Why the team wants this research

• What decision sits behind the request

• Who’s pushing for speed

• What’s riding on the outcome

• What happened last time someone skipped research

• Who will use the insights

• What the constraints look like

• Which trade-offs matter

• What business metric is at stake

• How much is already known

• What’s being assumed without evidence

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

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

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

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

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

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

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

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

Exclusively for paid subscribers.

Read more

Subscribe now

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

You know the drill: you’re managing five research projects, you just got pinged to “take a quick look” at a half-baked survey, and you’ve got feedback from 3,000 beta users, most of it vague, repetitive, or weirdly contradictory.

And yet, you’re still expected to be strategic, decisive, and insightful.

This guide is not about AI replacing user researchers, but about how to build a custom GPT agent that acts like a sharp, humble, unflappable thought partner. One that:

• Helps you clarify your thinking when your brain is fried

• Challenges you with smart questions (not just passive answers)

• Gets you out of blank-page paralysis

• Spots potential blind spots or contradictions before a stakeholder does

• Drafts starting points for tedious but necessary docs

Think of it as building your own research copilot. Not to do the job for you but to help you do it with more clarity, speed, and sanity.

This article is focused on creating a GPT through ChatGPT, because that is what I am most familiar with, but can be used on other LLMs as well.

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

I built an AI Prompt Library for user researchers who are tired of wasting time on useless outputs. These are the exact prompts I use when I want to:

• Pressure test my research questions

• Catch blind spots before they derail a study

• Frame insights so they actually land with leadership

• Prep for tough stakeholder conversations

• Kickstart deeper thinking when I’m stuck

It’s a working toolkit I’ve refined in real research projects with teams under pressure to deliver fast, smart, credible work.

If you want to stop messing around with AI and actually use it to get better at research, you can purchase the library below (starting at £297 for over 60 detailed prompts):

Get the UXR AI Prompt Library

What you’re actually building

You’re creating a custom GPT that works like an intern. It helps you move faster without cutting corners. It doesn’t replace your judgment or intuition but it gives you a solid first draft, a second brain, a structured way to think through messy tasks, or an outside perspective you may have missed.

It’s not here to “do research.” It supports the parts of your job that slow you down, such as writing from scratch, cleaning up notes, explaining something for the third time, or organizing chaos into something usable.

Your GPT should:

• Understand how research fits into product work

• Ask thoughtful questions when it doesn’t have enough info

• Stick to your preferred format (Docs, Markdown, Notion, etc.)

• Stay grounded in evidence

Step 1: Get Clear on What Your GPT Is Actually For

Before you start building anything, pause.

Most people skip this step and jump straight to writing prompts. Then they get frustrated when their GPT gives weird, useless responses.

That’s like hiring a new team member and just telling them, “Help with research.” You’d never do that.

This step is where you define the job. If your GPT is going to help you, it needs clear direction, just like an intern would.

You’re designing a GPT-powered agent that works like a trusted assistant:

• Helps you organize your thinking

• Reflects things back when you’re stuck

• Drafts first versions of the stuff you’d otherwise procrastinate on

• Challenges you when your plan is too big, vague, or stakeholder-pleasing

Let’s walk through how to define its job.

1.1 Pick a Specific Role

Trying to build a GPT that “helps with research” is like hiring someone and saying “your job is everything.” It won’t work.

Instead, think about a recent project where you said, “I wish I didn’t have to figure this out alone.”

That’s your first role.

Here are 6 realistic, high-leverage roles to choose from. These are built for busy UXRs dealing with limited time, pushy teams, and messy briefs.

Role 1: Study Goals & Scope Coach

Job: Help turn a vague or bloated request into a tight, meaningful set of research goals and define what’s out of scope.

Use this when: A PM says “We just need to understand what people want,” and you need to create something feasible without turning it into a 3-month epic.

What it might help you with:

• Turning broad goals into sharp questions

• Spotting red flags in scope creep

• Suggesting ways to align goals with actual product decisions

• Asking you clarifying questions when you’re stuck

Role 2: Method Matchmaker

Job: Recommend a suitable method (or hybrid) based on your study goals, team constraints, and timeline. Includes both rigorous and lean options.

Use this when: You’re toggling between three options—card sort? 1x1 interviews? diary study?—and need a sounding board to land on something defensible.

What it might help you with:

• Suggesting methods based on your real constraints

• Highlighting trade-offs you’re not considering

• Providing backup reasoning for your method when stakeholders push back

• Recommending ways to combine methods into a phased or scrappy approach

Role 3: Success Metrics Assistant

Job: Translate vague product or business goals into measurable indicators of research impact (or success). Not just “insightful findings” but change that matters.

Use this when: Your team says “We’ll know the research worked if people get it,” and you’re left guessing what “get it” means.

What it might help you with:

• Linking research goals to team or company metrics

• Coming up with proxy indicators (when hard metrics aren’t possible)

• Helping define what a “useful” outcome looks like ahead of the study

• Stress-testing your impact assumptions

Role 4: Stakeholder Pushback Coach

Job: Help you prepare responses to difficult stakeholder feedback: “Why are we doing this?”, “We already know this,” “Can we skip the research?”

Use this when: You’re emotionally exhausted from defending the value of your work and want help crafting a calm, credible, non-defensive reply.

What it might help you with:

• Drafting responses to common objections

• Helping you clarify the real resistance (budget? timing? ego?)

• Reframing research as a support tool, not a blocker

• Giving you talking points in plain language, not theory

Role 5: Communication Drafting Assistant

Job: Write first drafts of time-consuming or lower-stakes copy: intro emails to participants, internal study updates, screener survey logic, etc.

Use this when: You’ve got a dozen tabs open, a pile of notes, and zero time to sound polished.

What it might help you with:

• Writing readable stakeholder updates with different tones (PM, exec, designer)

• Turning bullet points into a screener survey

• Drafting opt-in emails or session invites

• Creating follow-up messages when sessions change or people ghost

Role 6: Business Alignment Sparring Partner

Job: Help you map research questions to business priorities, identify where the value is likely to show up, and anticipate what stakeholders care about.

Use this when: You’re asked to “just explore,” but you know the team will want something that ties back to growth, retention, or efficiency.

What it might help you with:

• Translating “user friction” into “potential revenue loss”

• Connecting product discovery to business OKRs

• Helping reframe user pain into decision-ready language

• Pressure-testing how your research supports real-world tradeoffs

Please don’t choose all of them. Start with one. Think about where you currently lose the most time or feel most unsure. That’s your GPT’s starting role.

1.2 Define Its Behavior: What This GPT Should Be Like

You’re now writing the personality and guardrails for your assistant. This is called the “system message.” It’s what runs under the hood, every time you use the GPT. This is where you train it to act like your ideal assistant.

Here’s a basic fill-in-the-blank version:

System Message Template

You are a [tone or seniority level] research thought partner who helps with [specific task].

You are [3 traits: sharp, structured, not too verbose].

You always:

• Ask clarifying questions before guessing

• Speak plainly and directly

• Offer options, not just single answers

• Reflect what I’ve said to check understanding

You never:

• Make assumptions without asking

• Speak like a marketer

• Try to sound clever

• Generalize without specific reasoning

Let’s look at a real example:

Example: Method Matchmaker System Message

You are a senior research advisor who helps select the right method for a study.

You are practical, thoughtful, and straight-talking.

You always:

• Ask about the project goals, timeline, and constraints

• Offer 2-3 possible methods with pros/cons

• Include a scrappy version and a gold-standard version

You never:

• Default to user interviews without justification

• Suggest things we can’t realistically run

• Use phrases like “delight” or “unlock”

You’ll paste this into the GPT builder when we get to Step 2. This is the blueprint for how your agent behaves.

1.3 Provide Context Every Time You Use It

This is the biggest mistake most people make. They drop in a vague prompt like, “What’s the best method for this?”

…and then wonder why the answer is useless.

GPTs aren’t mind readers. They need context to act like a partner. Here’s what good context includes:

• What the project is about (1-2 sentences)

• Who the team is

• What constraints you’re facing (time, people, budget)

• What stage you’re in (planning, revising, defending)

• What you want from the assistant (options? feedback? draft?)

Example: Good Setup Prompt

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