Turn customer interviews into an AI coding prompt

What to give a coding agent instead of transcripts

You have a folder of interview notes and a coding agent open in the next window. The tempting move is to paste everything in and type "build what these people want." Do not. Both a transcript and a wish list go wrong, for different reasons.

A transcript is long and full of asides. A wish list is short and full of guesses. Hand either one to an agent and you have asked it to decide what mattered, what was a passing comment, and what you meant. That decision belongs to you.

Here is the short answer to the question this guide is built around. Give the agent four things, in this order:

1. The evidence, cut down to the few excerpts that drive a decision.
2. The requirements those excerpts support, each written as behaviour someone can observe.
3. Acceptance examples the agent can test its work against.
4. Non-goals: things people asked for, or that look obvious, which you are deliberately not building.

Then tell it to stop and ask when the brief runs out, instead of filling the gap with a guess. The rest of this guide shows how to produce those four things from interview notes, with a complete prompt template you can copy.

This works for customers, users, your own team and partners. Anyone you interviewed about their work can feed it.

Separate what people did from what they asked for

Treat the people you interviewed as witnesses, not as designers. Ask them what happened; do not take their word on what to build. Research methods guidance distinguishes what people say from what they do, and notes that¹.

So split every interview note into two piles before you write a single requirement.

• What they did. A recent event, described concretely.
• What they asked for. A feature, a preference, a prediction.

Here are two lines from an invented example, a pottery-studio booking tool, which this guide develops in full below. Nothing in it is real. The first is something a member did: "I joined the waitlist, then came in on Thursday to ask if I was near the front." The second is something a member asked for: "It would be great if people could pay in the app."

Both are data. They are not the same kind of data. Use the first to find where the pain is. Treat the second as one person's guess at a fix, and test it against the first kind.

A rule that keeps you honest: a feature request earns a requirement only when you can point to a moment in someone's story where its absence caused trouble. No such moment means it goes in the parking lot, and later in this guide you will see it become a non-goal.

When you write each observation, follow GOV.UK's guidance on analysing research sessions and note². For the full method, see what makes an insight evidence-backed.

Build the evidence-to-requirement table

The central tool is a table with one row per decision. Each row walks from a piece of evidence to a requirement, and every step is a separate cell so you can see where your own thinking crept in.

Two habits make the table work.

Keep the interpretation column honest. Interpretation is where your assumptions sneak in. When the interpretation is the only thing connecting the excerpt to the requirement, say so in the cell. A reviewer, or you next week, can then challenge it.

Make it a team job. Ask anyone else who heard the interviews to read the table and challenge each interpretation. If you are a solo builder, you are the team, so read your interpretation column again a day later and ask what else could explain each row.

A worked example, with a non-goal and a disagreement

Here is the invented example in full, to show the method.

A community pottery studio runs evening classes with limited places. You are building a small booking tool for it. You spoke to five members and the studio owner, and you cut your notes down to four rows.

Look at what each row did.

R1 and R2 moved from an observed action to a requirement and an example. R3 did the opposite: two people asked for something, and the table recorded why it is not being built. R4 is the uncomfortable one. The owner and the members disagree, and counting heads (one owner, two members) does not settle it. The agent still needs something to build, so you choose waitlist order as a temporary default and say plainly that it is your choice. You keep it easy to reverse, you write down that the owner disagrees, you take the question back to the owner, who is the person you are building for, and you tell the agent not to add any regular-customer logic.

Write requirements, examples and non-goals the agent can check

Requirements as behaviour

A requirement that cannot be observed cannot be reviewed. "Waitlists should feel transparent" is a mood. "A member on a waitlist can see their position" is something you can look at on a screen.

Three rules for the requirement column:

• Start from the goal. GOV.UK's guidance on user stories says³, because it tells the team whether they are solving the right problem and when the need is met.
• Describe the outcome, not the build. Acceptance criteria for a mixed audience should⁴. Say what the member sees, not which table stores it. If you find yourself naming technical detail, ask whether the requirement is really a design choice you have not made yet.
• One requirement, one behaviour. If a row needs the word "and" twice, split it.

Then write an acceptance example for every requirement you are building. A familiar way to do it is the given, when, then pattern:⁵, when is the behaviour itself, and then is the change you expect. The examples in the table above follow it.

Examples do two jobs. They tell the agent exactly what "done" looks like, and they give you something to run yourself afterwards. For each requirement that has an awkward case, add an example for it, such as an empty waitlist or two people cancelling at once. Write those down yourself; do not leave them for the agent to guess.

Non-goals and open disagreements

Every brief has features that look like they belong. Say so out loud. One guide to software design documents recommends a non-goals section that⁶ and rules them out explicitly.

Do the same for an agent, and spell it out: do not leave an unstated feature to chance. Write non-goals as plain sentences:

• Payment is out of scope. Do not add checkout, card entry or price display.
• Do not add owner priority for regulars. Offers go in waitlist order.
• Do not add accounts, roles or settings beyond what the requirements name.

Keep disagreement visible in the same way. Dissent is not noise to be filtered out before the agent sees the brief. Do not discard the case that does not fit. Write one short line per open disagreement: who holds each view, what you decided for now, and what the agent must not decide for you.

The build prompt template

Here is the whole brief in one block. Copy it, replace everything in square brackets and curly braces, and delete the sections you do not need. The excerpts and rows come from your own table.

You are helping me change [product or project name]. Work
only from the evidence and requirements below. Do not invent
requirements.

CONTEXT
Who uses this: [type of user or customer]
What they are trying to get done: [the goal, in one sentence]
What I learned from [number] interviews: [two or three plain
sentences]

EVIDENCE
Each item is a short excerpt, what I observed, and my
interpretation. My interpretation is a reading, not a fact.
Challenge it if the code or the excerpt contradicts it.
- {id}: "[short verbatim excerpt]" ({interview ref})
  Observation: [what happened]
  Interpretation: [my reading of why]

REQUIREMENTS
Each requirement points back to its evidence id.
- {id}: [what the product must do, as behaviour someone
  can see]

ACCEPTANCE EXAMPLES
For each requirement, make these pass. Write them as
automated checks where the project has a way to run tests,
and tell me how you checked.
- {id}: Given [starting state], when [action], then
  [expected result].
- {id}: Edge case: given [awkward state], when [action],
  then [result].

NON-GOALS
Do not build any of the following, even if it looks like a
natural addition:
- [thing people asked for but I am excluding]: [one-line
  reason]
- [other obvious extension]: [one-line reason]

OPEN DISAGREEMENTS
These are unresolved. Build only the temporary default
stated here, keep it easy to change, and do not add logic
for either side.
- [Topic]: [who holds each view]. For now: [what to
  build]. Do not add: [what to leave out].

HOW TO WORK
1. Before writing code, list the requirements and non-goals
   back to me in your own words, and say which files you
   expect to change.
2. If anything is unclear, or a task needs a decision that
   the brief does not cover, stop and ask me. Do not fill
   gaps by guessing what users want.
3. Keep changes as small as the requirements allow. Do not
   add features, settings or screens that no requirement
   names.
4. When you finish, give me a table: each requirement id,
   what you changed, how you checked the acceptance
   example, and anything you could not check.
5. List every assumption you made and every place you
   departed from the brief, however small.

Notice step 2. Asking the agent to ask is cheap. Finding out later that it settled a question you did not know existed is expensive.

Review what it built against the evidence, then go back to people

When the agent reports back, do not review the diff first. Review the evidence trail.

1. Walk the table. For each requirement, run its acceptance example yourself. Do not accept "I checked" as the whole answer.
2. Hunt for additions. Look for any screen, setting or behaviour that no requirement names. Each one is a decision the agent made for you. Keep it, cut it, or add it to the table with evidence.
3. Check the non-goals. Search the result for payment fields, priority flags, extra accounts, whatever you excluded.
4. Read the assumptions list. Every assumption is either a missing requirement or a question for your next interview.

Then put the working build in front of the people you spoke to. GOV.UK's beta guidance describes the aim as⁷ to make sure it meets their needs. Watch them use it. Ask them to do the thing from their story, such as joining the waitlist, and see whether they find their place.

Add what you learn as new rows. If a member in the follow-up session pays at the door and shrugs, your payment non-goal just got stronger. If members start asking who gets first pick, your open disagreement just moved, and it is time to take it back to the owner.

What this will not tell you

This method turns interview evidence into a clear brief. It does not prove that the product will succeed, and it does not show how many people share a view. A handful of interviews gives you reasons and stories, not a measure of how common anything is.

The template is a working tool, not a tested standard. It has not been validated against any particular coding tool, and no brief guarantees what an agent builds. That is why the review step exists. Whatever the agent produces, you remain responsible for checking it against what people said and did.

The table also inherits every weakness of your interviews. If you spoke only to friendly or enthusiastic users, your requirements describe them. Follow your organisation's consent and privacy rules before pasting any interview material into any tool, and strip names and details you do not need.

Do this today

Take your three most important interview notes. For each, write one row: excerpt, observation, interpretation, requirement, acceptance example. Add one non-goal and one open disagreement if you have them. Paste that, inside the template, instead of the transcript.