# The Draft Bench — full text

> The Draft Bench is an independent publication about briefs, drafting systems, editorial review, and content operations. It is not a content agency, publishing platform, SEO vendor, newsroom, certification provider, or continuation of any former entity associated with this domain.

# How to Audit a Blog Post Before Publishing

> Audit a blog post in separate passes. Compare the title, opening, headings, conclusion, and metadata promise with the body. Next verify numbers, date, quote, named source, specification, price, and consequential claim; recompute arithmetic and search for values across body and FAQ. Then inspect structure, examples, steps, tables, care boundaries, external sources, and internal links. Align title, answer block, and FAQs; render at multiple widths; test keyboard use, downloads, images, and links; read aloud; and search for unfinished stand-ins or malformed text. Record files, checks, caveats, status, and reviewer at handoff.

Source: https://blogwerk.com/audit-blog-post-before-publishing/  
Publisher: The Draft Bench  
Published: 2026-07-19  
Updated: 2026-08-26

## Audit in passes, not one heroic reread

A pre-publication audit checks whether the article answers its question, supports its claims, works as a page, and matches the delivery contract. Separate those jobs. Reading once for facts, tone, links, headings, and commas guarantees that the comma will receive an exquisite review while a broken source waves from paragraph six.

Save a review copy or use version history. Record material changes, especially factual corrections. Do not silently “improve” a number without tracing its source and recomputing every place it appears.

## Pass 1: compare promise with delivery

Read only the title, opening, heading list, conclusion, and metadata answer. Write the promise in one sentence. Then ask whether the body actually delivers it.

A title promising “best tools” needs criteria, a verdict, tradeoffs, and evidence. “How to” needs prerequisites, ordered steps, verification, and failure handling. A recipe needs yield, quantities, pan or equipment, times, temperatures, and doneness. If the format fails its type, polish will not rescue it.

Check that the primary reader appears in the examples and that the opening answers rather than merely announces a journey. Remove throat-clearing that delays the useful sentence.

Compare against the [editorial brief](/write-editorial-brief-prevents-rewrites/) and note every intentional deviation. Research may justify a better angle; undocumented drift merely creates an argument during review.

## Pass 2: verify claims and arithmetic

Highlight every number, named institution, quote, date, specification, legal or health statement, product feature, price, place detail, and causal claim. For each, open the source and confirm it supports the exact wording in context.

Prefer primary and current sources when the subject requires them. Distinguish what the source states from your inference. Check publication and event dates separately. A page updated yesterday may describe a policy from ten years ago; an old page may still hold the current standard.

Recompute arithmetic from inputs. Verify unit conversions, totals, percentages, per-serving quantities, date counts, and table/body consistency. Search the whole package for each corrected number. The fact that 4 × 225 equals 900 in one paragraph does not stop a forgotten FAQ from confidently serving 950.

Remove invented precision, unattributed quotes, and statistics that cannot be verified. Generalize honestly when detail is unavailable.

## Pass 3: inspect structure and usefulness

Read the first and last sentence of every section. Each should answer one distinct question and lead to the next. Merge repetition; split sections that perform several jobs. Make headings describe reader value rather than cleverness alone.

Test every instruction as a sequence. Are prerequisites available before use? Are destructive steps labeled before the command or click? Does the reader know what success looks like and what to do when it fails? Add one complete example where abstraction remains high.

Tables should compare like with like. Every column needs a purpose, units must be consistent, and cells should remain understandable on small screens or in an accessible alternative.

Browse [editing systems](/editing-systems/) for recipe, code, comparison, and location-specific audit variants.

## Pass 4: check links and boundaries

Open every external link. Confirm the destination is the intended page, not a home page that vaguely discusses the topic. Check anchors honestly describe the supporting source. Replace stale redirects when an authoritative current page exists.

Open internal links in the actual site inventory. Do not link to drafts, nonexistent slugs, the current article itself, or a vaguely similar title. Use enough context in the anchor to explain why the next page helps.

Check the care line. Health content defers to qualified care; recipes protect time and temperature; travel details avoid invented hours; product guides disclose what was and was not tested; technical articles flag irreversible actions; cultural writing does not turn a community into decoration.

## Pass 5: align title, metadata, and FAQ

Count title length under the publication rule and front-load the reader's query without making syntax limp. Verify the title's promise at the section level.

Read the metadata answer as a standalone result. It should answer the primary question, not advertise that the body contains an answer. Check its word range. Each FAQ question should add information a reader plausibly needs, and each answer must remain correct when surfaced without the surrounding article.

Search for contradictions between body, table, answer block, FAQs, image captions, and structured data. Metadata is content, not a backstage area where old numbers go to retire.

## Pass 6: render and interact

Preview the page at narrow and wide widths. Inspect heading hierarchy, lists, code wrapping, table overflow, callouts, images, captions, alt text, focus order, and contrast. Use keyboard navigation and relevant assistive technology checks. Confirm the body begins and ends cleanly without frontmatter or unfinished production tokens leaking into view.

Click links and controls in the rendered page. Validate downloadable files. Check images for misleading content, licensing records, crop problems, and people or places the caption identifies incorrectly.

## Pass 7: read aloud and hand off

Read the article aloud or use text-to-speech. Listen for repeated openings, tangled sentences, missing words, artificial rhythm, and jokes that interrupt a safety instruction. Replace robotic signposting with direct transitions, but keep necessary warnings explicit.

Run spelling and grammar tools last, reviewing each suggestion rather than accepting the machine's sudden campaign against technical vocabulary. Search for unfinished-task flags, generic stand-in names, malformed characters, and duplicate spaces, and unsupported “best,” “always,” or “guaranteed.”

Finish in [planning tools](/planning-tools/) by recording status, files, checks run, unresolved caveats, and reviewer. The article is ready when the evidence, page, and handoff agree—not when the author has stared at the same paragraph long enough for it to achieve diplomatic immunity.

## Frequently asked questions

**Why audit a blog post in separate passes?**

Different review tasks compete for attention. A single reread may catch punctuation while missing a citation mismatch or broken promise. Separate passes let the editor focus on delivery, facts, structure, links, metadata, rendering, and language in turn. They also produce a clearer record of what was checked. Save version history so a factual correction can be traced and does not silently create new contradictions elsewhere.

**Which claims need verification before publishing?**

Verify every number, date, quotation, named institution, law, health or safety statement, product feature, price, specification, place detail, and causal claim. Open the source and confirm the exact wording in context, using current primary material when appropriate. Distinguish the source's statement from your inference. Remove unverifiable precision and recompute totals, percentages, conversions, dates, and examples rather than trusting the draft's arithmetic.

**How do I audit internal and external links?**

Open every link. External anchors should describe a destination that directly supports the attached claim, not merely a relevant home page. Internal targets must exist in the site's current inventory, help the reader, and not point to the article itself, an unpublished draft, or an uncertain slug. Check redirects and rendered behavior. A linked article may provide context, but an internal link does not substitute for external evidence.

**What should I check in blog metadata and FAQs?**

The metadata answer should solve the primary question when read alone, stay within its word range, and avoid promises the body cannot fulfill. FAQ questions should add plausible reader value rather than repeat headings. Each answer must remain accurate when surfaced without surrounding context. Search body, tables, captions, answer, FAQs, and structured data for contradictory numbers, dates, terminology, or safety guidance after every material correction.

**What belongs in a final content handoff?**

List the delivered files, status, checks run, source or data caveats, known limitations, unresolved decisions, and designated reviewer. Confirm filenames, format, encoding, word limits, title rules, link targets, and required assets. Include rendered or interaction checks when layout matters. Do not hide a skipped requirement inside a general “done” message; name it and its effect. A useful handoff lets another person verify the work without reconstructing the entire assignment.


---

# Blog Content Calendar: A Small-Team Workflow

> Create one record per article, with a specific reader question, an owner, a current status and separate dates for drafting, review and publication. Add the next action and any blocker. Schedule only work that has completed your editorial checks, then record the actual live URL and a future review trigger. Start with the amount of work your team can finish and review, rather than filling every available date.

Source: https://blogwerk.com/blog-content-calendar-small-team/  
Publisher: The Draft Bench  
Published: 2026-09-08  
Updated: 2026-09-08

## How do you create a blog content calendar?

Create one record per article, with a specific reader question, an owner, a current status and separate dates for drafting, review and publication. Add the next action and any blocker. Schedule only work that has completed your editorial checks, then record the actual live URL and a future review trigger. Start with the amount of work your team can finish and review, rather than filling every available date.

The method below is The Draft Bench's proposed workflow for a solo publisher or small team. It works as a table or task board; the field definitions matter more than the software. The examples are fictional planning scenarios, not productivity benchmarks.

## What belongs in the calendar?

A calendar coordinates several articles. The [editorial brief](/write-editorial-brief-prevents-rewrites/) defines one assignment in detail. Link the brief from the calendar instead of maintaining two competing copies of its requirements.

Keep these fields:

| Field | What to enter |
|---|---|
| Article ID | A stable identifier that survives title changes |
| Reader question | The decision or task this article answers |
| Work type | New article or revision of an existing URL |
| Owner | One person responsible for the next handoff |
| Status | A defined stage such as drafting or in review |
| Next action | The specific task that moves the article forward |
| Draft due | When the complete draft is expected |
| Review due | When the editorial decision is expected |
| Planned publication | Intended date, time and time zone |
| Blocker | Missing input, who supplies it and when to check again |
| Draft or live link | The authoritative file or published page |
| Next review | A date or event that requires another check |

A stable ID can be as simple as B-017. If the title changes, comments and dependencies still point to the same item. Do not make a headline the only way to identify an assignment.

[Asana's own editorial-calendar documentation](https://asana.com/templates/editorial-calendar) includes owners, content status, approval status and publication dates. Its examples demonstrate that these can be separate fields. You can apply that distinction without adopting its product.

## Which statuses are useful?

Use statuses with observable entry conditions. For this workflow, we propose the following:

- **Backlog:** an idea exists, but no delivery commitment has been made.
- **Ready to draft:** scope, owner and required inputs are available.
- **Drafting:** the writer is producing the agreed deliverable.
- **In review:** a complete draft is available to the named reviewer.
- **Changes requested:** the reviewer has identified specific unfinished work.
- **Approved:** the required editorial checks are complete.
- **Scheduled:** the publishing system confirms a future release.
- **Published:** someone has checked the live page and recorded its URL.

Keep “blocked” as a separate field. A draft can be blocked by a missing example; a review can be blocked by an unavailable specialist. Recording only “blocked” would lose the stage at which the interruption happened.

Avoid percentage-complete estimates unless the team has a consistent definition. “Ninety percent done” can mean missing a comma or waiting for the evidence that determines the conclusion. The next action is more useful.

## How far ahead should you plan?

Use two levels of commitment. Keep future ideas in the backlog and give firm dates only to work whose scope and resources you can explain. For a new team, a short initial scheduling period is an editorial starting point, not an industry rule.

Choose a publication frequency after identifying writing and review capacity. Here is a fictional weekly example:

- Writing time available: 6 hours.
- Estimated writing time per article: 3 hours.
- Review time available: 1 hour.
- Estimated review time per article: 1 hour.

Writing capacity is 6 ÷ 3 = 2 articles. Review capacity is 1 ÷ 1 = 1 article. The plan can support one fully reviewed article under these assumptions. Booking two publication slots leaves one article without allocated review time.

Actual production can take longer or shorter. Replace the estimates with your own records once you have them. Count revision, source checking and page preparation somewhere; leaving them out of the estimate does not remove the work.

## How do you work backward from publication?

Set handoff dates in the order the work depends on them. A planned release must leave room for a draft, a review decision, any corrections and preparation in the publishing system.

Consider this fictional sequence for one small article:

| Milestone | Example date | Completion evidence |
|---|---|---|
| Brief agreed | 2026-09-08 | Scope and owner recorded |
| Complete draft | 2026-09-10 | Draft link and source notes available |
| Review decision | 2026-09-11 | Approval or specific requested changes |
| Corrections and page preparation | 2026-09-14 | Required checks complete |
| Intended release | 2026-09-15, 09:00 UTC | Scheduled status confirmed |
| Live-page check | After release | Public URL opens as intended |

These dates illustrate dependencies. They do not establish a standard turnaround time. A complex comparison may need more research; a specialist review may need a longer booking.

If review is unavailable on the intended date, change the plan before the draft is due. Do not assign the same person simultaneous deadlines on the assumption that the calendar's rows can be completed independently.

## How do you handle missing information?

Write a blocker so another person can act on it. Replace “waiting for feedback” with “editor to confirm whether the export example covers archived records; check again September 10.”

Separate the original planned publication date from the current plan. When an article moves, keep a short reason. This helps distinguish an unrealistic estimate from a changed assignment or an external dependency.

Our proposed rule is that unresolved accuracy, safety or required approval work prevents scheduling. When an article is delayed, choose among three explicit actions: reschedule it, reduce its scope with editorial agreement, or use another already-approved article. Do not remove a required check merely to keep a date occupied.

If the missing information changes what the article can promise, update its brief as well as its calendar row. The schedule should not become the only place where a material scope decision survives.

## Is a planned publication date the same as a scheduled post?

No. A date in your planning tool expresses an intention. A scheduled post requires confirmation from the content management system, or CMS, that will publish it.

For example, [WordPress.com's scheduling guide](https://wordpress.com/support/schedule-a-post-or-page/) instructs users to choose a future date and time and select Schedule. It says the settings then show a scheduled status. Its troubleshooting checks include the site's time zone and whether the post was saved as a draft instead.

The same documentation notes that scheduled publication can depend on a site visit. That detail is specific to the documented platform behavior, not a universal promise about every CMS. For your own system, follow its current instructions and assign someone to verify the release.

Use one named time zone in the calendar. Confirm that the CMS interprets the intended time correctly. After publication, record the actual timestamp separately so a late release does not silently rewrite the original plan.

## What should a weekly calendar review decide?

Review decisions, not every paragraph. Start with work that is blocked or nearing a handoff. Then confirm that the next scheduled items have owners and available reviewers.

Use a short sequence:

1. Check what actually published and attach its live URL.
2. Resolve or reassign blocked next actions.
3. Confirm the upcoming draft and review dates with their owners.
4. Remove or revise commitments that no longer have enough time.
5. Pull the next suitable assignment from the backlog only when capacity exists.

A solo publisher can perform the same review. The owner and reviewer may be the same person, but drafting and checking still need separate time.

Keep the article's quality review in the [pre-publication audit](/audit-blog-post-before-publishing/). The calendar records that the check happened and points to the result; it does not replace the check.

## Where do updates to old articles fit?

Give a revision its own work record and link the existing URL. State what needs checking: a changed feature, an obsolete screenshot, a broken source or a reader question the current article does not answer.

[GOV.UK's content-management guidance](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/plan-manage-content/manage-existing-govuk-content/) distinguishes publication state, update information and overdue review dates. It also recommends monitoring whether content remains useful. Those distinctions are useful for a blog even though its publishing tools differ.

Choose review triggers according to the material. A software walkthrough can need reassessment when the interface changes; a general writing exercise may be reviewed after reader feedback. A calendar reminder means “check this,” not “pretend this was newly published.”

When a substantial revision changes the page, record what changed. [Google's date guidance](https://developers.google.com/search/blog/2019/03/help-google-search-know-best-date-for) advises updating the visible date when a page is significantly updated and keeping visible and structured dates consistent. Retain an internal checked date for reviews that produce no material change.

The calendar is complete enough when each active row answers three questions: who acts next, what they need to do, and what proves that stage is finished.

## Sources

- [Asana: Editorial calendar template](https://asana.com/templates/editorial-calendar) — examples of separate ownership, approval and publication fields.
- [WordPress.com: Schedule posts and pages](https://wordpress.com/support/schedule-a-post-or-page/) — scheduling confirmation, time-zone checks and release behavior; reviewed August 11, 2026.
- [GOV.UK: Manage existing content](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/plan-manage-content/manage-existing-govuk-content/) — content state, review dates and ongoing usefulness.
- [Google Search Central: Dates for web pages](https://developers.google.com/search/blog/2019/03/help-google-search-know-best-date-for) — significant updates and consistent date presentation.

## Frequently asked questions

**What is the minimum information in a blog content calendar?**

Record the article's reader question, owner, status, next action and separate draft, review and planned publication dates. Link the authoritative draft and record blockers. After publication, add the live URL and a review trigger. Keep the detailed assignment in its brief so the calendar stays usable.

**How often should a small blog publish?**

Base the commitment on available writing and review time. In the fictional example here, six writing hours at three hours per article permit two drafts, but one review hour at one hour per article permits only one reviewed article. Your own estimates and results should determine your schedule.

**What should happen when a scheduled article is delayed?**

Record the blocker, its owner and the next check date, then update the current plan while retaining the original target. Reschedule, agree a narrower scope or substitute an already-approved article. Unresolved accuracy, safety or required approval work should prevent scheduling under the workflow proposed here.

**Is a content calendar the same as the publishing schedule?**

A planning date is an intention; a scheduled post needs confirmation from the publishing system. Record that confirmation and check the site's time zone. Assign someone to verify the live page after release, then record the actual timestamp and public URL separately from the planned date.

**Should older posts appear in the calendar?**

Yes. Create a revision record linked to the existing page and state what needs checking or changing. Use review dates or relevant events as triggers. A review that finds no necessary change belongs in the internal record; it does not automatically justify presenting the page as newly updated.


---

# How to Write Alt Text for Blog Images

> Write alt text that supplies the information or function an image contributes in its specific page context. Describe the relevant detail in an informative image, name the destination or action of an image-only link, and use an empty alt attribute for a purely decorative image. Give complex charts a short identifier plus an accessible longer explanation. Keep the wording concise, factual and free of keyword stuffing.

Source: https://blogwerk.com/write-alt-text-blog-images/  
Publisher: The Draft Bench  
Published: 2026-09-15  
Updated: 2026-09-15

## How do you write alt text for blog images?

Write alt text that supplies the information or function an image contributes in its specific page context. Describe the relevant detail in an informative image, name the destination or action of an image-only link, and use an empty alt attribute for a purely decorative image. Give complex charts a short identifier plus an accessible longer explanation. Keep the wording concise, factual and free of keyword stuffing.

Alt text is a text alternative, not a second headline. Decide what the reader needs from the image before drafting the sentence. The examples below are hypothetical editorial exercises, not descriptions of photographs we have inspected.

## What information does this image add?

The [W3C Web Accessibility Initiative's informative-image guidance](https://www.w3.org/WAI/tutorials/images/informative/) emphasizes meaning in context. Ask what disappears when the image is unavailable.

Imagine a tutorial photograph showing a folder label's placement. “Blue label attached to the upper-right corner of a file drawer” communicates more than “Office furniture.” Omit color if it has no instructional role.

Check that every described detail is actually present. Do not infer a person's identity, emotional state or expertise from appearance. Record the image's purpose in the [editorial brief](/write-editorial-brief-prevents-rewrites/) so the writer and image editor agree on what it must communicate.

## When should alt text be empty?

[W3C's decorative-image guidance](https://www.w3.org/WAI/tutorials/images/decorative/) recommends `alt=""` when an image adds no information: purely visual decoration or information sufficiently provided in adjacent text.

An empty attribute differs from omission, which can cause screen readers to announce the filename. Do not enter “decorative” or assume a caption makes every photograph redundant.

An unlinked ornamental divider can be decorative. A screenshot showing an error message absent from the prose is informative. Judge its use, not its format or attractiveness.

## What if the image is a link or button?

[W3C's functional-image guidance](https://www.w3.org/WAI/tutorials/images/functional/) specifies the action or destination. For an image-only worksheet link, “Download the article planning worksheet” communicates more than “Sheet of paper.”

If text inside that same link already fully conveys its destination and the image adds nothing, empty alt text may avoid repetition. An image-only link still needs an accessible name.

Use “Open full-size image” only if activating it does that. Verify the destination; the illustration cannot establish the link's behavior.

## How do you describe a chart or complicated diagram?

[W3C's complex-image tutorial](https://www.w3.org/WAI/tutorials/images/complex/) pairs a short identifier with a longer text equivalent for essential information. Place the detail nearby or provide a clearly identified link.

For a hypothetical chart comparing draft, review and publication dates, identify the chart and point to its schedule table. Preserve the chart's relationships in the longer explanation.

Supply relevant values, units and patterns. A table exposes data; prose explains the comparison. Verify both against the graphic. “Chart of results” does not convey those results.

## How long should the wording be?

[W3C's writing tips](https://www.w3.org/WAI/tutorials/images/tips/) favor a concise description of purpose, important information first. If that needs more than a brief phrase or sentence, provide a longer description outside the alt attribute.

Usually omit “image of.” Identify the medium when relevant: paintings and photographs may serve different evidential purposes. Use normal punctuation and remove unhelpful repetition.

A useful editorial check is to read the surrounding paragraph and proposed alternative together. If the result repeats the same sentence, reassess what information the image adds before shortening words mechanically.

## Should you add keywords for search?

[Google's image guidance](https://developers.google.com/search/docs/appearance/google-images) says it uses alt text alongside the page's content and computer vision to understand an image. It recommends useful, contextually appropriate wording and warns against keyword stuffing.

Describe the relevant subject naturally. Do not append a list of search phrases to an otherwise complete alternative. Likewise, do not turn an unrelated decorative image into an informative one just to insert a query. This guide makes no promise of a ranking increase from an alt-text edit.

## What should the final review record?

We suggest recording the image's purpose, proposed alternative and reviewer beside the asset. For a linked image, include its verified destination; for a complex graphic, include the location of the full explanation.

Check the rendered page after the text is entered. Confirm that the intended alternative is attached to the intended image, decorative images have the correct empty attribute, and longer explanations are discoverable. Ask the person maintaining the publishing system to resolve any uncertainty about its output. This focused check complements the [pre-publication audit](/audit-blog-post-before-publishing/); it is not a complete accessibility evaluation.

## Sources

- [W3C WAI: Informative Images](https://www.w3.org/WAI/tutorials/images/informative/)
- [W3C WAI: Decorative Images](https://www.w3.org/WAI/tutorials/images/decorative/)
- [W3C WAI: Functional Images](https://www.w3.org/WAI/tutorials/images/functional/)
- [W3C WAI: Complex Images](https://www.w3.org/WAI/tutorials/images/complex/)
- [W3C WAI: Tips and Tricks](https://www.w3.org/WAI/tutorials/images/tips/)
- [Google Search Central: Image SEO Best Practices](https://developers.google.com/search/docs/appearance/google-images)

## Frequently asked questions

**Should the same image always have the same alt text?**

Its role can change between pages. W3C explains that informative alternatives depend on the meaning an image contributes in context. Review the surrounding text and reason for including it each time. Reuse wording only when it still supplies the information that this particular placement needs.

**Is an empty alt attribute the same as leaving it out?**

No. W3C recommends an empty alt attribute for decorative images, while noting that some screen readers may announce a filename when the attribute is absent. Confirm the actual output of your publishing system. A blank field in an editor does not, by itself, establish which HTML was produced.

**What should alt text say for an image-only link?**

Describe the destination or action that the link provides. W3C distinguishes functional images from images that merely convey information. Check where the link actually leads before naming it. If visible text in that same link already fully communicates its purpose, a redundant image may instead need empty alt text.

**Does a chart need every value in its alt attribute?**

A complex chart needs a short identifying alternative and a longer explanation of its essential information. W3C describes ways to provide that detail alongside the image or through a clearly identified link. Preserve relevant values and relationships in the longer description rather than compressing an entire chart into one attribute.

**Should alt text start with the words image of?**

Usually those generic words add little. W3C notes that screen readers already announce images, while a specific medium can matter in some contexts. State that an item is a painting, photograph or illustration when that distinction contributes to understanding. Otherwise, begin with the information the reader actually needs.


---

# Write an Editorial Brief That Prevents Rewrites

> Write an editorial brief as a decision record. Define the reader, the action or decision the article should enable, and the risk it should avoid. State the question, article type, target length, deliverables, deadline, owner, reviewer, format, and acceptance criteria. Add explicit includes and excludes, duplication boundaries, a question-led outline, voice behaviors, required examples, source and claim plans, internal-link targets, and the subject's care line. End with yes-or-no checks for promise, coverage, current evidence, reconciled numbers, valid links, aligned metadata, and correct files, plus open questions and named decision owners.

Source: https://blogwerk.com/write-editorial-brief-prevents-rewrites/  
Publisher: The Draft Bench  
Published: 2026-07-19  
Updated: 2026-08-26

## A brief is a decision record, not a wish

An editorial brief should tell a writer which reader needs what outcome, within which boundaries, using what evidence, in which deliverable. “Write 1,500 words about project management and make it pop” tells us the topic, approximate furniture requirement, and nothing about who lives there.

Begin with one sentence:

> After reading, **[specific reader]** should be able to **[observable decision or action]** without **[important risk or confusion]**.

For example: “After reading, a first-time team lead should be able to choose a weekly status format without buying software or exposing private employee information.” That sentence shapes scope, examples, sources, and the care line.

## State the assignment facts

Put these fields at the top:

- working title and primary reader question;
- audience knowledge and context;
- article type and target length;
- publication, category, voice, and delivery format;
- deadline, owner, reviewer, and approval path;
- success criteria and any fixed requirements.

A target length is a planning range, not permission to inflate three useful paragraphs into a ceremonial fog bank. Define acceptable tolerance. If the piece needs a table, calculator, code sample, recipe, image, quote, or downloadable file, say so now.

Record title constraints and metadata requirements separately from the body. A search query may inform the angle, but it does not replace the reader or make every exact phrase grammatical.

Browse [planning tools](/planning-tools/) for brief fields suited to different article types.

## Define scope with includes and excludes

Write three to six things the article must cover and two to five things it will not cover. Exclusions prevent a useful article from becoming a tiny encyclopedia with one paragraph per continent.

For a guide to choosing a meeting format, scope might include participant count, decision type, preparation, accessibility, privacy, and follow-up. It might exclude a vendor roundup, employment-law advice, and instructions for a specific company's internal system.

Name adjacent published or queued topics that must not be duplicated. Link the current content inventory or list exact titles and slugs. “Avoid overlap” is not enough when nobody has been shown the other work.

## Convert tone words into behaviors

“Friendly, expert, engaging” describes nearly every brief produced since the invention of adjectives. Translate voice into observable choices:

- define specialist terms on first use;
- use direct second person only in practical steps;
- include one dry aside per major section at most;
- never joke about harm, identity, grief, illness, or safety;
- prefer concrete verbs and examples to hype;
- state uncertainty and disagreement openly.

Add a short excerpt from an existing article when voice matching matters. Say what works in it. Otherwise, writers may imitate surface quirks and miss the publication's actual relationship with the reader.

## Build a question-led outline

List the questions the body must answer in reader order. A how-to commonly moves through prerequisites, setup, steps, verification, failure modes, and next actions. A comparison needs a verdict, criteria, comparable evidence, tradeoffs, and who should choose each option.

Keep headings provisional until research clarifies the material. The brief should specify logical coverage, not force evidence into a decorative outline. Include one sentence describing what each section must deliver so two headings do not quietly answer the same question.

## Attach a source and claim plan

Identify the claims that need current or primary support: laws, prices, specifications, health or safety guidance, dates, records, product features, named organizational policies, and statistics. List preferred source types and any mandatory official sources.

Do not prefill a persuasive statistic because the angle would enjoy one. Write the information need instead: “Find current official data on processing time, or generalize if unavailable.” Mark facts that must be recomputed, screenshots that need dates, and quotations that require exact attribution.

Separate source links from internal-link targets. An internal link must resolve and help the reader; it is not evidence for an external factual claim.

## Specify examples and care lines

State which example the article must include and what it must prove. “Add examples” often produces three variations of a sentence that already made sense. Ask for a worked calculation, before-and-after edit, failure recovery, decision table, or complete scenario.

Add the subject's care line: no medical promises, food temperatures verified, cultural claims sourced, commands tested, venue details checked, financial figures dated, or animal welfare prioritized. Care requirements belong beside the assignment, not in a policy document everyone is expected to remember telepathically.

## End with acceptance tests

Write a checklist a reviewer can answer yes or no:

- Does the opening answer the primary question?
- Does every required section deliver its named outcome?
- Are time-sensitive claims current and sourced?
- Do numbers and examples reconcile?
- Do links resolve to intended targets?
- Does metadata promise only what the body provides?
- Is the output in the required file structure?

Use the [pre-publication audit](/audit-blog-post-before-publishing/) as the matching review system and [editing systems](/editing-systems/) for specialized passes.

Finally, name open questions and who decides them. A good brief does not eliminate creative judgment. It prevents the writer and reviewer from discovering at line 1,407 that they were producing different articles with the same noun.

## Frequently asked questions

**What is the purpose of an editorial brief?**

It aligns writer, editor, and stakeholder on the reader, outcome, scope, evidence, deliverable, and review standard before drafting. A good brief removes consequential ambiguity without scripting every sentence. It makes disagreements visible while they are cheap to resolve, protects against topic duplication and unsupported claims, and gives the reviewer observable acceptance tests rather than a late request to make the article more engaging.

**How detailed should a content brief be?**

Detailed enough to define the reader question, required coverage, exclusions, evidence needs, examples, care line, format, and acceptance tests, but not so detailed that it prewrites transitions or forces research into an unsupported conclusion. High-risk, technical, commercial, or multi-format work needs more specification. A familiar low-risk essay may need less. Every field should prevent a plausible misunderstanding or support a real review decision.

**What belongs in a content brief outline?**

List the questions the article must answer in reader order and add one sentence describing each section's required outcome. A how-to needs prerequisites, steps, verification, failure handling, and next actions. A comparison needs criteria, verdict, evidence, tradeoffs, and audience fit. Keep headings provisional until research clarifies the material. The outline should define logical coverage, not serve as decorative furniture the evidence must squeeze around.

**How do I specify tone without vague adjectives?**

Translate tone into observable behaviors: define terms on first use, prefer concrete verbs, use second person in instructions, limit asides, state uncertainty, avoid hype, and never joke across identified care boundaries. Provide a short approved excerpt and explain what it does well when voice matching matters. “Friendly, expert, and engaging” alone does not tell a writer how sentences, evidence, humor, or reader address should work.

**What acceptance criteria should an editorial brief include?**

Use yes-or-no checks tied to the assignment: the opening answers the question, every required section delivers its outcome, time-sensitive claims are current and sourced, arithmetic reconciles, examples work, links resolve, metadata matches the body, care requirements are met, and files follow the delivery format. Add article-type tests such as doneness for recipes, runnable code for tutorials, or criteria and drawbacks for commercial comparisons.


---