The Brief Prompting Method: AI Needs a Brief, Not a Prompt

Why AI needs a brief, not a prompt

Most disappointing AI output has the same root cause: the model was handed a request, not a brief. "Write a LinkedIn post about our new feature" is a request. A creative director at an agency would never accept it, because it leaves out everything that makes the work good: who it is for, what it should achieve, what has already been tried, what the brand sounds like and what would get it rejected.

A language model is in the same position as that creative. It is capable, fast and eager, and it knows nothing about your situation unless you say so. When information is missing, the model fills the gap with the statistically average choice. That is why unbriefed output feels generic: it is the average of everything the model has seen.

Brief Prompting is the method PromptDeck originated to fix this. You brief the AI like a top agency briefs a creative, and you gather the brief by interview rather than writing it from scratch.

Key takeaways

• A prompt is an instruction; a brief is an instruction plus the context needed to do it well.
• The brief has nine elements: goal, audience, context, constraints, tone, format, examples, what to avoid and success criteria.
• Most people can answer questions about their idea much more easily than they can write a good prompt from a blank page.
• Interviewing the user, one question at a time, surfaces details people forget to include.
• The result should be one prompt, structured for the target model: markdown headings for ChatGPT, XML tags for Claude.
• Depth should match stakes: a quick brief for a caption, a deep one for a strategy document.

The problem with blank-page prompting

Prompt engineering as a discipline grew up around a real difficulty: the way you phrase a request changes the result. Tips multiplied: assign a role, think step by step, use delimiters, give examples. These are useful, but they share a hidden assumption, that the user already knows what they want and only needs better phrasing.

In practice the bottleneck is usually earlier. Users have a rough idea and have never articulated the audience, the constraints or the definition of "good". No phrasing trick can supply information that the user has not yet produced.

Three failure patterns follow from this.

1. The thin prompt. One line, no context. The output is generic, so the user adds "make it better" and iterates five times.
2. The dump. The user pastes everything they know in no particular order. The signal is there, but the priorities are not: the model cannot tell a hard constraint from a passing thought.
3. The cargo-cult prompt. A template found online, filled with half-fitting details. It looks professional and produces average work.

A brief fixes all three because it is both complete and ordered. Each element has a job, and the model can tell which job each sentence is doing.

How agencies brief, and why it transfers

Creative agencies have run on briefs for a century because the economics are unforgiving. A creative team that starts from a vague brief burns days producing the wrong thing. A good brief is short, specific and opinionated, and it contains a few things that a vague request never does: a single clear objective, a defined audience, boundaries and a way to judge the result.

An AI model behaves like a very fast junior creative with no memory of your company. Cost of a bad brief is lower in hours but identical in kind: wasted iterations and work you cannot use. The same discipline applies, and the same structure works.

The nine elements of a brief

Here is each element, what it does, and what a weak versus strong version looks like.

1. Goal

What should exist at the end, and what should it accomplish? A goal names the outcome, not just the artifact.

• Weak: "Write an email."
• Strong: "Write a cold email that gets a head of operations at a logistics firm to book a 20-minute call."

2. Audience

Who will read, hear or use this? Describe their knowledge, their attitude and what they care about. The model adjusts vocabulary, depth and persuasion to match.

• Weak: "For customers."
• Strong: "Existing customers on the free plan, mostly freelancers, who have used the product for under a month and are unsure it is worth paying for."

3. Context

The background the model cannot guess: your product, the situation, what has already happened, source material, relevant facts. Context is the element most often omitted, and the one that most separates generic from specific output.

4. Constraints

The hard boundaries: length, word count, deadline-driven scope, legal or compliance limits, required inclusions, tools or data the answer must stay within. Constraints should be testable. "Short" is a wish; "under 120 words" is a constraint.

5. Tone

How it should sound. Tone is easier to convey with contrast and anchors than with adjectives alone: "warm but not chatty, confident without hype, closer to a knowledgeable colleague than a salesperson."

6. Format

The shape of the output: headings, bullets, a table, JSON, three variants, a subject line plus body. Without a format the model chooses one, and it often chooses a long essay with a bulleted summary.

7. Examples

Samples of what good looks like, or of the style you want. Examples are the highest-bandwidth element: one good example conveys structure, tone and level of detail at once. Real published examples are better than invented ones, because they show what actually works in the wild.

8. What to avoid

Explicit exclusions: clichés, banned phrases, topics, competitors, claims you cannot support. Models respond well to a short, specific "do not" list, especially when it names the habit you have seen before ("no opening with a question, no 'in today's fast-paced world'").

9. Success criteria

How you will judge the result. This is the element that turns "good" into something the model can aim at: "The reader should be able to explain the offer in one sentence after reading. A skeptical CFO should not find a claim they can't verify."

The elements at a glance

Element	Question it answers	Typical failure when missing
Goal	What outcome do I want?	Output that is on-topic but pointless
Audience	Who is it for?	Wrong level, wrong vocabulary
Context	What does the model not know?	Generic, plausible-sounding filler
Constraints	What are the hard limits?	Too long, off-scope, non-compliant
Tone	How should it sound?	Default corporate-neutral voice
Format	What shape should it take?	Unusable structure, rework
Examples	What does good look like?	Style drift
What to avoid	What would ruin it?	Clichés and repeated mistakes
Success criteria	How will I judge it?	Endless "make it better" loops

Not every task needs all nine at full weight. A brief for a product name may barely need format; a brief for a board memo needs all of them. The point of the checklist is that you decide to skip an element, rather than forgetting it.

Why gather the brief by interview

Knowing the nine elements does not make them easy to produce. Staring at a blank box and trying to write nine paragraphs is the same blank-page problem again, only with a longer checklist.

Interviews work better for several reasons.

• Recognition beats recall. Answering "Who is this for?" is easy. Remembering to specify an audience unprompted is not.
• One question at a time keeps thinking focused. Each answer is small, and small answers get done.
• Questions can adapt. If the goal is a sales email, the follow-up asks about the offer; if it is a technical explanation, it asks about the reader's expertise.
• Interviews expose contradictions early. If you ask for "formal but playful" and "under 50 words," a good interviewer notices the tension.
• The user does the thinking, not the formatting. Turning answers into a well-structured prompt is mechanical work that software does better.

This is the idea behind PromptDeck. It interviews you one question card at a time, then writes a single ready-to-paste prompt. For the broader comparison with fill-in templates, see Templates vs interviews.

Choosing the depth

The interview comes in three lengths so effort matches the stakes.

Mode	Approx. questions	Best for
Quick	~8	Short, low-risk tasks: captions, subject lines, quick rewrites
Standard	~15	Most work: blog posts, emails, summaries, analyses
Deep	~25	High-stakes or complex output: strategy docs, long-form content, multi-step tasks

A useful rule: if you would be embarrassed by a mediocre result, go one level deeper than feels necessary.

Before and after: three examples

Example 1: a blog post

Before

Write a blog post about remote team productivity.

This produces a 700-word listicle with "set clear goals" and "use the right tools." Every competitor has already published it.

After (Standard brief)

# Role
You are a senior B2B content writer who has managed remote teams.

# Goal
Write a blog post that convinces engineering managers to replace their daily
status meeting with a written async update. The post should lead readers to
download our one-page async update template.

# Audience
Engineering managers at 20-200 person software companies. They are skeptical
of "async-first" evangelism because they have seen it go badly. They are
short on time and respect specifics.

# Context
We make a project tracking tool. Our own team replaced daily standups six
months ago; the main lesson was that updates only work if they have a fixed
structure (done / next / blocked).

# Constraints
- 1,000-1,200 words
- Mention our template once, near the end, not in the intro
- Do not make claims about measured productivity gains

# Tone
Direct, practical, mildly dry. A peer sharing what worked, not a guru.

# Format
H2 headings, short paragraphs, one example update in a code block,
a closing section "When this does not work".

# What to avoid
Openers like "In today's fast-paced world." Generic advice such as
"communicate clearly." Hype words.

# Success criteria
A skeptical manager should finish with one concrete change to try this
week and an honest sense of the risks.

Same model, same topic. The second prompt gives it a position to argue, a reader to respect and a bar to clear.

Example 2: a Claude task with XML structure

For Claude, the same brief is typically more reliable as XML tags, which cleanly separate instructions from material.

<role>You are a customer-success analyst.</role>

<goal>
Summarize the attached support tickets into the five most common causes of
churn risk, ranked by frequency, so the product team can choose what to fix
next quarter.
</goal>

<audience>Product leadership. Non-technical. Five minutes to read.</audience>

<context>
The tickets come from the last 90 days, from customers on paid plans only.
</context>

<constraints>
- Quote at most one short customer sentence per cause
- Do not speculate about causes the tickets do not support
- Flag any cause with fewer than 5 tickets as "low confidence"
</constraints>

<format>
A table: cause, ticket count, example quote, confidence.
Followed by three sentences of recommendation.
</format>

<avoid>Jargon, internal team names, sentiment scores without evidence.</avoid>

<success_criteria>
Leadership can pick a top priority from the table without opening the tickets.
</success_criteria>

<tickets>
{{paste tickets here}}
</tickets>

See Claude XML prompting for why tags work well, and ChatGPT vs Claude prompting for the broader differences.

Example 3: a short Quick brief

Not every task needs a long prompt. Here is a Quick (~8 question) result for a simple task.

Write 5 subject lines for a webinar invitation to HR managers about
reducing onboarding time. Each under 55 characters, plain and specific,
no exclamation marks, no emoji, no "unlock" or "game-changer." The goal
is opens, not clicks. Return a numbered list with a one-line rationale
for each.

Eight answers, one short paragraph, and it already covers goal, audience, constraints, tone, format and what to avoid.

How the interview becomes a prompt

Turning answers into a prompt is more than concatenation. Good assembly does five things.

1. Orders the information so that goal and audience come before detail.
2. Resolves overlaps so the same constraint is not stated three ways.
3. Writes in the model's preferred structure: markdown headings for ChatGPT, XML tags for Claude.
4. Preserves the user's specifics such as numbers, names and phrases, rather than paraphrasing them into vagueness.
5. Ends with the success criteria, which gives the model something to check its draft against.

You still own the result. Read it, edit it, and paste it into your model of choice.

Finding real reference examples

Element seven, examples, is where many briefs fall down because the user does not have a good sample at hand. PromptDeck can search for real published reference examples on the web, such as articles, landing pages or emails in the style you want, and bring them into the brief.

Guidelines for using examples well:

• Use one to three. More dilutes the signal.
• Say what to learn from each: "match the structure, not the topic."
• Never ask the model to copy; ask it to match qualities such as pacing, specificity and opening style.
• Respect copyright: use examples to inform style, not to reproduce text.

When Brief Prompting is the wrong tool

Honesty about limits is part of method. A brief is overkill when:

• the task is a trivial lookup or one-line rewrite;
• you are exploring and want the model to surprise you; in that case a loose prompt is a feature;
• the work is a continuing conversation in which context has already been established.

Brief Prompting also does not replace review. A great brief reduces bad output; it does not remove the need to check facts, especially for claims and figures.

A practical checklist

Before you send any important prompt, ask:

• Can I state the goal as an outcome, not a task?
• Could a stranger tell who the audience is?
• Did I include the one fact the model could not guess?
• Are my constraints measurable?
• Did I say what to avoid, based on past disappointments?
• Do I know how I will judge the result?

If you answer "no" to two or more, you are writing a request, not a brief.

Getting started

You can try the method in a few minutes. Pick a task you do regularly, run a Quick or Standard interview and compare the output with what you usually get. PromptDeck gives you one free prompt, and Pro is €9 per month (100 credits) or €79 per year. There is also a ChatGPT and Claude connector, so you can run the interview where you already work.

Try PromptDeck free to turn your next rough idea into a brief. For the concept in short form, read What is Brief Prompting?, and for how it compares with classic technique, see Prompt engineering vs Brief Prompting. Browse worked examples in the library.

FAQ

What is Brief Prompting in one sentence?

Brief Prompting is briefing an AI like a top agency briefs a creative, covering goal, audience, context, constraints, tone, format, examples, what to avoid and success criteria, gathered by interview rather than written from scratch.

How is a brief different from a long prompt?

Length is not the point. A long prompt can be a disorganized dump. A brief is structured so that each sentence does a defined job, and the model can tell goals from constraints and context from examples.

Do I need all nine elements every time?

No. Decide deliberately which to skip. A short, low-risk task may need only goal, audience, tone and format. High-stakes or complex work benefits from all nine, which is what the Deep interview is for.

Does Brief Prompting work with both ChatGPT and Claude?

Yes. The content of the brief is the same; the packaging differs. PromptDeck writes markdown headings for ChatGPT and XML tags for Claude, because each model tends to follow its respective structure reliably.

Will a better prompt stop the model making things up?

It reduces the risk by supplying source material and boundaries, and by asking the model to flag uncertainty. It does not eliminate it. Always verify facts, figures and quotations before publishing.

How long does the interview take?

Quick takes a couple of minutes, Standard a few more, and Deep longer because it asks around 25 questions. Time spent answering is usually less than the time lost to repeated rewrites.