The User Research Strategist: AI 101

10 ways to make Claude think like a research partner

Nikki Anderson — Thu, 25 Jun 2026 08:01:04 GMT

👋 Hey, I’m Nikki. Each week I write about UX research strategy, communicating impact, and using AI to do your best work. For more: Claude Skills Bundle | Claude Agents | AI Prompt Library | Team Training | AI Courses for UXRs

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!

Stop re-explaining your frameworks to Claude every morning

Nikki Anderson — Thu, 04 Jun 2026 08:01:21 GMT

Subscribe now

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

Static user research deliverables are done

Nikki Anderson — Thu, 07 May 2026 08:01:41 GMT

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

Bonus video: Behind-the-scenes of using AI agents

Nikki Anderson — Tue, 03 Mar 2026 12:46:30 GMT

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:

Offloading tedious/mundane tasks or starting with a draft versus a blank
Getting an additional perspective on something
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!

Use AI Across Your User Research Process

Nikki Anderson — Thu, 05 Feb 2026 09:01:00 GMT

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

Image from Unsplash

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.

A guide to AI agents for user researchers

Nikki Anderson — Tue, 23 Sep 2025 08:00:27 GMT

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.

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.