Chapter 28: Blog Posts, Articles, and Science Communication: Explaining Technical Concepts to Everyone

"Find a story. Tell that story. The numbers will follow." — Randy Olson, Houston, We Have a Narrative (2015)

Chapter Overview

Here is the same churn finding you have followed since Chapter 2, written for the last reader on its journey. To her VP, Dana Whitfield wrote a recommendation memo: shift retention budget into week-one onboarding. To her analyst peer, she wrote the full apparatus: random forest, cross-validation, partial-dependence past day 14. Now imagine her company's blog wants a post on what the data team learned, aimed at customers, prospects, and curious strangers who will arrive from a search result, give the page eight seconds, and leave the instant they're bored. This reader is not paid to read Dana's writing. They owe her nothing. There is no "Results" section they're obligated to reach, no manager forwarding the memo with "please review." If the first sentence doesn't earn the second, there is no second. That is the audience of this chapter, and it is the hardest one in the book.

This is science communication: explaining a technical idea to people who don't share your training and didn't ask for a lecture. It runs from the company engineering blog to the popular-science magazine to the explainer thread that makes a research paper go viral. The skill matters more every year, because the gap between what experts know and what the public understands is now a civic problem, not just a marketing one—climate, vaccines, algorithms, money, security. Someone has to stand in that gap and explain. The someone is increasingly you: the engineer who can write, the scientist who can hold an audience, the analyst who can turn a model into a story. The whole book has pointed here. Chapter 2 (Audience) gave you the curse of knowledge and the four-reader spectrum—public sat at the far end. Chapter 3 (Clarity) taught you to cut jargon and bloat. Chapter 7 (Word Choice, Tone, and Voice) taught you to set register on purpose. This chapter takes all three to their limit, for the reader who is the furthest from you it is possible to be.

The center of that skill is one tool, used more in science communication than anywhere else in technical writing: the analogy. An analogy borrows something the reader already understands to explain something they don't—and it is the single highest-leverage move you have, because it lets you explain a concept without first teaching the vocabulary the concept usually requires. It is also dangerous, because every analogy is wrong somewhere, and an analogy you don't control will mislead a reader who trusts it. By the end of this chapter you will be able to build an analogy that carries real explanatory weight, find the exact place it breaks, and flag that break before it costs you; set and hold a jargon budget of two or three terms per article; open with a hook that creates curiosity instead of demanding patience; structure a piece as a story rather than a study; and pitch the result to a publication. The finding stays the same. The audience has moved as far from the VP as it can go.

In this chapter, you will learn to:

• Build an analogy by mapping a familiar source onto an unfamiliar target—and find and flag the point where the mapping breaks down.
• Set a jargon budget of two or three technical terms per article, and decide for every other term whether to keep, replace, or cut it.
• Write an opening hook that opens a curiosity gap—using a scene, a surprising fact, a question, or the stakes—instead of opening with background.
• Structure a popular article as a narrative (hook → tension → payoff), and say why IMRaD, which served you in Chapter 13, fails this reader.
• Apply the SEO basics—title, meta description, descriptive headers—that this very book uses, and pitch a finished piece to a publication.

📗 Software/Data track: The company engineering blog, the launch post, the "how we built it" writeup—these are science communication, and they're how your work reaches users and how your reputation reaches your industry. The analogy (§28.2), the jargon budget (§28.3), and SEO (§28.7) are your core sections; the Dana blog-post rebuild in §28.6 is the chapter's spine. 📘 Business/Professional track: Thought-leadership posts, the explainer your CEO publishes under their name, the article that positions your company as the expert—all of it lives here. Read the hook (§28.4), narrative structure (§28.5), and the pitch (§28.8) closely; these are how a business earns authority in public.

28.1 The General Audience: Who You're Really Writing For

Every chapter in this book has insisted on one question before any other: who is the reader, and what do they have to do? For science communication, the answer has a feature no other audience in the book shares, and it changes everything downstream. So name it first.

The general reader is unobligated. Your manager has to read your memo. Your professor has to grade your paper. The developer using your API has to read your docs to get unstuck. Every audience so far has had a reason to push through writing that isn't quite working—a paycheck, a grade, a problem they need solved. The general reader has none of that. They clicked a link, or a friend sent them a thread, or they're idling on a magazine's homepage. They will give you a few seconds to prove the piece is worth their time, and if you spend those seconds on throat-clearing—background, definitions, "in this article we will explore"—they're gone, and you will never know they were there. The bounce is silent.

That single fact—the reader can leave at no cost, at any moment—is the discipline of this whole chapter. It is why the hook can't wait (§28.4). It is why the jargon budget is so tight (§28.3): every unexplained term is an exit. It is why you lead with a story, not a study (§28.5): the story creates a reason to keep reading where the study assumes one. Everything technical writing usually gets to take for granted—a reader who will stay—is gone, and the techniques here are what you use to earn the reader, sentence by sentence, instead of assuming them.

The second feature is the one Chapter 2 already named, now at maximum strength: the curse of knowledge is most dangerous here. When you write for a peer, the gap between your knowledge and theirs is small, so the words you forget to define mostly land anyway. When you write for the public, the gap is enormous, and every term that's invisible to you—every "endpoint," "p-value," "cohort," "latency"—is a wall to them. You cannot feel these walls, because you can't un-know what they mean. So, exactly as in Chapter 2, you defeat the curse with mechanics, not willpower: list your terms, test on a real non-expert, and—the move that does the most work and is unique to this chapter—reach for an analogy instead of a definition wherever you can.

Before going further, let's be precise about what "general audience" is not, because the phrase invites two mistakes.

It is not "stupid." This is the cardinal sin of science communication, and readers smell it instantly. A general reader is not less intelligent than you; they are less trained in your specialty. A cardiac surgeon is a general reader for a blog post about compiler design, and you would not write down to her—you'd just spare her the jargon she has no reason to know. "Translate, don't dumb down" (Chapter 2, Chapter 7) is the whole posture: you keep the real idea and change the vocabulary, never gut the idea and condescend. Condescension and clarity are opposites, not cousins.

It is not one person. "The general public" is a convenient fiction; in practice you write for a specific slice of it—the readers of this magazine, the customers of this product, the people who searched this phrase. A piece for a science-curious Quanta reader can assume more than a piece for a local newspaper. So even here, you do the Chapter 2 work: picture an actual representative reader (Chapter 2's "smart friend"), and write to them. "Everyone" is not a target; a particular curious non-specialist is.

🔄 Check Your Understanding A colleague says: "I write for a general audience, so I keep it simple—I just leave out anything complicated." What's wrong with that approach, and what should they do instead?

Answer

"Leave out anything complicated" confuses simplifying the vocabulary with removing the idea—the dumbing-down trap. If you cut every complicated thing, you've cut the actual content, and the reader leaves having learned nothing worth their time. The fix is to keep the complicated idea and make it accessible: explain it with an analogy, ground it in a concrete example, spend your jargon budget on the one term you truly need. "Translate, don't dumb down" (Chapter 2). The skill isn't omitting the hard part; it's making the hard part land.

28.2 The Analogy: The Fundamental Tool of Science Communication

Here is a concept most people have never studied, explained in one sentence with no technical vocabulary: A blockchain is a shared notebook that everyone can read and write in, but no one can erase—so once something's written down, everyone agrees it happened. You now understand the single most important property of a blockchain (an append-only, distributed, tamper-evident ledger), and you understand it without my having used any of the four jargon terms in the parenthetical. That is the power of an analogy, and it is the reason this section sits at the center of the chapter.

An analogy explains an unfamiliar thing (the target) by mapping it onto a familiar thing (the source). The source is something already in the reader's head—a notebook, a traffic jam, a library, a thermostat, a queue at a coffee shop. The analogy says: the new thing works like this thing you already know. Done well, it does something no definition can: it lets the reader understand a concept before learning the concept's vocabulary, by borrowing structure they already possess. A definition gives the reader a new entry to memorize. An analogy gives them a place to put the new idea, attached to something they'll never forget because they already knew it.

Watch the move turn a wall of jargon into something a stranger grasps in one read. Here is Dana's churn finding, stated for an expert:

❌ Before (for a peer; opaque to the public): "Time-to-first-value is the dominant predictor of 90-day churn: accounts that fail to reach an activation event within the onboarding window exhibit a 7× hazard ratio relative to rapidly-activating cohorts, controlling for plan tier."

✅ After (the same finding, one analogy): "Signing up for a new app is like the first day at a gym. If someone shows you around, you try a machine, and you leave having actually done something, you come back. If you wander in, can't figure out the lockers, and leave without a workout, you quietly never return—and you blame yourself, not the gym. Our data says our customers are having that bad first day. The ones who get a real 'win' in their first week stick around; the ones who don't are seven times more likely to quit. The problem isn't our product. It's that first trip to the gym."

Why it's better: The "before" is precise and correct and, to a non-specialist, almost entirely opaque—"hazard ratio," "activation event," "cohorts," "controlling for plan tier" are four walls in two lines. The "after" uses one source the reader already owns (the first day at a gym) and maps the whole finding onto it: signing up = walking in, first value = a real workout, churn = quietly never returning, the seven-times multiplier survives intact because it's the one number worth keeping. The reader finishes understanding not just that onboarding matters but why it feels the way it does—the self-blame, the silent exit. No vocabulary was taught. The idea landed anyway. That is the analogy doing what only an analogy can.

How to build an analogy that works

A good analogy is not decoration you sprinkle on at the end. It's a structural choice you make deliberately, and it has to satisfy three tests.

1. The source must be genuinely familiar to this reader. The whole mechanism depends on the source already living in the reader's head, so it has to be common ground for your actual audience—not just for you. Explaining a database index by comparing it to "a B-tree's logarithmic lookup" fails: the source is as unfamiliar as the target. Comparing it to the index at the back of a book—you don't read every page to find "photosynthesis," you flip to the index and it tells you the page—succeeds, because every reader has used a book index. Choose sources from daily life: kitchens, traffic, mail, money, weather, queues, libraries. The more universal the source, the wider the analogy carries.

2. The mapping must hold for the part you care about. An analogy explains one relationship, and you should know exactly which one before you choose it. The gym analogy maps the first-experience-determines-retention relationship; that's the part that has to be faithful, and it is. You don't need the gym to resemble a software company in every respect—you need it to resemble it in the one way your point depends on. Pick the source whose structure matches the specific relationship you're explaining, not the source that's merely in the same general neighborhood.

3. The reader must be able to reason with it, not just nod at it. The best analogies don't only illustrate the idea you state—they let the reader extend it correctly on their own. Once you've said onboarding is the gym's first day, the reader can infer, unprompted, that a friendly trainer (a guided setup) would help and that a confusing locker room (a cluttered signup) would hurt. The analogy has handed them a little engine for thinking about your domain. That's the gold standard: an analogy the reader can run, not just receive.

🧩 Productive Struggle Before you read the next part, try building one. You need to explain caching (storing the results of expensive work so you don't have to redo it) to a general reader. Don't write a paragraph—just pick a source: one everyday thing that has the same structure (you do something costly once, then reuse the result instead of redoing it). Then ask yourself: where would that source break as an explanation of caching?

Discussion

Good sources: keeping leftovers (cook once, reheat for days instead of cooking again); a phone's recently-called list (the numbers you use most, kept one tap away instead of searched for each time); memorizing your commute (you don't re-derive the route every morning). Each captures the core relationship—expensive-once, cheap-thereafter. Now the break: leftovers spoil, which is actually a feature of the analogy, because cached data goes "stale" too and has to be thrown out and refreshed—a rare case where the break teaches the next concept (cache invalidation). The recently-called list breaks differently: it has no notion of staleness, so it explains the "fast reuse" half but not the "the answer can go out of date" half. The point of this struggle: you can't pick a good analogy until you know which relationship you're explaining and where the source stops matching—which is the whole next section.

[📍 Good stopping point]

28.3 Where Analogies Break: The Most Important Skill in This Chapter

Every analogy is wrong. That is not a flaw to apologize for; it's the definition. An analogy works precisely because the source is not the target—if it were identical, it wouldn't be an analogy, it would be the thing itself. The source matches the target in the one relationship you care about and diverges everywhere else, and the art is knowing exactly where the match ends. A science communicator who can't find the break in their own analogy is holding a loaded tool by the barrel.

Here is why the break matters so much: a reader trusts an analogy further than you intend it to go. You offer the gym to explain onboarding's effect on retention. The reader, reasoning with the analogy as good analogies invite, may extend it to a place you never meant—"so we should make customers sweat? add friction so they feel they earned it?"—and now your analogy is generating false conclusions in their head, with your authority behind them. The reader can't see the break, because they don't know the target; only you know where the source stops matching. If you don't mark the edge, the reader will walk off it.

So the skill, stated as a rule you can apply every time: find where your analogy breaks, decide whether the break matters for your point, and if it does, name it before the reader hits it.

Watch it on a famous, genuinely useful analogy: the atom is like a tiny solar system—electrons orbit the nucleus the way planets orbit the sun. This is one of the most successful science analogies ever; it correctly conveys a small dense center with lighter things arranged around it, held by an attractive force. It is also wrong in ways that matter the moment a reader reasons with it.

The analogy: "An atom is like a tiny solar system—a heavy nucleus at the center, with electrons orbiting around it like planets around the sun."

Where it breaks (and whether it matters): - Electrons don't travel on fixed paths like planets; they exist in fuzzy probability "clouds." (Matters a lot if your point is about quantum behavior; matters little if your point is just "small center, lighter things around it.") - The solar system is mostly held by gravity; the atom by electromagnetism. (Matters if the reader will reason about the force; otherwise a footnote.) - Planets could orbit at any distance; electrons can only occupy specific energy levels. (Matters enormously if your next paragraph is about why atoms emit specific colors of light.)

The move in practice: if your article is a casual "what is an atom," you might use the solar-system analogy and add one sentence—"though unlike planets, electrons don't really travel on neat little tracks; think of them more as a blur around the center." You've named the break that matters and waved off the rest. If your article is about why neon signs glow a specific color, the solar-system analogy is the wrong tool entirely, because the break (fixed energy levels) is the exact thing you need to explain—so you'd choose a different source (rungs on a ladder: you can stand on a rung or the next one, but never in between). The break determines whether the analogy is right for the job. An analogy whose break sits right on top of your main point is not a good analogy for that point, no matter how vivid.

This gives you a clean two-step you can run on any analogy you're considering:

1. List where the source and target diverge. Name three ways the gym is not a software company, three ways the atom is not a solar system. You'll almost always find them fast once you look.
2. Ask whether any divergence sits on your point. If the break is off to the side (the gym has a smoothie bar; irrelevant), the analogy is safe—use it, maybe with a light wave at the edge. If the break is load-bearing for what you're explaining, either flag it explicitly or pick a different source.

🔍 Why Does This Work? Why is naming the break more persuasive, not less—why doesn't admitting "this analogy isn't perfect" undermine your authority? Think about what the reader concludes about a writer who flags their own analogy's limits, then read on.

Answer

Because flagging the break signals expertise and honesty at once, and both build trust. A writer who says "the solar-system picture is useful but electrons don't really orbit on tracks" demonstrates that they understand the target deeply enough to see past their own simplification—that's the mark of someone who actually knows the material, not someone parroting a cliché. It also pre-empts the smart reader's objection: the moment a knowledgeable reader thinks "but that's not quite right," you've already said so, which converts a potential credibility hit into a credibility gain. (This is the calibrated-certainty move from Chapter 7—matching your stated confidence to reality—applied to analogies: claim what the analogy gets right, disclaim what it gets wrong.) An unflagged analogy that a reader catches breaking looks like ignorance; a flagged one looks like mastery. Same analogy; opposite effect on trust.

🚪 Threshold Concept: An analogy is a loan, not a gift. Before this section, you probably thought of a good analogy as a clean win—find the right comparison and the explaining is done. After it, you should see every analogy as a loan against the reader's existing understanding: it borrows the structure of something they know to explain something they don't, and like any loan, it comes due. The interest is the break—the places where the source doesn't match, which the reader will discover by reasoning with it. A skilled communicator doesn't avoid the loan (it's the most powerful tool they have); they manage it: take only as much as the point needs, and disclose the cost (the break) before the reader trips over it. Once you cross this threshold, you stop asking "is this a good analogy?" and start asking "what does this analogy get wrong, and does that wrongness sit on my point?"—and you'll never again deploy a comparison without first locating its edge.

28.4 Opening Hooks: Creating Curiosity in the First Two Sentences

Recall the reader from §28.1: unobligated, impatient, one click from gone. That reader hands you exactly one resource at the start—a few seconds of attention—and the opening hook is how you convert it into a few more. The job of the first sentence is not to introduce the topic. It is to make the second sentence unskippable. The job of the second is to do the same for the third. A hook that merely announces what the article is about ("This post explains how machine learning models can drift over time") has told the reader the topic and given them no reason to keep reading—they now know enough to decide they're not interested.

The mechanism a hook exploits has a name worth knowing: the curiosity gap. People feel a small, almost physical itch to close a gap between what they know and what they sense they're about to find out. A good hook opens that gap—poses a question the reader now needs answered, states a fact that doesn't fit their model of the world, drops them into a scene whose ending they have to know. The rest of the article closes the gap. The whole transaction is: open a loop in the first two sentences, and the reader stays to see it closed.

Compare the two ways Dana's blog post could begin.

❌ Before (topic announcement, no gap): "Customer churn is an important metric for subscription businesses. In this post, we'll share what our data team learned about the factors that drive churn and what we're doing about it."

✅ After (a curiosity gap): "Most of the customers who quit our product never complained. They didn't email support, didn't leave a bad review, didn't rage-quit. They just… stopped showing up, usually within their first three weeks—and we had no idea why. So we went looking. What we found surprised us: the problem wasn't anywhere we'd been looking for it."

Why it's better: The "before" names the topic (churn) and previews the structure ("in this post we'll share")—two of the deadest openings in writing, because they ask the reader to care about a subject before giving them any reason to. The "after" opens three loops in five sentences: who are these silent quitters? why didn't they complain? what surprised the team and where had they been wrong? Each is a small gap the reader now wants closed, and the only way to close it is to keep reading. Notice it also withholds the finding—it promises a surprise and makes you read on to collect it. That's the engine of the hook: a question you've planted that the reader needs you to answer.

You have four reliable openers. None is universally best; each fits a different piece.

The scene. Drop the reader into a specific moment, concretely rendered. "At 11:38 p.m. on January 27, 1986, an engineer named Roger Boisjoly sent a memo he hoped no one would ever need." A scene works because humans are wired for narrative—we lean in to find out what happens. Use it when your topic has a moment, a person, a story attached.

The surprising fact. State something true that contradicts what the reader assumes. "The most dangerous part of flying isn't turbulence, takeoff, or landing. It's a clipboard." The fact creates the gap—the reader's model of the world just cracked, and they need you to repair it. Use it when your topic contains a genuine counterintuition.

The question. Ask something the reader can't answer but now wants to. "Why do some new customers stick around for years while others vanish in a week—even though they bought the exact same thing?" A real question (not a rhetorical one with an obvious answer) plants the gap directly. Use it when the question itself is intriguing and the reader can feel its pull.

The stakes. Make the reader feel why this matters to them, fast. "If you've ever wondered whether the password you reuse on six sites is actually a problem, here's the uncomfortable math." Stakes work when the topic touches the reader's own life, money, safety, or curiosity. Use it to convert "why should I care" into "oh—this is about me."

⚠️ Warning: A hook writes a check the article must cash. If your surprising fact is hype ("Scientists have discovered the secret to immortality"—they have not), or your question is answered with a shrug, or your scene has nothing to do with the payoff, you've spent the reader's trust on a bait-and-switch, and they'll bounce harder than if you'd never hooked them—and remember you next time as the writer who wasted them. This is the clickbait failure: a hook with no honest payoff. The gap you open must be a gap you genuinely close. (We'll meet this again as an ethics question in Chapter 38: clear, compelling writing in service of an empty or false claim is a misuse of the skill.)

✏️ Try This Take this flat opening and rewrite it as a hook using any of the four openers: "This article explains how vaccines train the immune system to recognize pathogens." Write two sentences that open a curiosity gap.

One possible answer

Surprising-fact opener: "Your immune system fights most battles against an enemy it has never met—and usually wins on the first try. A vaccine is how we let it cheat: a chance to study the enemy's face before the real fight ever starts." It opens a gap (how does it win against something it's never met? what does "cheat" mean here?) and previews the analogy (studying the enemy's face) without yet explaining the mechanism. Compare to the original, which announces the topic and gives the reader nothing to wonder about. A question opener would also work: "How does your body know how to fight a virus it has never encountered? The answer is the reason vaccines exist."

🔄 Check Your Understanding Why does "In this post, we will explore the topic of X" fail as an opening, in terms of the curiosity gap?

Answer

It closes the gap instead of opening one. By announcing the topic ("the topic of X") and the structure ("we will explore"), it tells the reader everything they need to decide whether to care—and gives them no unanswered question pulling them forward. There's no loop, no itch, nothing withheld. The reader can fully predict what's coming, so there's no reason to keep reading. A hook must leave the reader needing something the next sentences supply; a topic announcement supplies the prediction up front and kills the need.

28.5 Narrative Structure: Why a Story Beats a Study

In Chapter 13 you learned IMRaD—Introduction, Methods, Results, Discussion—the structure of the lab report and the research paper. It is an excellent structure for its reader: a fellow specialist who wants to verify your work and reuse it, and who will read Methods before trusting Results. For the general reader, IMRaD is close to the worst possible structure, and understanding why is the key to writing for them.

IMRaD front-loads the apparatus. It opens with background and method—exactly the material the unobligated reader has the least patience for and the least ability to evaluate. It saves the "so what" for the Discussion, at the very end, where the general reader will never arrive because they left during Methods. It is built for a reader who has to finish; the general reader has to be made to finish, and IMRaD gives them every reason not to. (This is the same lesson as Dana's method-first memo in Chapter 27—lead with the apparatus and the busy reader is gone—pushed to its extreme, because the blog reader is even less obligated than the VP.)

What replaces it is narrative structure: the shape of a story, not a study. At its simplest, three beats.

1. The hook (tension). Open a question, a problem, a surprise—a gap the reader needs closed (§28.4). This is the story's inciting incident: something is unresolved, and the reader wants the resolution. "Most of our customers who quit never complained—they just vanished, and we didn't know why."

2. The journey (rising action). Take the reader along as the tension builds toward resolution—but as a story, with them beside you, not as a methods dump. "So we pulled every cancellation and started looking for a pattern. At first we suspected price. Then we suspected the product. Both were dead ends. Then someone noticed something about when people quit…" The method is in there—the reader learns you looked at cancellation data and ruled out alternatives—but it arrives as plot, as a search with false leads and a turn, which is how humans are built to absorb information. You are not hiding the rigor; you are narrating it.

3. The payoff (resolution). Close the gap you opened. Deliver the finding as the answer the whole piece has been driving toward, and—because this is communication, not just storytelling—land what it means. "The pattern was the first week. Customers who got a real win early stayed; the ones who drifted, quietly quit. We'd been trying to win customers back at renewal, a year too late. The fight was week one all along."

The difference between this and IMRaD is not that the story has less substance. It's the order and the frame: narrative leads with tension and resolves it, where IMRaD leads with apparatus and saves the meaning for readers who reach the end. Same facts; the structure that matches how the reader reads.

The same content, two structures:

	IMRaD (for the specialist)	Narrative (for everyone)
Opens with	Background, prior work, method	A hook—tension, a question, a surprise
Middle	Methods, then Results	The journey to the answer, with false leads
The "so what"	Last, in the Discussion	Threaded throughout and landed at the payoff
Assumes the reader	Must finish (paid, graded, professional)	Can leave at any second, owes you nothing
Fails when	Read by an impatient non-specialist	Used to report verifiable science to peers

Two practical pieces of the narrative toolkit, borrowed from journalism, are worth naming because you'll use them constantly.

The lede (journalists spell it that way to distinguish it from the metal "lead") is your opening—the hook, the first beat that sets the tension. "Don't bury the lede" means: don't make the reader dig past throat-clearing to find the interesting part. Your lede is the hook of §28.4.

The nut graf (newsroom slang for the "nutshell paragraph") is the short passage, usually just after the lede, that tells the reader why this story matters and what it's about—the bridge from the hook's specific scene to the broader point. After the gym anecdote or the "silent quitters" hook, the nut graf is the sentence or two that says: this is a post about why companies lose customers in the first week, and what the data says to do about it. The lede grabs; the nut graf orients. Together they get a reader from "huh, interesting" to "ah, I see why I'm reading this" without ever stalling on background.

🔄 Check Your Understanding You're writing a popular article about a genuine research finding. A colleague insists you "be rigorous" and lead with your methodology so readers can trust the result. In one or two sentences, explain why this advice, though well-meant, will lose your general audience—and what to do with the methodology instead.

Answer

Leading with methodology front-loads the apparatus the general reader has the least patience for and can't evaluate anyway, so they'll leave during the method section and never reach the finding—the IMRaD failure, the same one Dana's method-first memo committed in Chapter 27. The fix isn't to hide the method (that would be dishonest); it's to narrate it—weave it into the journey ("we suspected price, then the product, both dead ends, then we noticed…") so the reader absorbs the rigor as plot, and lead instead with the hook. Rigor and a hook aren't in tension; rigor delivered as a story is what keeps a non-specialist reading.

[📍 Good stopping point]

28.6 The Centerpiece: Dana's Finding as a Blog Post

Now we put every tool in one place, on the finding you've followed across three audiences. To the VP, Dana led with the recommendation. To her peer, she led with the method. To the public, she leads with a story—and we'll build the post in stages so you can watch each technique do its job.

First, the version a smart engineer writes when they're told "write a blog post about the churn project" and reach for the structure they know—the research structure.

❌ Version 1 — The "study," posted to a blog (fails the general reader):

What We Learned About Customer Churn

Customer retention is a critical metric for any subscription business. In this post, we describe an analysis our data team conducted to identify the drivers of early-stage churn. We extracted cancellation records across two quarters (n=4,812 new accounts) and applied a random-forest classifier to rank predictive features. Time-to-first-value emerged as the dominant predictor (ROC-AUC 0.81), with a steep relationship past approximately 14 days, robust to controls for plan tier. We conclude with recommendations for reducing churn through onboarding optimization.

Read it as a stranger who arrived from a search for "why do customers leave." It opens by telling them churn is important (they suspected as much, or they wouldn't have searched), then immediately drops into apparatus—extraction, n, random forest, ROC-AUC—and ends by promising recommendations it makes them read on to get. There is no hook, no gap, no analogy, and a jargon budget blown four times in two sentences. The stranger is gone before "ROC-AUC." It's not that the content is wrong; it's IMRaD aimed at a reader IMRaD was never built for.

Now the rebuild. Watch each technique enter.

✅ Version 2 — The same finding, as a story (lands the general reader):

The Customers Who Quietly Disappear

Most of the customers who quit our product never said a word. They didn't email support, didn't leave an angry review, didn't even cancel in a huff. They just… stopped showing up—usually within their first three weeks—and for a long time, we had no idea why. ← hook: a curiosity gap (the silent quitters)

If you've ever signed up for an app, used it twice, and never opened it again, you already understand this story from the inside. This is about why that happens, and what we found when we finally went looking. ← nut graf: orients the reader, pulls them into the story

Here's the thing we kept getting wrong. We assumed people left because of price, or because a competitor was better, or because the product was missing some feature. So that's where we looked. All dead ends. The customers who left weren't price-sensitive, and they weren't defecting to a rival—they were just gone. ← the journey: false leads, building tension

Then someone on the team noticed it wasn't about who the customers were. It was about when they quit. Almost all of them left in the same window: the first three weeks. And signing up for a new app, it turns out, is a lot like the first day at a gym. ← the turn, into the analogy

If someone shows you around, you try a few machines, and you leave having actually broken a sweat, you come back. But if you wander in, can't work the lockers, can't figure out the equipment, and leave without doing anything—you quietly never return. And you don't blame the gym. You blame yourself, and you find an excuse not to go back. ← the analogy: a source the reader owns

That's what was happening to our customers. The ones who got a real "win" in their first week—who actually did the thing the product is for—stuck around for years. The ones who didn't were seven times more likely to quit. Seven times. The product was fine. The price was fine. The problem was the first trip to the gym. ← the payoff: the finding, in the reader's units, the one number kept

Which means we'd been fixing the wrong thing. We'd poured effort into winning customers back at renewal time—a full year after they'd already mentally checked out. The fight was never at renewal. It was in week one, and we'd been showing up 51 weeks late. ← the "so what," landed

Look at what Version 2 spends and what it keeps. It spends its jargon budget on nothing—there isn't a single unexplained technical term; "time-to-first-value" became "a real win in their first week," "7× hazard ratio" became "seven times more likely to quit." It keeps the one number that matters (seven times) and drops every number that doesn't (n=4,812, ROC-AUC, day 14, the model type)—not because they're unimportant to the analysis, but because they're irrelevant to this reader, who needs to feel the finding, not audit it. The method is present as narrative—the reader learns the team looked at who left, ruled out price and competitors, and found a timing pattern—but it arrives as a search with dead ends, not a methods section. And the analogy carries the explanatory weight a definition would have spent three paragraphs failing to carry.

Two things Version 2 does not do, on purpose, are worth flagging.

It doesn't bury the rigor; it relocates it. A blog post like this should end with a short, low-key pointer for the reader who wants the apparatus: "(For the curious: this is from a model across two quarters of cancellation data; the technical writeup is here.)" One sentence, at the bottom, linking out. The general reader skips it; the technical reader who wandered in finds it. You serve the impatient majority without lying to the curious minority—the layering move from Chapter 27, applied to a blog.

It flags the analogy's edge if the piece pushes the gym further. This post uses the gym lightly and doesn't over-extend it, so a single sentence of hedging isn't strictly required—but if Dana went on to argue "so we should make onboarding effortless," she'd want to note that the gym breaks there: at a real gym, a little effort is the point, whereas for software you usually want to remove effort. The break (effort is good at the gym, bad in onboarding) sits right on a conclusion she might draw, so she'd name it. Watch your own analogies for exactly this: the moment you reason past the relationship the source faithfully maps, mark the edge.

🔄 Check Your Understanding In Version 2, the finding "seven times more likely to quit" appears, but "ROC-AUC 0.81," "n=4,812," and "random forest" do not. Both sets of numbers are true and were in Version 1. Why keep one and cut the others for this reader?

Answer

Because the reader's job determines which facts are load-bearing. The general reader needs to grasp the size and shape of the finding, and "seven times" does that in their units, memorably—it's the one number that conveys "this is huge." "ROC-AUC 0.81," "n=4,812," and "random forest" are about how confident to be in the model and how it was built—questions a peer auditing the work asks, and a general reader neither asks nor can evaluate. To this reader they're not precision; they're walls (the curse of knowledge, Chapter 2). Keeping them wouldn't make the post more honest—the honesty lives in the link to the full writeup—it would just make it unreadable. Keep the number that carries the meaning; demote the numbers that establish the rigor to where the rigor-seeking reader can find them.

28.7 SEO Basics: How Readers Find the Piece (the Techniques This Book Uses)

A blog post no one finds might as well not exist. The general reader rarely arrives because they were looking for you; they arrive because they searched for a thing, and a search engine decided your piece answers it. SEO—search engine optimization—is the set of writing choices that help the right reader find your work. It has a bad reputation, earned by people who keyword-stuff and game rankings, but the honest core of it is simply this: write so that a person searching for what you wrote about can find it. That's not manipulation; it's the same audience-service this whole book teaches, extended to the moment before the reader arrives.

And here's the proof that the honest version works: this textbook uses it. Every chapter's frontmatter carries an seo_description and a list of seo_queries; every chapter ends with a Frequently Asked Questions section; the headings are descriptive ("How to Build an Analogy That Works," not "Analogies"). Those aren't an afterthought bolted onto a writing book—they're a demonstration that good SEO and good writing are the same choices, made for the same reason: to connect a specific reader with the specific thing they need. Four moves carry almost all of it.

1. The title: promise the answer the reader searched for. Your title is the single most important SEO element and the single most important hook, at once—it's what appears in the search results and what determines whether anyone clicks. It should contain the words a reader would actually search and promise the thing they want. "The Customers Who Quietly Disappear" is a lovely literary title and a terrible search title—no one searches that. A reader wanting this content searches "why do customers churn in the first month" or "how to reduce early customer churn." So the winning move is often a title that does both: a searchable phrase plus a hook. "Why New Customers Quit in the First Month (and What Actually Fixes It)"—searchable ("why new customers quit," "first month") and intriguing (the parenthetical promise). Don't choose between findable and compelling; engineer a title that's both.

❌ Before (clever, unfindable): "The Silent Goodbye" ✅ After (findable and compelling): "Why New Customers Quit in the First Few Weeks — and How to Keep Them"

Why it's better: "The Silent Goodbye" is evocative but contains none of the words a reader searches, so the people who'd love this post never see it. The "after" leads with the exact phrase a searcher types ("why new customers quit"), includes the time frame they'd specify ("first few weeks"), and keeps a hook (the promise to fix it). It's findable and clickable—and findable-but-plain beats clever-but-invisible every time, because an unfound post has zero readers.

2. The meta description: the ad for the click. The meta description is the short snippet (keep it under ~155 characters) that appears beneath your title in search results. Search engines may not use it to rank you, but humans use it to decide—it's a tiny ad for your piece. Write it as one clear sentence that states what the reader will get and includes the main search phrase. It's the same skill as the seo_description in this chapter's frontmatter at the top of this file: a reader-facing promise, under 155 characters, containing the words they searched. (Go look at this chapter's frontmatter—that field is a meta description, written exactly this way.)

3. Descriptive headers: write headings someone could search. Search engines read your headings to understand your structure, and readers scan them to navigate—so a heading should describe its content in words a person would use. "How to Build an Analogy That Works" beats "Analogy Construction"; "Where Analogies Break" beats "Limitations." This is the same advice Chapter 4 (Structure) gave for the reader's sake—headings that signpost—now doing double duty for findability. The book practices it: scan this chapter's section titles and you'll see they're phrased as the questions and tasks a reader brings, not as one-word labels.

4. The FAQ: answer the questions people actually type. A Frequently Asked Questions section near the end—real reader questions as headings, with crisp answers—does three things at once: it helps the reader who skimmed and still has a question, it gives search engines clean question-and-answer pairs they often surface directly, and it forces you to articulate the questions your reader actually has. That's why every chapter of this book ends with one, including this chapter (just below). It is not filler; it is SEO and reader-service that happen to be the same move.

💡 Tip: The honest test for any SEO choice is: does this help the right reader find and choose my piece, or does it trick the wrong reader into clicking? Putting the searched phrase in your title: honest—it helps the right person find you. Stuffing twelve unrelated keywords into a wall of gray text, or a headline that promises what the article doesn't deliver: dishonest—it games the engine and wastes the reader. The first is audience service; the second is the clickbait failure (§28.4) wearing a technical hat. Optimize for the reader who should find you, never for raw traffic.

🔄 Check Your Understanding This chapter's own frontmatter contains seo_description and seo_queries fields and the chapter ends with an FAQ. In one sentence, what is the book demonstrating by carrying these, beyond just "ranking on Google"?

Answer

That good SEO and good writing are the same choices—serving a specific reader by helping them find and navigate the exact content they need—so a well-written piece is naturally findable, and "optimization" done honestly is just audience service extended to the moment before the reader arrives. The book models its own advice: it doesn't tell you to write findable, reader-serving pieces while itself being an undiscoverable wall of generic headings.

📐 Project Checkpoint

This chapter builds Portfolio Piece 7: the blog post explaining a technical concept to a general audience—the final piece of your seven, and the one that most directly tests whether you can do the thing the whole book is named for: take something you understand and make a stranger understand it too.

Where you are. You have carried a technical finding across the book—shaped into a data memo in Chapter 27 for a decision-maker. Now you take that same finding (or another technical concept you know well) to the furthest audience: the general public, who owes you nothing and will leave the instant you bore them.

This chapter's increment. Write a 600–900 word blog post explaining one technical concept or finding to a general audience. It must contain, and you should be able to point to, each of these:

1. A hook (§28.4) in the first two sentences that opens a curiosity gap—a scene, a surprising fact, a question, or the stakes. No "in this post, we will explore."
2. A nut graf just after the hook that orients the reader to what the piece is about and why it matters to them.
3. At least one analogy (§28.2) mapping a source the reader already owns onto your concept—and, if your point pushes past the relationship the source faithfully maps, one sentence flagging where the analogy breaks (§28.3).
4. A jargon budget of two or three terms, maximum (§28.3, applied): list every technical term in a first draft, then keep-and-define, replace, or cut each until you're within budget.
5. Narrative structure (§28.5): hook → journey → payoff, with the "so what" landed, not an IMRaD report in disguise.
6. A searchable, compelling title and a meta description under 155 characters (§28.7).

The test to apply to your own draft. Hand it to someone outside your field and watch where they slow down or glaze over—that's an unpaid jargon term or a broken analogy (the Chapter 2 "test on a real non-expert," now non-negotiable). Then check the hook alone: read them only the first two sentences and ask if they'd keep reading. If not, the hook announces instead of intrigues—rewrite it.

Self-assessment (rubric in exercises.md): Does the hook open a gap a reader needs closed? Is the jargon within budget, every kept term defined? Does the analogy map the right relationship, with the break flagged if it's load-bearing? Could a stranger finish the piece and explain the concept back to you?

Looking ahead. In Chapter 29 (Writing with AI), you'll learn to use a language model as a tool in producing writing like this—brainstorming analogies, drafting a hook, tightening prose—without letting it do the thinking that is the whole point. Keep this blog post; it's a good test case for what AI can and can't help with, because the hardest part of it—choosing the right analogy for your reader—is exactly the part a model can't do for you.

28.8 Pitching, Publishing, and the Science-Communication Career

Writing the piece is half the job; getting it in front of readers is the other half, and it has its own craft. Here's the practical and professional side, briefly—from "where does this go" to "could I do this for a living."

Where a piece can live. Venues run along a spectrum, and each shapes the writing. Your own blog or newsletter: total control, but you build the audience yourself. A company engineering or research blog: an existing audience, but the piece also serves the organization. A platform like Medium or a community like dev.to: built-in discovery, lower prestige. A trade publication in your field: a credible, targeted readership. A mainstream popular-science outlet (Scientific American, Quanta, Ars Technica, and their kin): the widest reach and the highest bar. As you move up that spectrum, the editing gets stricter, the jargon budget tighter, and the hook more essential—but the skills are the ones in this chapter, all the way up.

The pitch. For anything beyond your own blog, you usually don't write the piece and then submit it; you pitch it—a short email proposing the piece to an editor before you write it. A pitch is itself a piece of persuasive technical writing (Chapter 20's skills, Chapter 19's email discipline), and it lives or dies on the same things your article does: a hook and a clear "so what."

The anatomy of a pitch email (≈150–200 words): - Subject line: specific and intriguing, like a headline. "Pitch: why new customers quit in week one—and the gym-membership science behind it." - The hook (1–2 sentences): open with the story, not "I'd like to pitch an article." Lead with the most compelling thing about the piece—the same opening you'd use in the article. - The angle (2–3 sentences): what the piece argues, why it's new or timely, and—crucially—why it fits this publication's readers. (Editors reject generic pitches instantly; show you read their outlet.) - Why you (1 sentence): your credibility to write it—your expertise, access, or unique vantage. - The ask: a clear, low-friction next step. "Would a 1,200-word version be of interest? I can have a draft to you by the 15th."

❌ Before (a pitch that gets ignored): "Hi, I'm a data scientist and I'd like to write an article for your publication about customer churn and machine learning. Let me know if you're interested. I've attached my résumé." ✅ After (a pitch that gets a reply): "Most customers who quit a product never complain—they just vanish in the first few weeks. I'm a data scientist who dug into why, and the answer turns out to look a lot like a gym membership: it's all about the first visit. I think your readers, who [specific thing about their audience], would find the counterintuitive 'fix retention by fixing day one' angle useful. Could I write this as ~1,200 words? Draft by the 15th."

Why it's better: The "before" leads with "I'd like to write" (about the writer, not the reader), names a topic without an angle ("churn and machine learning"), shows no knowledge of the publication, and ends with a résumé instead of an idea. The "after" opens with the hook itself—proving the writer can do the one thing the job requires—names a specific, counterintuitive angle, shows it fits this outlet's readers, and makes a clean, dated ask. An editor can say yes to the second in ten seconds. The pitch, in other words, is a tiny science-communication piece: hook, so-what, audience-fit. If you can't make the pitch compelling, the article won't be either.

The career path. Science communication is not only a side skill; for a growing number of people it's the whole job. Science journalists write about research for the public. Technical writers and developer advocates (part documentation, part teaching, part public writing) sit between engineering teams and their users. Communications staff at universities, national labs, and research institutes translate their organization's work for the world, and popular-science authors build audiences around explaining hard things well. And countless scientists, engineers, and analysts who don't do it full-time find that explaining their work to non-specialists is what earns them grants (Chapter 17's "broader impacts"), promotions, and influence their equally-skilled peers never reach. The reason traces straight back to Chapter 1: technical skill is common; the ability to explain technical work to people who don't share it is rare, and rarity is leverage. This chapter is a door into that, whether you walk all the way through it or just keep the key.

🪞 Learning Check-In You're near the end of Part V, and you've now written the same finding for a peer, a decision-maker, and the general public. Pause and ask yourself: when you sit down to explain something technical to a non-expert now, what's the first question you ask—and how is it different from the question you'd have asked before Chapter 2? If your honest first instinct is still "how do I explain what I did?" rather than "what does this reader already know that I can build an analogy on, and what's the one thing they need to walk away with?"—that's the gap to keep closing. The whole skill of this book is in the order of those questions.

28.9 Common Mistakes and Practical Considerations

The principles are clear; the failures are persistent, because the pull toward writing for yourself—your vocabulary, your sense of what's interesting, your love of your own analogy—is strong. Here are the mistakes that survive knowing better, and the judgment calls the rules don't settle.

Mistake 1: Dumbing down instead of translating. The cardinal sin, and the one readers punish hardest. Cutting the actual idea, condescending ("this might sound complicated, but bear with me!"), or oversimplifying into falsehood are the same failure: you mistook "general audience" for "less intelligent" instead of "less specialized." Keep the real idea; change the vocabulary and the frame. If your simplified version no longer contains the thing that was interesting or true, you didn't translate it—you gutted it.

Mistake 2: The unflagged broken analogy. You found a vivid analogy, fell in love with it, and rode it past where it stops matching—without telling the reader, who is now drawing wrong conclusions with your authority behind them (§28.3). The fix is the §28.3 discipline: know where your analogy breaks, and if the break sits on your point, name it or change analogies. Loving your own analogy is the most common reason writers ride it off the cliff.

Mistake 3: Blowing the jargon budget without noticing. You're so fluent that "endpoint," "throughput," "cohort," "significant," "vector" don't register as jargon at all—the curse of knowledge, exactly. You think you used one term; you used six. The only reliable fix is mechanical: in a near-final draft, circle every term a non-specialist might not know, count them, and get to two or three by defining the essential and cutting the rest. You can't do this by feel, because the words are invisible to you.

Mistake 4: A hook that doesn't pay off. Clickbait—you opened a gap the article never closes, promised a surprise that fizzles, asked a question you answer with a shrug. It wins the click and loses the trust, and a reader burned once leaves faster next time. The hook must cash the check it writes: open only gaps you genuinely close (§28.4). Compelling-but-empty spends a reputation you don't get back.

Mistake 5: Burying the lede out of "rigor." The IMRaD reflex (§28.5): you lead with background and method because it feels more responsible and scientific. For this reader it's the surest way to lose them before the interesting part. Narrate the rigor; don't front-load it—weave the method into the journey and point to it at the end for the curious.

The judgment call: how much can you assume? "General audience" is always a specific slice (§28.1), and the hardest live decision is how much that slice already knows. A Quanta reader wants more depth and one more term than a local-newspaper reader; a company engineering blog can assume "API," a mainstream outlet can't. There's no formula—make the Chapter 2 move: picture the actual publication's representative reader and calibrate jargon and analogy to them, not to a lowest common denominator and not to yourself. When genuinely unsure, aim slightly lower: a reader rarely minds an explanation they didn't need (their eye skips it), but is always lost by one they did.

A note on length and the medium. Popular articles are usually shorter than the writer's instinct—a tight 800-word piece that lands beats a thorough 2,500-word one that loses the reader by paragraph six. Cut harder than for any other genre (Chapter 3, at maximum). And mind the medium's furniture: a compelling title and meta description (§28.7), short paragraphs and descriptive subheads for the phone-scanner (Chapters 4 and 10), and one well-chosen image where a wall of text would lose the reader (Chapter 9). The writing is the core; the packaging gets it read.

Frequently Asked Questions

How do I explain a technical concept without dumbing it down?

By translating, not deleting—the same distinction from Chapter 2 and Chapter 7. Dumbing down removes the actual idea or condescends to the reader; translating keeps the real idea and changes only the vocabulary and the frame to fit a non-specialist. The three tools that do this without loss: an analogy that maps the concept onto something the reader already understands (§28.2), a tight jargon budget that spends your two or three terms on what truly needs them (§28.3), and narrative structure that delivers the idea as a story the reader wants to follow (§28.5). If your "simplified" version no longer contains the thing that was interesting or true, you gutted it—that's the failure to avoid. A general reader is less specialized than you, not less intelligent; write to that.

What makes a good analogy in science writing?

A good analogy maps a source the reader already knows onto the target you're explaining, and it satisfies three tests: the source is genuinely familiar to this reader (not a second piece of jargon), the mapping holds for the one relationship your point depends on, and the reader can reason with it—extend it correctly on their own (§28.2). Crucially, you must also know where it breaks: every analogy diverges from the target somewhere, and if that break sits on top of your point, you flag it ("unlike planets, electrons don't really orbit on tracks") or pick a different source (§28.3). The mark of a skilled communicator isn't a flawless analogy—there's no such thing—it's one whose limits they understand and disclose before the reader trips over them.

How many technical terms can I use in an article for a general audience?

As a working rule, two or three per article, maximum—the jargon budget. Every unexplained technical term is a place an unobligated reader can get lost and leave, so you spend the budget only on terms that are genuinely load-bearing and worth teaching, define each one the first time (often with a quick analogy), and cut or replace the rest in plain language (§28.3). The catch is that you can't enforce this by feel, because fluency makes your field's vocabulary invisible to you (the curse of knowledge, Chapter 2)—so do it mechanically: in a near-final draft, circle every word a non-specialist might not know, count them, and get the count down. Most writers discover they used five or six terms when they thought they'd used one.

How do I start a blog post so people keep reading?

With a hook that opens a curiosity gap in the first two sentences—a question the reader now needs answered, a surprising fact that cracks their assumptions, a scene they have to see the end of, or the stakes that make it about them (§28.4). What a hook must not do is announce the topic ("In this post, we'll explore…"), because that closes the gap instead of opening one—it tells the reader what's coming and gives them no reason to continue. The one rule: the hook writes a check the article must cash. Open only gaps you genuinely close; a hook with no honest payoff is clickbait, and it loses more trust than no hook at all.

How do I pitch an article to a publication?

Send a short pitch email (≈150–200 words) before you write the piece. Open with the hook itself—the most compelling thing about the article, the same opening you'd use in the piece—not "I'd like to pitch an article" (§28.8). Then give the angle (what it argues, why it's new or timely, and specifically why it fits this publication's readers—generic pitches that ignore the outlet get rejected instantly), one line on why you can write it, and a clean, low-friction ask with a length and a date ("~1,200 words, draft by the 15th"). A pitch is itself a tiny science-communication piece—hook, so-what, audience-fit—so if you can't make the pitch compelling, the article won't be either. Read the publication first; the surest rejection is a pitch that could have been sent to anyone.

Chapter Summary

Key Takeaways

• The general reader is unobligated—they can leave at any second, at no cost—so you have to earn attention sentence by sentence instead of assuming it. That single fact drives the hook, the jargon budget, and the narrative structure.
• The analogy is the fundamental tool of science communication: it maps a familiar source onto an unfamiliar target, letting the reader understand a concept before learning its vocabulary. Pick a source genuinely familiar to this reader, that maps the one relationship your point needs.
• Every analogy breaks somewhere, and finding the break is the most important skill in the chapter. If the break sits on your point, flag it or change analogies—an unflagged broken analogy makes the reader draw wrong conclusions with your authority behind them. An analogy is a loan, not a gift.
• The jargon budget is two or three terms per article. Enforce it mechanically—circle every term, count, cut—because fluency makes your own jargon invisible to you (the curse of knowledge).
• Open with a hook that creates a curiosity gap, and structure as narrative, not IMRaD. Lead with tension (a question, a surprise, a scene, the stakes), narrate the rigor as a journey, and land the "so what" at the payoff—because the structure that serves a specialist loses everyone else.
• Honest SEO is audience service: a searchable-and-compelling title, a meta description under 155 characters, descriptive headers, and an FAQ help the right reader find and choose your piece—the same choices this book itself makes.

Action Items

1. Before drafting, choose your analogy—pick the source the reader already owns that maps your one key relationship, and write down where it breaks.
2. Write the hook last and hardest: open a curiosity gap in two sentences, and make sure the piece cashes the check.
3. Run the jargon count on a near-final draft: circle every term, get to two or three, define the survivors with an analogy where you can.
4. Structure it as hook → journey → payoff, narrating the method instead of front-loading it, and land the "so what."
5. Title for findability and the click, write a sub-155-character meta description, and test the whole piece on a real non-specialist—watch where they slow down.

Common Mistakes

Decision Framework: Writing for a General Audience

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 7) Chapter 7 taught that register is a dial you set on purpose—formal, neutral, informal—to match audience and genre. A blog post for the general public and a journal article report the same finding. Which register does each call for, and name one concrete word- or sentence-level choice that differs between them.
2. (From Chapter 3) The "so what?" test asks whether a sentence carries a fact for this reader. How does the jargon budget in this chapter apply the same idea Chapter 3 applied to cutting jargon—and what's different about the ceiling?
3. (From Chapter 2, bridging) Chapter 2 placed the general public at the far end of the audience spectrum and said they need "a hook or an analogy, a term or two, max." This chapter is that one line expanded into a whole skill set. Connect the curse of knowledge (Chapter 2) to why the jargon budget has to be enforced mechanically rather than by feel.

What's Next

You've now written a technical idea for every reader on the spectrum—the peer who audits it, the decision-maker who acts on it, and the stranger who has to be hooked into caring at all. That stranger demanded the hardest skills in the book: the analogy, the jargon budget, the curiosity gap, the story over the study. Chapter 29 (Writing with AI) turns to a tool you'll be tempted to use for all of it—a language model that can draft a hook, suggest an analogy, or tighten a paragraph in seconds. The chapter's question is where that help ends: what a model is genuinely good at (rephrasing, brainstorming, first drafts) and what it cannot do (know your reader, supply the right analogy, tell the truth reliably, or do the thinking that—per Chapter 1—is the whole point of writing). You'll learn to use AI as a revision tool without outsourcing the judgment that makes the writing yours.

Practice: Exercises · Quiz Go deeper: Case Study · Case Study 2 Review: Key Takeaways · Further Reading