How to Write an Explainer People Finish Reading Guide (2026)

Most explainers don’t fail because the reporting was thin or the prose was ugly. They fail because a reader gets to the 40% mark and can’t tell what’s coming next, and quietly closes the tab. Fixing that is mostly structural, and structure is checkable. Here’s the short version of how to write an explainer people finish reading: name one question the reader already has, answer it in the first screen, build a visible trail of subheads, and cut anything that doesn’t advance the answer. Everything below is a workflow you can run on a draft tomorrow morning.

I work on a data journalism desk, and the pattern is consistent enough to write down. The pieces that get read to the end are not the longest ones and not the cleverest ones. They’re the ones where the reader can always tell what question is being answered, where in the article they are, and what’s coming next.

That is a solvable problem, not a taste problem. The rest of this guide lays out the workflow we use: what to gather before you draft, the seven steps of the Finish-Line Framework, the mistakes that quietly cost you readers, and a sign-off list an editor can actually run.

What You Need

Before you write a word, you need six things. Most failed explainers were missing the first one, and no amount of editing repairs that later.

A single question, phrased the way a reader would say it. “What changed in the eviction rules and who it affects” works. “Eviction policy” does not. If you can’t write the question in one sentence without an “and,” you have two pieces, and both will suffer.

A named reader. Not “the public.” A working parent applying for housing assistance, a small-city council member, a first-year data reporter. The narrower the reader, the less background you have to explain, because you can stop guessing what they already know.

A one-sentence promise. What will the reader be able to explain, decide, or do after the last paragraph? Write that sentence before you write the article, not after. It’s the sentence your ending has to keep.

Three evidence anchors. One document or dataset, one named expert or official, and one concrete instance — a person’s situation, a company, a street. Three anchors are enough to write around; more can come in during drafting.

An answer-first outline. A two-column list: what the reader is wondering, and what you tell them. If a row has nothing in the second column, that section doesn’t earn its place. Practitioners in r/writing describe using exactly this two-column check on their own outlines before drafting, and it catches more dead weight than any later read-through.

A stop rule. Decide in advance what ends the piece. Usually it’s the last piece of context the reader needs to act, or the last step in a process. Without a stop rule, explainers ramble into a second and third act that only you find interesting.

Step-by-Step

The Finish-Line Framework has seven steps. Each one exists to prevent a specific drop-off point, and the table below is the whole thing at a glance — worth pinning above your desk while you work.

Step	What to do	Drop-off it prevents
1. Name the question	Write the reader’s question in their words, and put it in the headline or dek	The click that never becomes a read
2. Find the core idea	State the one thing the reader must understand, and say what’s at stake if they don’t	The piece that explains everything and means nothing
3. Map the explanation	Order context, definition, cause, examples, then implications — and cut what doesn’t advance them	Readers lost in the middle with no map
4. Open direct	Answer the question in the first three sentences, with a concrete example	The 10% bounce on the first screen
5. Write for momentum	Short paragraphs, one idea each, descriptive subheads, explicit transitions	Attention dying at the second heading
6. Add evidence in place	Put data, quotes and links where they answer something, translated into plain language	Evidence dumps the reader skims past
7. Edit and close	Run separate passes for clarity, structure and rhythm, then end on a next action	The ending that introduces a new idea and loses the finish

1. Choose a Question Readers Already Have

Start with a question that already exists in someone’s head, at the moment they need it answered. The best source is your own inbox, the comments on your last piece, or the search queries your own site receives. Readers don’t arrive wanting an article; they arrive with a question and a short window of patience.

Information scent is the trail of clues that tells a reader a useful answer is nearby. Headline, dek, subheads, the pull quote, the chart caption — together they form the scent. When a piece has no scent, the reader has no way to estimate the payoff, and the rational move is to leave.

Write the question, then write the headline as a promise about that question. Compare “Council votes 7-2 on new parking rules” with “The parking rules change in March, and here’s who gets an exemption.” Same information. The second one answers a question, so the reader knows what finishing buys them. Verbs like “explained,” “everything,” and “you need to know” tell a reader you plan to hand them a bundle rather than an answer; prefer “how,” “why,” “what changes,” and “who pays.”

How you know it worked: your headline can be restated as the reader’s question without editing, and a colleague can tell you what the piece promises after reading only the headline and dek.

2. Find the Core Idea and Show Why It Matters

Distill the topic into one sentence a reader could repeat to a friend. If your sentence has two clauses joined by “but,” you still have two ideas competing, and one of them is padding. This is sometimes called the nut graf — the paragraph that states what the piece is about and why it matters — and burying it is the single most common reason an explainer stalls.

The curiosity gap is the space between what the reader knows and what they want to know. Open a gap and readers lean in; close it early and politely and they leave, because the rest is confirming what they already suspected. A useful gap is honest: you promise to answer a real question, not a manufactured one.

Then spend a paragraph on stakes rather than context. Context paragraphs describe how we got here; stakes paragraphs describe what changes for the reader. “Three council members introduced the amendment in September” is context. “Under the old schedule, a family in the affected zone lost 40 minutes of bus service each way; under the new one, the 6:40 arrives four minutes earlier” is stakes. One is context the reader can skip; the other is why they can’t.

How you know it worked: you can state the core idea in a single sentence, and a test reader who read only that paragraph could explain what the piece argues.

3. Map the Explanation Before Writing

Explainer article structure is a sequence, not a mood. The reliable order is: what happened, what the terms mean, why it happened, what it looks like in practice, and what it means for the reader. Front-load the news and the definition, hold the nuance for later. A reader who gets the answer and leaves satisfied is a reader who will come back for the next one.

Progressive disclosure means holding the detail until the reader needs it. Most explainers reverse this, front-loading methodology and caveats the reader didn’t ask for, then rationing the payoff.

Now take your two-column outline and test each row. Three questions, in this order: does this row answer something the reader asked, does the next row depend on it, and could the reader skip it without breaking the next row? Any row that fails the first test and isn’t a load-bearing definition goes. A section that exists only to look thorough is where the mid-article drop-off lives.

How you know it worked: every heading in your outline can be written as a question a reader is holding, and no two headings ask the same thing.

4. Open With a Direct, Concrete Introduction

Answer the central question within the first three sentences, then spend the rest of the opening on the concrete detail that makes it real. Writers consistently report in r/writing that the first paragraph gets rewritten dozens of times, and that the versions that survive deliver the point first and the nuance second. That’s a small consensus, but it’s a useful one.

Here’s a weak opening, in the style of a lot of published explainers: “With housing costs continuing to rise across the region, and following several years of policy discussion, policymakers have increasingly turned their attention to a range of measures aimed at addressing affordability.” Nothing in that sentence is wrong, and it tells a reader nothing they can use. Four clauses, no named rule, no date, no person.

Same story, rebuilt: “A council vote on Tuesday night changed how long roughly 4,000 renters in the south district can expect to wait for a housing inspection. The old rule capped the queue at 30 days. The new one lets it run to 90.” The question is answered, the scope is stated, and the specific number gives the reader something to hold.

The second version also has a curiosity gap: 90 days is alarming, and the reader wants to know what happens in that gap. Give them the answer within a screen or two, or they’ll assume you buried it. If the explanation needs three steps, say in sentence four that it takes three and what they are. Promising a count and delivering that count is one of the cheapest retention tricks available.

This is the part of how to write an explainer people finish reading that most drafts get wrong, and it is the cheapest fix available. How you know it worked: the first three sentences contain the answer, a number or a name, and no throat-clearing about what the piece will cover.

5. Write for Momentum and Reader Memory

Readers hold a few chunks at once, not a page of connected prose. Write to that limit. One idea per paragraph, two to four sentences per paragraph, a new idea every paragraph. The practical test is the second draft rule: if a paragraph can be deleted without breaking the next one, it should be, or it should be merged with its neighbour.

Subheads do the load-bearing work. Use descriptive subheads that promise something — “What the 90-day cap changes for applicants” beats “The new rules.” Every subhead is a decision point where a reader decides to keep going, and vague ones give them permission to stop. Most pieces that fall apart around 60% have subheads that summarise a section rather than argue a point.

Signposting means telling the reader where they are. “Three things change in March” followed by a section that delivers three things is signposting. It costs one clause and it removes the anxious feeling that the piece is wandering.

Vary sentence length deliberately. A stack of 25-word sentences reads as monotone and gets skimmed; a few short ones — under ten words — land as emphasis and reset attention. A transition sentence that names the relationship between two ideas (“That delay matters because the appeal window is 14 days”) does more for flow than any amount of stylistic polish. Delete throat-clearing openers such as “that said,” “it’s worth noting,” and “in addition”; each costs a reader a beat and gives them nothing in return.

How you know it worked: read only the subheads in order. If you can reconstruct the argument, the trail works. If the headings feel like a list of topics, rewrite them.

6. Add Evidence Without Breaking the Flow

Evidence earns its place by answering a question or proving a claim. If a statistic appears and the next sentence doesn’t say why anyone should care, it is decoration. Put each piece of evidence next to the claim it supports, and translate it immediately: the raw figure goes in the chart or the callout, the plain-language reading goes in the sentence.

“Forty-two per cent of the city’s housing stock is more than 30 years old” means little on its own. “Nearly half the housing stock is more than 30 years old, which is why the inspection rules are the part that bites first” means something. Same fact, and the second version tells the reader what to do with it.

Quotations do the same job. Cut any quote where the speaker is restating what you just said in words you’d never use, and keep the ones with a specific detail, a flat disagreement, or a moment of hesitation. In our field, an annotated screenshot or a simple diagram often does more work than three paragraphs of description, and a recurring piece of practitioner advice is that a story you cannot illustrate usually has an argument you have not finished working out yet.

How you know it worked: every chart, quote, and link sits next to the sentence it supports, and could be lifted out without leaving a dangling reference.

7. Edit for Clarity, Interest, and Completion

Don’t edit everything at once. Run separate passes, in this order: comprehension, structure, repetition, rhythm, then the ending. A single read-through tries to do all five and usually fixes none.

The comprehension pass hunts jargon. Define a term on first use, in plain words, and never make the reader come back for it. The structure pass checks one thing: can any section be moved without breaking something later, and if so, is the current order the one that answers questions fastest? The repetition pass is where less experienced writers panic, but repeating a key fact three times in a long piece is not a flaw. It’s how a piece survives being skimmed, read on a phone, and opened in a newsletter where the top is cut off.

The rhythm pass is read aloud. Sentences you stumble over are too long or badly ordered. The final pass is the ending, and the rule is simple: do not introduce anything new. Summaries confirm what the reader already has; they don’t land well. Close on a next action or a decision the reader now faces, and let the last line be the sharpest one in the piece. If you promised a three-step answer in the opening, the close should name all three.

A quick note on AI-assisted drafts, which now show up in a lot of newsroom pipelines: the tells are uniform paragraph lengths, a fondness for tricolon lists, and explanations that arrive before the concrete instance. Fix them by cutting the summary sentence that restates the previous paragraph, putting an example ahead of the abstraction, and deleting every hedge phrase. AI-drafted explainers don’t fail because the facts are wrong; they fail because readers can feel the shape of them.

How you know it worked: a colleague reads the piece and, unprompted, describes the ending in one sentence that matches your promise from the opening.

Common Mistakes

The delayed answer. Burying the point until paragraph six because it “needs context.” The reader leaves with the context and never returns for the point. Fix: answer in the first three sentences, then earn the nuance you wanted to lead with.

Background as a hobby. History that serves the writer’s enjoyment more than the reader’s question. Test every context paragraph with a simple question: does the reader need this to understand what comes next? If not, cut it or move it to a linked sidebar that the interested reader can open.

Topic headings pretending to be arguments. “Background,” “Analysis,” “Conclusion.” These force the reader to hold the whole structure in their head to know why they’re still reading. Fix: rewrite each subhead as a claim. “Background” becomes “The shortage predates the current council.”

Jargon used as shorthand for expertise. Fix: define the term in the sentence where it appears, then use the plain version for the rest of the piece. If the plain version is harder to write, the explanation is probably not finished.

Transitions that only name time. “Next, let’s look at the numbers.” Fix: name the relationship instead — why the numbers matter, what they settle, what they leave open.

Unsupported claims. “Renters felt abandoned” tells the reader you surveyed the mood of renters. Either show a source or narrow the sentence to what you can support. On a standards desk this is a rejection issue, not a style note.

An ending that opens a new door. Fix: cut the final section that introduces a fresh argument, and move anything genuinely new into a linked piece. One ending per article, and it should resolve the promise made in the first screen.

Ignoring where readers actually leave. If you’ve published three explainers and none of them improved, the fix is in the data, not the draft. Find the drop-off point first.

Scroll-depth audit. Open your analytics and set up a scroll-depth or read-through report for the piece. Look for the steepest single drop, and match its percentage to your outline.

1. Top of page (0 to 20%). A cliff here is a headline or opening problem. The reader never got the answer.
2. Just past the nut graf (20 to 35%). A drop here usually means the first section ran long after the payoff, or a chart arrived with no explanation.
3. Mid-article (50 to 65%). The classic wall. Look for a section that repeats earlier material or a wall of quotes with no signposting.
4. Before the end (90 to 100%). Readers reached the finish and didn’t log it. Check for a paywall scroll, a video autoplay, or a broken embed before blaming the writing.

Time on page and completion rate are the two numbers worth arguing about in an editorial meeting. Pageviews tell you how many people arrived; neither of them tells you whether the explanation worked. Compare pieces built with the framework against pieces built without it, same section, same traffic source, and look at the shape of the curve rather than a single aggregate.

Newsroom QA checklist before sign-off. Run this on a printout, not a screen, and it takes about ten minutes: Does the first three sentences answer the question? Is there a number, a name, and a date in the first screen? Can someone who reads only the subheads reconstruct the argument? Does every chart have a caption that says why it matters? Is every term defined on first use? Do the paragraph lengths vary? Does the ending resolve the opening promise without introducing anything new? Is there a clear next action for the reader? If any answer is no, fix it before the piece goes to the desk.

Frequently Asked Questions

Conclusion

A finished explainer feels simple to read, which is exactly what makes it hard to write. The craft of how to write an explainer people finish reading comes down to three moves: name one question in the reader’s own words, map the answer in a two-column outline, and cut every section that doesn’t advance it.

Then edit in passes and run the QA list before you send it. If you do only one thing this week, rewrite the first three sentences of your last published piece and see what happens to the curve.