"Prompt engineering" sounds like it belongs to people who write code, and for the specific task of getting a general-purpose AI tool to help with qualitative research work - summarizing themes, drafting a codebook, checking whether a coding decision is consistent - it's really closer to a writing and thinking skill than a technical one. The instinct that makes someone good at writing a clear research brief for a colleague, or a clear set of instructions for a new research assistant, transfers almost directly into getting better results from an AI tool. This guide is that instinct, made explicit.
Table of Contents¶
- The Core Idea: Specificity Over Cleverness
- Give It the Context a New Team Member Would Need
- Show It an Example of What Good Looks Like
- Ask It to Show Its Reasoning
- Iterate Rather Than Expecting Perfection First Try
- A Worked Example
- FAQ
The Core Idea: Specificity Over Cleverness¶
The single biggest lever in prompt engineering, across essentially every use case, isn't a clever trick or a magic phrase - it's specificity. A vague request produces a plausible, generic response; a specific request, with a clear description of what's actually wanted, produces something meaningfully more useful on the first attempt. Asking an AI tool to "summarize these interview notes" will get you a summary; asking it to "summarize these interview notes, focusing specifically on what participants said about barriers to adoption, organized by which barrier came up most often" will get you something much closer to what a research brief actually needs. This isn't a special qualitative-research trick - it's the same principle behind writing a good classification goal for automated categorization, applied more broadly to any AI-assisted research task, not just sorting responses into categories.
Give It the Context a New Team Member Would Need¶
A useful mental model for writing a good prompt is imagining you're briefing a genuinely capable but completely new research assistant who's never seen your project before - what would they need to know to do the task well? They'd need to know what the research is actually about, who the respondents are, what decision the findings are meant to inform, and any background assumptions that would otherwise be invisible to someone coming in cold. A prompt that includes this kind of framing - "this is feedback from enterprise software customers about a recent pricing change, and I'm trying to understand whether the concern is about the price itself or about how the change was communicated" - gives an AI tool the same grounding a new human team member would need, and produces noticeably more targeted, useful output than a prompt that jumps straight to the task with no surrounding context at all.
Show It an Example of What Good Looks Like¶
Describing what you want in the abstract is useful; showing a concrete example of the output format or quality you're looking for is often more useful still. If you want interview quotes pulled out and organized by theme in a specific format, showing one worked example - even a rough, hand-written one - of exactly how you want a single quote formatted and labeled communicates something that a paragraph of abstract instructions often can't capture as precisely. This mirrors a well-established finding in qualitative coding generally: a category definition with a concrete example attached produces far more consistent results than an abstract description alone, the same principle covered from a categorization-specific angle in our guide on common mistakes when defining categories.
Ask It to Show Its Reasoning¶
For research tasks where the "why" behind a judgment matters as much as the judgment itself - deciding whether a given comment fits a proposed theme, for instance - explicitly asking the tool to explain its reasoning alongside its answer, rather than just returning a bare conclusion, does two useful things. It gives you something to actually evaluate, rather than a conclusion you either have to trust blindly or independently re-derive from scratch to check. And it often surfaces a case where the stated reasoning reveals a misunderstanding of what you were actually asking, even when the bare answer looked plausible on its own - a mismatch between reasoning and answer is a strong, early signal that the prompt itself needs to be clearer about the actual criteria you had in mind.
Iterate Rather Than Expecting Perfection First Try¶
Treating the first response to a prompt as a draft to react to, rather than a final answer to accept or reject outright, is closer to how this actually works well in practice. If a first attempt at summarizing themes comes back too broad, saying so directly - "these are too general, I need them split more specifically by which part of the product each one refers to" - and letting the tool revise usually gets to a better result faster than starting over with an entirely rewritten prompt from scratch. This mirrors the same iterative discipline that makes AI-assisted categorization work well generally: the first pass is a strong starting point, not a finished product, and treating it that way produces better results than expecting a single perfect prompt to anticipate everything on the first try.
A Worked Example¶
A researcher wants help identifying recurring themes across forty pages of interview transcripts about why employees leave a mid-sized company. A first attempt - "find the themes in these transcripts" - returns six broad, generic categories that could describe almost any exit-interview dataset: compensation, management, growth, culture, workload, and other. Recognizing the output as too generic, the researcher revises with more context and specificity: "these are exit interviews from a software company specifically; I'm trying to distinguish reasons the company could realistically have prevented from reasons it couldn't have, since that split will shape which findings go into the retention proposal versus which get noted but not acted on." The revised output splits the same underlying data into preventable causes (management quality, workload, lack of growth path) and non-preventable causes (relocation, career pivot, return to school) - a structure directly usable in the retention proposal the first, generic pass never could have supported, achieved by adding context and a clear purpose rather than by finding a cleverer way to phrase the request.
FAQ¶
Do I need to learn any technical syntax or special commands to do this well?
No - everything in this guide is plain written English, the same skill as writing a clear brief or a clear email. "Prompt engineering" for this kind of task is a writing and thinking discipline, not a technical or coding skill.
How long should a good prompt be?
Long enough to include the context, specificity, and (where relevant) an example that a new team member would need - often a few sentences to a short paragraph. Longer isn't automatically better if it's still vague about the actual question; a shorter, more specific prompt usually outperforms a longer, vaguer one.
Should I write one long prompt or break the task into smaller steps?
For complex tasks, breaking the work into smaller steps - context and framing first, then a specific request, then a follow-up refinement - tends to produce more controllable, checkable results than trying to specify an entire complex analysis in a single dense instruction.
Is this different from how you'd prompt AI for classifying survey categories specifically?
The underlying principles are the same specificity-and-context discipline covered in our guide on writing a good classification goal, which is really this same skill applied to one particular, structured task. This guide covers the broader skill as it applies to qualitative research more generally - drafting codebooks, summarizing transcripts, checking coding consistency, and other tasks beyond just category sorting.
For a structured application of these ideas to survey classification specifically, see Writing a Good Classification Goal and How AI Actually Reads Open-Ended Text.