If you have ever typed a vague instruction into an AI tool and got back something bland, repetitive or quietly wrong, the problem usually is not the AI. It is the brief. AI models are extremely good at producing fluent text from whatever you give them, and extremely bad at guessing what you actually meant if you do not tell them. A thin prompt like "write a blog post about email marketing" will get you a thin, generic article that sounds like every other thin, generic article on the internet, because that is exactly what it was trained to default to. A proper brief changes the output dramatically, not because the AI gets smarter, but because you have removed the guesswork. This article walks through what a solid article brief actually needs: who you are writing for, what question they are really asking, what facts and sources you can actually stand behind, how the piece should be structured, what voice it should sound like, and what you still need to check once the draft comes back. None of this requires special software. It is simply a discipline, and it is one that separates useful AI-assisted content from AI slop.
Key takeaways
- A brief needs a specific audience and their real question, not just a topic or keyword.
- Supply the facts, figures and sources you want used; AI will invent plausible-sounding ones if you leave gaps.
- Give structural guidance (headings, length, examples) so the draft matches how your readers actually read.
- Specify voice and things to avoid, including banned phrases and claims, so editing is lighter.
- Always plan a human review step; a brief reduces editing, it does not remove the need for it.
Start with the reader's actual question, not a topic
Most briefs fail at the first line because they describe a subject area instead of a question. "Email marketing tips" is a subject area. "Why do my welcome emails get good open rates but terrible click-throughs, and what should I check first" is a question. The second version gives an AI model something to actually answer, with a beginning, a middle and an end, rather than something to wander around.
Before you write a brief, ask yourself what the reader typed into Google, or what they would ask a knowledgeable friend, immediately before landing on this article. If you cannot answer that in one sentence, the brief is not ready yet. It also helps to be honest about where the reader currently is: are they trying to decide whether a problem is worth solving, comparing two approaches, or stuck on a specific mistake they have already made? Each of those needs a different opening and a different level of detail.
- Write the reader's question as a single sentence before anything else in the brief.
- Note what the reader probably already knows, so the draft does not waste paragraphs explaining basics they do not need.
- Identify the one practical outcome the reader should be able to act on after reading.
Supply facts and sources, do not expect AI to find good ones
This is the part most people skip and it causes the most damage. Large language models are fluent, not factual. If your brief does not include the specific statistics, dates, product details or quotes you want used, the model will often produce something that sounds plausible and is not accurate, particularly for anything time-sensitive or niche. It is not being deceptive; it is doing what it was built to do, which is predict reasonable-sounding text.
The fix is straightforward: put the actual facts in the brief. If you want a statistic cited, paste the statistic and where it came from. If you are writing about a feature, describe exactly what the feature does today, not what it is planned to do, because AI has no way of knowing your product roadmap unless you tell it. If the topic is time-sensitive (pricing, regulations, platform policies, seasonal trends), say explicitly that these details need checking against a current source before publication, and flag that in your own review notes rather than trusting the draft blindly.
A brief should also say what not to claim. If your business cannot promise certain outcomes (promises of a particular search position, specific sales outcomes, specific percentage improvements) say so directly, because otherwise a draft will happily produce confident-sounding promises that someone in legal or customer support will have to walk back later.
- List the specific facts, numbers and sources you want referenced, with links where possible.
- Flag anything time-sensitive that needs a current check before publishing.
- State explicitly which claims or promises are off-limits for this piece.
Sources: Documentation to Improve SEO | Google Search Central | Google for Developers
Give structural guidance, not just a word count
A target word count tells an AI tool almost nothing useful about how to use that length well. What actually shapes a good structure is telling the model how the reader will consume the piece: do they need a quick scannable answer near the top, a step-by-step walkthrough, a comparison table, or a long narrative explanation? If you want headings that match how people search (so the piece can answer several related questions, not just one), say that directly and list the sub-questions you want covered.
It also helps enormously to specify where examples belong. A brief that says "include a worked example showing a bad version and a better version of this brief" will get you something concrete and useful. A brief that just says "make it practical" will get you something vague that claims to be practical without actually being so. If you have a real scenario, even a simplified one, put it in the brief. If you do not have a real one, say so and ask for a clearly hypothetical, clearly labelled illustration instead of letting the draft imply it is a true case study.
- List the sub-questions or headings you expect the article to cover.
- Specify where you want a worked example, checklist or comparison, and what it should illustrate.
- Say whether any example should be clearly hypothetical if you have no real case to share.
Set the voice and the things to avoid
Voice is where briefs get lazy, usually reduced to a single adjective like "professional" or "friendly", which tells the model almost nothing. A more useful approach is to describe the voice by contrast: more conversational than a corporate press release, less jokey than a social caption, written the way an experienced practitioner would explain something to a smart colleague who is busy. Giving two or three sentences of a style you like, even from your own previous writing, works better than a single adjective.
Equally important is a list of phrases and habits to avoid. Overused AI phrasing ("in today's fast-paced world", "vague promotional slogans", "overused introductory phrases") creeps in constantly unless you explicitly ban it. If your organisation has house style rules, UK versus US spelling, preferred terminology, or banned superlatives, put them in the brief rather than discovering them during editing. This single step probably saves more editing time than any other part of the brief.
- Describe voice by contrast (more like X, less like Y) rather than with a single adjective.
- List specific words and phrases to avoid, including generic AI stock phrases.
- State spelling convention and any house terminology upfront.
Plan the human review before you even generate the draft
A brief, however good, does not remove the need for a human to check the output. What it does is change what that human is checking for. With a weak brief, an editor spends most of their time rewriting structure and adding missing substance. With a strong brief, the editor's job shifts to verifying facts, checking tone fits the brand, and confirming nothing has drifted into an unsupported claim or an invented statistic.
It is worth deciding, before you generate anything, who checks facts, who checks tone, and who gives final approval. For anything involving numbers, dates, prices, legal or medical content, decide in advance that those specific claims get verified against a current, named source rather than accepted on faith because the sentence sounds confident. AI drafts are a genuinely useful starting point, provided everyone involved treats them as a draft, not a finished, fact-checked article.
- Decide who checks facts, who checks tone and who approves, before generating the draft.
- Treat any number, date, price or claim as unverified until checked against a current source.
- Use the brief as a tool to speed up drafting, not as a substitute for editorial judgement.
Sources: Documentation to Improve SEO | Google Search Central | Google for Developers
Frequently asked questions
How long should an article brief be?
Long enough to answer the questions above, short enough that someone would actually read it. For most articles, a few sentences on audience and the reader's real question, a short list of facts or sources to use, a rough structure with headings, and a short note on voice and things to avoid, is usually enough. A brief that takes twenty minutes to write typically saves far more than twenty minutes in editing.
Can I just paste a keyword into an AI tool and get a good article?
You can, but the result will usually read like a generic summary of the keyword rather than a genuinely useful answer to a real question. Keywords describe what people type into search boxes, not what they actually want to know or do. A good brief translates the keyword into a specific question and a specific practical outcome.
Should I tell the AI tool what not to say?
Yes. Explicitly listing banned claims, banned phrases and any commercial facts that must not be invented (prices, guarantees, statistics) prevents a lot of avoidable editing later, and reduces the risk of publishing something inaccurate or overconfident.
Does a detailed brief guarantee a publishable draft?
No brief guarantees a finished article. It significantly improves the starting point, but every draft still needs a human check for accuracy, tone and any claim that sounds confident but is not actually backed by a real source.