Beyond the Template: How Understanding AI is Critical for Writing Good Prompts for UXR
I’ve been working through the Anthropic AI Fluency course. The Description module gave me a useful framework for writing good prompts. But it also showed me where good prompts are only half the battle.
Some prompt problems live beneath what any writing framework can catch. Writing prompts that actually work means knowing the AI as a system, with all its limitations: knowledge cutoffs, hallucinations, context window constraints. The properties that shape whether your prompt will land or fail silently.
For UX researchers working with AI, this matters. Prompt writing is a skill. So is the thinking around it. They aren’t the same thing, and getting good at one without the other will get you stuck.
The framework, briefly
I dive into the Description module in this post. It’s worth noting that this is one component of a larger framework Anthropic uses called the 4Ds: Delegation, Description, Discernment, Diligence. These dimensions tackle different parts of leveraging AI, including knowing what to delegate to AI in the first place and evaluating what comes back. For now, Description is the part about communicating with AI. This is where prompts live.
When it comes to writing good prompts, Anthropic says:
AI can't read your mind […] the quality of your results often comes down to how clearly you articulate your needs, preferred approach, and desired interaction style.
So, the Description module names three dimensions you should specify when prompting:
Product. What you want the AI to create or provide.
Process. How you want the AI to approach the work.
Performance. How you want the AI to behave during the collaboration.
This is useful. Most prompts I see only specify Product, and not even that clearly. Adding Process and Performance forces you to think about the work before you ask for it. The framework guides you in pressure-testing your draft before you send it.
What the framework doesn’t catch
The course exercise asks learners to work with Claude on improving poorly-written prompts. Claude generated three for me to fix. Here was one of them.
“Why is qualitative research better than quantitative for understanding user mental models?”
I took the prompts, left Claude behind, and got to thinking in my notebook. When using the framework, I caught real issues. For example, the prompt didn’t specify what kind of mental models. It didn’t say what application or context. It didn’t tell the AI what format the answer should take or whether to include citations.
My rewrite:
“Tell me more about the strengths and weaknesses of using only qualitative research or only quantitative research to explore users’ mental models in configuring web browser privacy settings.”
Cleaner. More specific. The framework worked.
When I was done assessing what made these prompts a flop and rewriting them to be more effective, I asked Claude to do the same so I could compare our notes.
Claude flagged something my structural analysis missed. The original prompt is a leading question. It presupposes qualitative is better and asks for justification. Looking back at my rewrite, I had stripped the leading framing without realizing it. Years of writing neutral research questions made that move automatic.
But Claude caught something else. My rewrite kept the binary intact. “Only qual or only quant” still forces a comparison between two approaches, when the better research question might invite hybrid methods or challenge the framing entirely.
Three layers in one short prompt. The framework caught the structural issues. My experience caught the leading framing. The binary slipped between the cracks. The point isn’t that experience saves you where the framework runs out. It’s that prompting is layered work, and it takes thinking on all the layers at once.
But the more I thought about the framework’s limits, the bigger the gaps became.
The bigger gap and what AI asks of us
The framework names Performance as a thing to specify. The intent is to define how you want AI to behave during your collaboration. Do you want it to give you a little or a lot of details? Do you want it to support you or challenge you?
What the module fails to articulate is that to specify it well, you have to know the AI you’re working with.
Performance was harder to get right because it goes beyond thinking about what to write. It involves a strong understanding of the implications of your performance instructions and how they lead to effective (and sustainable, token-friendly) outcomes.
For example, when writing Performance effectively, I had to consider:
What should and shouldn’t go in a context window?
What’s the best way to optimize the context window? When do I go to a new chat? When is it best to compress? What’s lost when I do either?
What settings (model, thinking mode, project vs. co-work) are best for this specific project?
These aren’t prompting questions. They’re system questions. They’re about how the AI is built and how it behaves under different conditions. If I don’t have answers, my Performance descriptions land in a vacuum.
There are specific limitations of generative AI that shape what a Performance instruction can and can’t accomplish. Knowledge cutoffs will make a prompt asking the model to cite recent research fail silently if it can’t access data past its training date. Hallucinations will happen even if you ask it to only state what it’s certain of because the model has no internal marker for certainty. The FIFO context window will make it forget critical foundations you set up (and implicitly rely on) early in a long conversation. Non-determinism means asking for consistency can’t fully control run-to-run variation. Reasoning gaps mean asking the model to think step by step lands differently depending on whether it has extended thinking built in.
None of these are edge cases. They’re properties of the system. Prompts (especially Performance parts) that don’t account for these characteristics may fail.
This is where prompting and AI literacy collapse into the same skill.
If we don’t know what’s possible to ask for, we won’t be able to write the right prompt. To understand what’s possible, we have to engage with AI deeply through documentation, experience, watching what breaks, paying attention. Only then can we make these connections.
What this means for research work
The framework facilitates thoughtfulness. It doesn’t generate it.
Good prompts come from someone who’s done the thinking outside of the prompt. They apply domain expertise. They engage with the AI as a system. They understand what good outputs look like in the field. They know when to stop and reconsider whether the AI should be involved at all. None of this lives inside the prompt. The prompt is where the thinking surfaces, not where it happens.
For researchers, this means something specific. Our skill is judgment. Knowing what question to ask. Knowing what context matters. Knowing when a method fits. The framework helps us communicate that judgment to AI. It doesn’t replace any part of it.
If our strength is our thinking (context, goals, nuances that AI cannot access), then we have to dedicate time to perfecting this part of the skill too.
The framework is real, useful, worth learning. But getting better at prompting means getting better at understanding the system itself, not just the surface where we type.
So what does this change?
For me, it shifts my attention. I’ll spend less time looking for the perfect prompt template, and more time understanding what the AI I’m using can actually do, what makes it break, and what I have to bring to it that it can’t bring to itself.
If you’re working with AI and feeling like your prompts almost work but not quite, the gap might not be in the prompt. Before you debug the prompt, treat the AI as your user: learn its constraints and underlying needs for success. Most of all, check your assumptions on what it can actually do.