Chapter 10: Design and Layout: Making Documents That People Actually Want to Read

"Typography exists to honor content." — Robert Bringhurst, The Elements of Typographic Style

Chapter Overview

Put two documents in front of someone. They contain the exact same words. The first is a single block of 11-point text, edge to edge, no headings, no spacing, justified into a gray slab. The second has a clear title, generous margins, short paragraphs separated by air, three informative headings, and one key number set in bold. Ask which one the reader would rather read. You already know the answer—and so does the reader, who decided in about half a second, before reading a single sentence. That half-second judgment is the subject of this chapter, and it determines whether the careful writing you did in Chapters 1 through 9 ever gets read at all.

Here is the claim this chapter defends: visual design is part of clear communication, not a cosmetic layer applied afterward. You have spent nine chapters making your words clear—cutting bloat (Chapter 3), structuring for scanners (Chapter 4), flowing paragraphs (Chapter 8), interpreting data (Chapter 9). All of that work reaches the reader through a visual surface: a page, a screen, a slide. If that surface is hostile—dense, cramped, undifferentiated, low-contrast—the reader bounces before your words get a chance. Design is the doorway. A reader who finds the doorway uninviting never enters the room you built. This connects to theme 5 (structure serves the reader, not the writer): visual layout is structure made visible, the physical expression of the hierarchy you organized in Chapter 4. And it connects to theme 7 (the best writing is invisible)—because the best design, too, is invisible. Good layout you don't notice; you simply find what you need without friction. Bad layout you feel as effort, even if you can't name why.

This is not a graphic-design course, and you are not being asked to become a designer. You are being asked to clear a much lower and more important bar: stop actively harming your readers with your defaults. Most technical documents are not over-designed; they are un-designed—Times New Roman, single-spaced, no white space, headings that look like body text, a wall of gray. You don't need to make documents beautiful. You need to make them readable, and you need to make them readable by everyone, including the roughly one in twelve men who can't distinguish red from green and the readers who navigate your document by ear through a screen reader. By the end of this chapter, you will be able to take a wall-of-text page and redesign it—with typography, white space, hierarchy, and restrained emphasis—into something a reader actually wants to read, and you will be able to check that your design is accessible to readers who see color differently, who need high contrast, or who rely on assistive technology.

In this chapter, you will learn to:

• Set body text that is comfortable to read—choosing a typeface, size, line length, and line spacing that reduce reading effort instead of adding it.
• Use white space and a visible header hierarchy to convert a dense block into a scannable, navigable page.
• Apply emphasis and color sparingly and purposefully, so that what's emphasized actually stands out.
• Design for accessibility as a default: meet contrast ratios, never rely on color alone, and structure documents so screen readers and assistive tech can navigate them.
• Use templates and house styles to your advantage without producing generic, soulless documents.

📘 Business/Professional track: Design is reputation. A proposal or report that looks careful signals that the thinking behind it is careful; a sloppy-looking one undercuts good content. Prioritize §10.2 (typography), §10.3 (white space and hierarchy), and §10.7 (templates)—your documents live and die on first impression in an inbox. 📗 Software/CS track: This is the visual layer of everything you'll write in Part V—READMEs, API docs, tutorials. Markdown and the web give you hierarchy, code blocks, and white space for free if you use them. Pay special attention to §10.3 (hierarchy), §10.5 (emphasis—and not over-bolding), and §10.6 (accessibility, which is a hard requirement on the web). 📕 Engineering/Science track: Even inside a rigid journal or report template, the principles here govern your figures, tables, and section spacing. §10.2 and §10.6 matter most; the template handles the rest, and §10.7 tells you how to work with it.

10.1 The Reader Judges Before Reading

You learned in Chapter 4 that the reader scans rather than reads. There is a step that happens even before scanning: the reader looks at the page and decides, almost instantly and mostly unconsciously, whether this is going to be painful. Call it the flinch test. A dense, gray, undifferentiated page triggers a small flinch—this looks like work—and the reader's willingness to engage drops before they have processed a single word. An open, structured, well-spaced page invites them in. This judgment is visual, it is fast, and it is real.

Consider the most extreme version of the problem—the wall of text. This is the anchor we'll return to all chapter, so look at it closely:

❌ Before (a wall of text — described): Imagine a full page with no title and no headings. The text runs from the left margin to the right margin with almost no margin at all. It is one continuous block—no paragraph breaks visible, or paragraphs so long they read as one mass. The lines are long, stretching the full width of the page, so the eye has to travel far and then hunt for the start of the next line. Everything is the same size, the same weight, the same color. There is no place for the eye to rest and nothing to tell it where to look first. It is a gray rectangle of words.

Nothing is wrong with the words in that block. The sentences might be excellent. But the reader can't tell, because the page has given them no way in. There is no entry point (no title or heading saying "start here"), no hierarchy (nothing signals what matters most), no breathing room (no white space to rest the eye), and no navigation (no headers to scan). The reader has to read it linearly and entirely to get anything—which, as Chapter 4 taught, is exactly what no reader will do. The design has defeated the writing.

Now the same content, redesigned:

✅ After (the same words, designed — described): The page now opens with a clear title in large, bold type, with space beneath it. The text sits in a comfortable column—not edge to edge, but with generous margins, so each line is a comfortable length the eye can track. Three informative headings (larger and bolder than the body, with space above each) break the page into scannable sections; a reader running their eye down the left edge meets a heading every few inches. Paragraphs are short—three or four lines each—separated by visible space. One key figure is set in bold so it catches the eye. There is air. The page looks like something a person made for another person to read, not a data dump.

Why it's better: Every change serves the scanning, flinching reader. The title and headings give entry points and a navigable map (the hierarchy from Chapter 4, now made visible). The shorter line length and the margins reduce the physical effort of reading. The white space gives the eye places to rest and signals "this is organized." The short paragraphs invite the reader in rather than daring them. Crucially, not one word changed. The improvement is entirely in the visual presentation of identical content. That is the whole thesis of the chapter: how a document looks changes whether it gets read, independent of what it says.

🚪 Threshold Concept: Design is not decoration; it is part of the meaning.

How novices think about design: the words carry the meaning, and design is "making it look nice"—an optional layer of polish applied at the end if there's time, a matter of taste, the part you do in PowerPoint with clip art and gradients. If the content is good, the design doesn't really matter; substance over style.

How design actually works: the visual surface is the only channel through which your words reach the reader, and the reader processes that surface before and while reading the words. Layout, type, spacing, and hierarchy are not added to meaning—they carry meaning. A heading says "this is a new section" before the reader reads it. White space says "you can rest here." Bold says "this matters." Bad design doesn't just look bad; it miscommunicates, or fails to communicate, or repels the reader entirely. Design is the reader's first and continuous experience of your content. You cannot opt out of it—every document has a design, and the only question is whether yours helps or hurts.

Once you cross this threshold, "substance over style" stops being a defense. A document with great substance and hostile design has failed to deliver its substance, the same way the Challenger engineers' correct conclusion failed to arrive (Chapter 4). The reader experiences design and content as one thing, because to them they are one thing: the page in front of them.

The good news is that clearing the bar is easy. The wall-of-text fix above required no design talent—just short paragraphs, headings, margins, and a little white space. Most of this chapter is that simple. The reader isn't asking you to be a designer. They're asking you not to make them flinch.

🔄 Check Your Understanding A colleague says, "I don't have time to format it nicely—the content is solid, and that's what matters." What's the flaw in this reasoning?

Answer

It assumes content and design are separable, and that the reader experiences the content independent of how it looks. They don't. The reader meets the visual surface first and decides—in about half a second—whether to engage, before reading any content. Solid content behind a hostile, undifferentiated layout is content the reader bounces off of. "Formatting nicely" here isn't decoration; it's the difference between the solid content being read or ignored. Design is part of whether the substance lands.

10.2 Typography: Making Words Comfortable to Read

Typography is the visual treatment of text itself—the typeface, the size, the spacing of lines and letters. It is the part of design that operates at the smallest scale and matters most, because it governs the basic physical comfort of reading. Most reading discomfort that people blame on "too much text" is actually bad typography: type too small, lines too long, spacing too tight. Fix the typography and the same amount of text becomes far easier to take in.

Start with the choice that everyone overthinks and gets the wrong way around: serif versus sans-serif. A serif typeface has small finishing strokes at the ends of letters—Times New Roman, Georgia, Garamond. A sans-serif typeface omits them ("sans" = without)—Arial, Helvetica, Calibri, Verdana. (A third family, monospace, gives every character the same width—Courier, Consolas—and is for code, which we'll get to.) The folklore says "serif for print, sans-serif for screen," and there's a grain of truth in it historically, but here is the honest current answer: for body text, either works if it's a well-made, readable typeface used at a reasonable size; the typeface matters far less than the size, spacing, and line length. A good serif and a good sans-serif are both fine. What's not fine is a decorative or novelty face for body text, or twelve different fonts on one page. Pick one readable typeface for body text, optionally a second (often a sans-serif) for headings, and stop. The skill isn't choosing the perfect font; it's not making a mess.

🔍 Why Does This Work? Why do serifs and sans-serifs both work for body text, when people insist one is "more readable"? Think before reading on.

Because legibility at normal reading sizes is dominated by factors that have little to do with the serifs: the overall letter shapes being distinct from one another, the type being big enough, the lines being short enough to track, and enough space between lines that they don't blur together. Serifs were long thought to "guide the eye along the line," and that may help a little in dense print, but the effect is small compared to size and spacing. So obsessing over serif-vs-sans is optimizing a rounding error while ignoring the main terms. The real readability wins are: bigger type, shorter lines, more line spacing. Spend your attention there.

Now the factors that actually matter. First, type size. Technical writers chronically set body text too small to look "professional" or to fit more on a page—9-point, 10-point, justified tight. This is a false economy paid for by the reader's eyes. For body text, aim for something in the comfortable range (roughly 10–12 point in print, 16 pixels or more on the web is a common baseline) and lean toward the larger end when you can. If you're tempted to shrink the type to fit more on the page, that's a sign to cut words (Chapter 3) or add a page, not to shrink the type. The reader's comfort outranks your page count.

Second, line length (typographers call it the measure). This is the single most underrated typographic factor and the one technical writers get wrong most often, because the default in a word processor or a full-width web page is to run text edge to edge. Lines that are too long are genuinely hard to read: when the eye finishes a long line and sweeps back to the left, it has to find the start of the next line, and across a long measure it frequently lands on the wrong one—you re-read a line or skip one. The widely-taught guideline is roughly 45 to 75 characters per line (about 8 to 15 words), with the mid-60s often cited as a sweet spot. This is why books have margins, why newspapers use columns, and why a full-page-width block of text feels exhausting even when it's well written. The fix is simple: constrain the width. Add margins. Use a column. On the web, set a max-width on your text container. Don't let a single line of body text run the full width of a wide page.

Figure 10.1 (described): Line length and the return sweep. Two text blocks side by side. The left block, labeled "Too long (~110 characters)," runs the full page width; a dotted arrow shows the eye finishing a line at the far right and sweeping all the way back to the left, with a small "?" where it has to hunt for the correct next line. The right block, labeled "Comfortable (~65 characters)," is a narrower column with wide margins; the return-sweep arrow is short and lands cleanly on the next line. A caption reads: "Shorter lines make the return sweep reliable; long lines cause re-reading and line-skipping." Alt-text: a comparison showing that very long lines force a long, error-prone return sweep to the next line, while a comfortable ~65-character measure makes the eye's return short and accurate.

Third, line spacing, called leading (pronounced "ledding," from the strips of lead once used to space lines in metal type). Lines set too tightly blur together and make the return sweep harder; lines with a little breathing room are markedly easier to read. The common guideline is leading of roughly 120–145% of the type size—so 11-point text wants something like 13–16 points of line spacing, and the "single spacing" default is often a touch tight while "double spacing" is usually too loose for finished documents (it's a drafting/markup convention). On the web, a line-height around 1.4 to 1.6 is a reasonable default. A small increase in leading is one of the cheapest readability upgrades available; dense, single-spaced text loosened just slightly becomes visibly more inviting.

A quick before/after to make typography concrete:

❌ Before (hostile typography — described): 9-point Times New Roman, set in a single block the full width of an 8.5-inch page (≈110 characters per line), single-spaced, fully justified so the word spacing stretches unevenly and "rivers" of white open up through the text. It is technically legible and genuinely unpleasant—small, wide, and tight all at once.

✅ After (comfortable typography — described): 11-point in a clean serif or sans-serif, set in a column about 6.5 inches wide with 1-inch margins (≈70 characters per line), line spacing around 135%, left-aligned with a ragged right edge (no forced justification, so word spacing stays even). The same words now read with noticeably less effort.

Why it's better: Three independent improvements stack: the type is large enough, the measure is short enough to track, and the leading gives the lines room to breathe. Dropping forced justification removes the uneven "rivers" of white space that full justification opens up in narrow columns. None of this is artistry—it's just respecting how eyes work. (A note on justification: justified text, with both edges flush, can look tidy, but in narrow columns or without good typesetting it creates ugly, distracting gaps. For most technical documents, left-aligned, ragged-right is the safe, readable default.)

One more, briefly: monospace for code. When you show code, commands, file names, or any text where exact characters and alignment matter, use a monospace typeface in a code block. It's not just convention—monospace makes 1 versus l, O versus 0, and indentation unambiguous, and it visually signals "this is literal text to type, not prose." We'll lean on this throughout Part V. Don't set code in your body font, and don't set prose in monospace.

✏️ Try This Open any document you wrote recently. Check three numbers: (1) the body type size—is it at least ~11pt / 16px? (2) the line length—does any line of body text run more than ~90 characters? (3) the line spacing—is it at or above single spacing, ideally a touch more? If you fix only the line length (constrain the width with margins or a column), you'll likely get the biggest single readability gain for the least effort.

[📍 Good stopping point — you now have the typography fundamentals: typeface (any readable one), size (bigger), line length (shorter), spacing (looser). The rest of the chapter zooms out to the whole page.]

10.3 White Space and Hierarchy: Turning a Block Into a Page

If typography is the comfort of the text, white space and hierarchy are the architecture of the page. White space is simply the empty area in a layout—margins, the space between paragraphs, the gaps around headings and figures, the breathing room. Beginners treat white space as wasted space to be filled; designers treat it as one of their most powerful tools. Empty space is not absence; it is structure you can see. It groups related things, separates unrelated things, directs the eye, and tells the reader the page was made with care.

Watch what white space alone does. Take a set of items crammed together versus the same items with space:

❌ Before (no white space — described): A contact block reading "Dr. Amara Okonkwo Principal Investigator Marine Biology Department aokonkwo@university.edu +1-555-0142 Office 314B Marine Sciences Building" — all run together on adjacent lines with no spacing, so the name, role, department, and contact details form one undifferentiated clump the reader has to parse.

✅ After (white space groups and separates — described): The same information with the name on its own line in slightly larger type; a small gap; then role and department as a pair; another gap; then the contact details (email, phone) grouped together; another gap; then the location. The eye now reads four distinct groups instead of one clump, and finds the email instantly.

Why it's better: No words changed; spacing alone created groups. This is the design principle of proximity: things that are related should be close together, and things that are unrelated should be separated by space. The reader reads grouping as meaning—items near each other are understood as belonging together. White space, used this way, does structural work. It's the visual version of the paragraph break: just as a new paragraph signals a new idea (Chapter 8), a gap signals a new group.

The most important white space is the most ignored: margins. Generous margins around a page or a text column do two things at once—they shorten the line length (the typographic win from §10.2) and they frame the content, giving it room to breathe and signaling quality. Cramped, edge-to-edge text reads as a data dump; the same text inside comfortable margins reads as a considered document. When a page feels oppressive, the fix is often just more margin. Resist the instinct to fill every inch. Empty space at the edges is doing real work.

Now visual hierarchy—the visible version of the structural hierarchy you built in Chapter 4. There, you organized content into headings and subheadings, levels nesting one step at a time. Visual hierarchy is making those levels look like what they are, so a reader can see the structure at a glance without reading. The tools are size, weight, and space: more important things are bigger, bolder, and have more space around them; less important things are smaller and closer to what they belong to.

Figure 10.2 (described): Visual hierarchy through size, weight, and space. A page schematic with four levels shown as gray bars of text. At the top, a large, bold bar = the title (H1), with wide space below it. Below that, a medium bold bar = a section heading (H2), with clear space above it (more than below, so it attaches to the section it introduces). Beneath it, several thin regular bars = body text, closely spaced. Then a smaller bold bar = a subsection heading (H3), again with more space above than below. The right margin notes: "Size + weight + space encode level. More space ABOVE a heading than below it, so it groups with the content it introduces (proximity)." Alt-text: a schematic page showing how heading levels are made visually distinct by using larger size, heavier weight, and more surrounding space for higher-level headings, with more space placed above a heading than below it so it visually attaches to the section it introduces.

Two practical rules make hierarchy work. First, make the levels obviously different, not subtly different. A heading that's only one point larger than body text, in the same weight, doesn't read as a heading—it reads as a slightly odd sentence. Headings should be unmistakably bigger and/or bolder than body text, and each level clearly distinct from the others. If a reader can't tell at a glance whether something is an H2 or an H3, your hierarchy isn't doing its job. Second, the "more space above than below" rule: put more space above a heading than below it. This sounds trivial but it's the difference between a heading that floats ambiguously between two sections and one that clearly belongs to the section it introduces. Proximity again: the heading should sit closer to its own content than to the content above it.

Here's the wall-of-text anchor, re-examined through this lens. The original failed not because its sentences were bad but because it had no white space (no margins, no paragraph gaps, no room around anything) and no visible hierarchy (everything the same size and weight, no headings standing out). The redesign worked by adding exactly those two things: white space to group and rest, and hierarchy to show structure. You don't need more than that to rescue most dense documents.

🧩 Productive Struggle Before reading on: you're handed a one-page "release notes" document that's a single bulleted list of 30 changes, all at one level, no grouping, no headings—just 30 bullets in a row. The reader complains they "can't find anything." Using only white space and hierarchy (no rewriting the bullets), how would you fix it? Think it through, then check.

One good approach

Group and label. Sort the 30 bullets into a few meaningful categories—say "New Features," "Bug Fixes," "Breaking Changes," "Performance"—and put each group under its own clear heading (visual hierarchy), with white space between the groups (proximity). Within each group, the bullets stay as they are. Now a reader hunting for breaking changes jumps to that heading and reads five bullets instead of scanning thirty. You changed no bullet text—only the grouping (white space) and the labels (hierarchy). That's the whole fix, and it's exactly what good release notes and changelogs do. The flat list buried everything at one level; grouped-and-labeled structure makes it scannable. This is the Chapter 4 lesson—structure serves the scanner—expressed purely through visual design.

A short word on alignment, the fourth quiet workhorse (with proximity, hierarchy, and white space). Things that line up read as orderly and connected; things that don't line up read as sloppy and create invisible tension. Pick an alignment—usually left—and hold to it: body text, headings, and list items sharing a left edge create a clean vertical line the eye follows down the page. Stray centered headings, randomly indented blocks, and mixed alignments make a page feel disordered even when nothing is "wrong." When a layout feels off but you can't say why, check whether everything that should align actually does.

10.4 Page Layout by Document Type

The principles so far—typography, white space, hierarchy, alignment—are universal. How you apply them depends on the document type, because different documents are read differently and live in different formats. A few common cases, each with its design priorities.

A report or paper (read on a page, scanned then sometimes read deeply). Comfortable margins; a clear title block; informative headings in a visible hierarchy (Chapter 4); body text in a readable measure; figures and tables with captions that interpret (Chapter 9), placed near the text that references them with space around them. The reader scans the headings, dips into sections, studies the figures. Design serves that: strong heading hierarchy for scanning, clean figures for the dip-in, enough white space that a deep reader isn't exhausted. If it's long, a table of contents and running headers (so a reader always knows where they are) earn their keep.

An email (read fast, in a crowded inbox, often on a phone). Design is mostly structural because you don't control the typeface: short paragraphs (one idea each), white space between them, the ask up front (BLUF, Chapter 4), maybe a short bulleted list or a bolded deadline. The enemy is the dense five-line paragraph that the reader's eye slides off. We'll go deep on email in Chapter 19; the design lesson here is simply that white space and short paragraphs are most of email "formatting," and they matter more on a phone screen, where a long paragraph becomes a daunting scroll.

A README or web document (read on screen, scanned hard, navigated by jumping). The web gives you hierarchy, code blocks, lists, and white space cheaply through Markdown or HTML—use them. A README wants a clear title, a one-line description, scannable section headings (Installation, Usage, Contributing), code in monospace blocks, and generous spacing. Readers jump to the section they need (Chapter 4's scanning, intensified). Raj's README, which we'll rebuild in Chapter 25, fails partly as a design problem: a wall of prose with no headings, no code formatting, no white space—the visual symptoms of the same disease we diagnosed in §10.1. The cure is the cure for any wall of text: hierarchy and air.

A slide (seen from across a room, for seconds). A radically different medium—not a document to read but a visual to glance at. Big type (a slide read at 12-point fails), very few words, one idea per slide, high contrast, lots of empty space. The mistake is treating a slide like a page and cramming paragraphs onto it. Slides get their own full treatment in Chapter 30 (the assertion–evidence approach), but the through-line is the same principle scaled to an extreme: more white space, bigger type, less crammed in.

A form or instructions (read while doing a task, under stress). Generous spacing between fields or steps so they don't blur; numbered steps with clear separation; warnings set off visually before the step they apply to; one action per step (Chapter 22). Cramped instructions cause errors because the reader, mid-task and stressed, loses their place. Here white space isn't aesthetic—it's safety. (Chapter 36 makes this point in the highest-stakes setting, medical instructions.)

The meta-point: let the reading situation drive the layout. Ask how, where, and under what pressure this will be read—on a phone in a hallway, on paper at a desk, on a projector from the back row, on a screen while debugging—and design for that situation. The same content laid out for a printed report and for a phone email should look different, because it will be read differently. Audience is everything (theme 2), and the reading situation is part of the audience.

🔄 Check Your Understanding Why should the layout of the same content differ between a printed report and a mobile email?

Answer

Because they're read in different situations, and layout serves the situation. A printed report is read at a desk, scanned then studied, on a wide page—so it can use a multi-section hierarchy, figures, comfortable margins, and a longer measure. A mobile email is read fast, in a crowded inbox, on a narrow phone screen, often one-handed in a hallway—so it needs very short paragraphs, lots of white space, the ask up front, and almost no width-dependent formatting (a long paragraph becomes an intimidating scroll on a phone). Same words, different reading situation, therefore different layout. The reading situation is part of the audience (theme 2).

10.5 Color and Emphasis: Less Than You Think

Color and emphasis are where eager writers do the most damage, because they feel like "making it pop" and are easy to add. The governing principle runs exactly opposite to the instinct: emphasis works only by contrast, so the more you emphasize, the less any of it stands out. A page with one bold phrase has one thing your eye jumps to. A page with twenty bold phrases, three colors, some italics, an underline, and a highlighter pass has nothing that stands out—the emphasis cancels itself, and you've just made the page noisy and harder to read. Emphasis is a scarce resource. Spend it on the one or two things that genuinely matter most.

❌ Before (over-emphasized — described): A paragraph in which roughly a third of the words are bold, two phrases are in red, one is ALL CAPS, another is italic-and-underlined, and a sentence is highlighted yellow. The writer emphasized everything they thought was important. The eye, hit with emphasis everywhere, has nowhere to land and reads the whole thing as agitated noise. Nothing is prioritized because everything is.

✅ After (one emphasis, purposeful — described): The same paragraph in plain body text, with exactly one phrase bold—the single key number the reader most needs ("churn rose to 8.2%"). The eye goes straight to it. Everything else is calm body text, so the one emphasized thing actually does its job: it stands out.

Why it's better: Emphasis is differential—it works by being different from its surroundings. When most of the text is emphasized, "emphasized" becomes the new normal and stops signaling anything. Restricting emphasis to one phrase restores the contrast that makes emphasis function. The rule of thumb: if you've emphasized more than a small fraction of a passage, you've emphasized nothing. Pick the most important element and let it be the only one.

A few specific guidelines. Bold is for the occasional key term or critical phrase you want a scanner to catch—use it sparingly. Italics are for genuine uses (titles of works, a defined term at first mention, light stress on one word) and not for whole sentences (long runs of italic are harder to read). Underline, on screen, means "link"—don't underline for emphasis on the web, because readers will try to click it; underlining for emphasis is a holdover from typewriters that has no place in digital text. ALL CAPS is for very short labels (a one-word "WARNING"), never for sentences or paragraphs—caps remove the word-shape cues that aid reading and read as shouting. The disciplined default is: plain body text, with bold used rarely and deliberately.

Now color. Color can be genuinely useful—to categorize (status colors in a dashboard), to highlight (one accent color drawing the eye), or to brand (a consistent palette). But it carries three traps. First, the emphasis trap above: too many colors is the same failure as too much bold—a rainbow page where nothing stands out. A restrained palette (often one accent color plus neutrals for text) beats a riot of color. Second, color costs nothing on screen but can cost money and legibility in print (and a document emailed around may be printed in grayscale, where your color coding vanishes—see accessibility below). Third, and most important, color is the single biggest accessibility hazard in document design, which is the subject of the next section. Before you use color to carry meaning, you must understand who can't see it the way you do.

⚠️ Warning Never use color as the only way to convey information. "The red items are overdue, the green ones are on track" fails completely for the roughly 1 in 12 men and 1 in 200 women with color vision deficiency (most commonly red-green), and for anyone reading a grayscale printout. This isn't a minor edge case—it's a large fraction of your readers. Always pair color with a second cue: a label, an icon, a shape, a text marker. Color can reinforce a distinction; it must never be the sole carrier of it. (Detailed in §10.6.)

🔄 Check Your Understanding Why does emphasizing many things in a document result in nothing standing out?

Answer

Because emphasis works by contrast—an emphasized element stands out only by being visually different from the unemphasized text around it. When you emphasize a large fraction of the text (lots of bold, multiple colors, etc.), "emphasized" becomes the dominant texture of the page, so there's no longer a calm baseline for it to contrast against. The eye has emphasis everywhere and therefore nowhere to land. Restricting emphasis to one or two genuinely important elements restores the contrast that makes emphasis function. Emphasis is a scarce resource; spending it everywhere bankrupts it.

10.6 Accessible Document Design: Designing for Everyone

Everything in this chapter so far makes documents better for most readers. This section makes them usable for all readers—including people who see color differently, who need high contrast, who enlarge text, or who can't see the document at all and navigate it by ear through a screen reader. Accessibility is not a niche add-on or a compliance checkbox; it is part of clear communication, which is the whole point of the book. A document that excludes readers has failed to communicate to them, however elegant it looks to everyone else. And accessibility is the law in many contexts (public-sector and many commercial documents must meet standards), so this is professional baseline, not extra credit. Three areas cover most of what a technical writer controls: contrast, color independence, and structure.

Contrast. Text must have enough luminance contrast against its background to be readable by people with low vision, by anyone in bright sunlight or on a dim screen, and frankly by everyone (low-contrast text is tiring for all readers). Light-gray text on a white background—a trendy choice—fails many readers. The standard to know is WCAG (the Web Content Accessibility Guidelines), which specifies a contrast ratio: the ratio between the brightness of the text and the brightness of its background, from 1:1 (no contrast, invisible) to 21:1 (black on white). The practical thresholds: normal body text should meet at least a 4.5:1 contrast ratio; large text (roughly 18pt+, or 14pt+ bold) can pass at 3:1. You don't compute this by eye—free contrast-checker tools (and most design software) report the ratio when you enter two colors. The takeaway: don't set text in light gray, pale color, or low contrast to look "subtle" or "modern." Subtle text is unreadable text for a meaningful slice of your audience. Pure black on white is fine; very dark gray on white is fine; light gray on white is not.

Color independence. As the warning in §10.5 stated: never let color be the only signal. This is worth its own treatment because it's the most common accessibility failure and the easiest to fix. About 1 in 12 men and 1 in 200 women have some color vision deficiency, most often difficulty distinguishing red from green—exactly the pairing people reach for to mean "bad/good." For these readers (and for grayscale printouts), a red-versus-green chart or a "red = overdue" table is information they cannot extract. The fix is redundant encoding: always pair color with a second, non-color cue.

❌ Before (color-only — described): A project table where each row's status is shown only by the cell's fill color: red cells are "overdue," yellow cells are "at risk," green cells are "on track." To a red-green color-blind reader, the red and green cells look nearly identical, and a grayscale printout turns all three into indistinguishable grays. The status information is invisible to a large group of readers.

✅ After (color plus a redundant cue — described): The same table, but each status cell now also contains a text label and a distinct icon: "● On track" (green dot + word), "▲ At risk" (yellow triangle + word), "■ Overdue" (red square + word). The color still helps readers who see it, but the word and the shape carry the meaning independently—so a color-blind reader reads the words, a grayscale printout shows the shapes and labels, and a screen reader announces the text. Color reinforces; it no longer monopolizes.

Why it's better: The information now survives every channel: color vision, no color vision, grayscale print, and audio. Adding a word and a shape costs almost nothing and removes the single most common exclusion in document design. When you must use color to categorize, also choose a color-blind-safe palette—palettes designed so the colors remain distinguishable under common color-vision deficiencies (avoid red/green pairs; blue/orange is a far safer contrast). Tools and named palettes for this exist; the principle is to pick colors that differ in more than just hue.

Structure for screen readers. A blind or low-vision reader using a screen reader doesn't see your layout at all—they hear the document, and they navigate it the way a sighted reader scans: by jumping between headings, lists, and links. This works only if your visual structure is also real, semantic structure underneath. This is the deep link back to Chapter 4's point about heading hierarchy, and it's why "use real headings" keeps recurring:

• Use real headings, not fake ones. A line that's big and bold but is just styled body text is invisible to a screen reader's heading navigation. Use actual heading styles/levels (in Markdown, #/##/###; in Word, the Heading styles; in HTML, <h1>–<h6>). And don't skip levels—a screen-reader user, like a sighted scanner, relies on the level structure to understand nesting. The heading hierarchy you built for sighted scanners in Chapter 4 is the structure that serves screen-reader users; do it once, serve both.
• Real lists, real tables. Use actual list markup for lists and real table markup (with header cells) for tables, so a screen reader can announce "list, 5 items" or read a table by row and column with headers. Faking a list with dashes-and-line-breaks or faking a table with spaces destroys this.
• Alt-text for every image. Every figure, chart, diagram, or meaningful image needs alt-text: a concise text description a screen reader reads aloud (and that appears if the image fails to load). This is exactly the figure-description discipline this book uses throughout—every "Figure X (described)" block is, in effect, alt-text. A chart's alt-text should convey what the chart shows (its point), not just "chart." (Decorative images that carry no information get empty alt-text so the screen reader skips them.) This ties directly to Chapter 9: a caption that interprets and an alt-text that conveys the takeaway are the same instinct—tell the reader what the visual means.
• Meaningful link text. Links should describe their destination ("see the installation guide"), not "click here" or a bare URL—because screen-reader users often pull up a list of links out of context, where "click here, click here, click here" is useless. (This is also Chapter 4's "informative headers" lesson applied to links.)

🔍 Why Does This Work? Why does building a correct heading hierarchy for sighted scanners also automatically serve blind screen-reader users? Consider before reading on.

Because both groups are doing the same task—navigating by structure rather than reading linearly—just through different senses. A sighted scanner runs their eye down the page and jumps to the heading that looks relevant (Chapter 4). A screen-reader user pulls up a list of headings and jumps to the one that sounds relevant. Both depend on the document having a real, correctly-nested hierarchy: meaningful headings, in the right levels, not skipped. So the work you do to make a document scannable for sighted readers—real informative headings, clean nesting, real lists—is the identical work that makes it navigable for screen-reader users. There's no separate "accessibility version." Good structure is accessible structure. That's why this book keeps insisting on real headings: one effort, two audiences served. The only place they diverge is the purely visual (contrast, color) and the image descriptions (alt-text)—which is why those get their own attention here.

The encouraging summary: most accessibility is just good design done properly. Real headings, real lists, sufficient contrast, color that isn't load-bearing, and alt-text that says what the image means—that's the bulk of it, and every item also improves the document for sighted readers (high contrast is easier on all eyes; redundant cues are clearer for everyone; alt-text forces you to articulate each figure's point). You are not doing extra work for a few people; you are doing the work that makes the document genuinely usable for everyone. Accessibility and quality point the same direction.

[📍 Good stopping point — you now have the accessibility essentials: contrast (≥4.5:1 for body text), color independence (never color alone), and real structure (headings, lists, alt-text) for screen readers.]

10.7 Using Templates Without Becoming Generic

Most of the time you won't design from scratch. You'll use a template—a company report template, a journal's LaTeX class, a slide master, a README skeleton, a documentation theme. Templates are good: they encode design decisions (margins, type, hierarchy) so you don't have to make them, they enforce consistency across a team or a publication, and they keep an inexperienced designer (most of us) from making a mess. A good template is a gift. Use them.

The worry people raise is that templates produce generic documents—everything looking identical, soulless, stamped from a mold. There's a real risk there, but it's usually misdiagnosed. A template feels generic not because templates are bad but because the writer dumped content into it without thought: kept the placeholder structure that didn't fit, left every section the default template provided whether relevant or not, never adjusted spacing or emphasis to the actual content, and produced the visual equivalent of a form letter. The template didn't make it generic; unthinking use of the template did. The fix isn't to abandon templates and design from scratch (you'll do worse). The fix is to use the template as a foundation and then make deliberate choices on top of it.

How to use a template well without fighting it:

• Keep the bones; adapt the content. Let the template own the things templates are good at—typeface, sizes, margins, the heading hierarchy, the color palette. Those are consistency wins; don't override them on a whim. But the structure of your specific document—which sections exist, in what order, what's emphasized—is yours. Delete template sections you don't need; add ones you do; reorder to fit your content's actual logic (Chapter 4). A template is a starting structure, not a mandatory one.
• Fill it with real hierarchy, not placeholder filler. The generic feeling comes from leaving the template's default emphasis and structure untouched. Apply this document's hierarchy: emphasize this document's key number, write this document's informative headings (not the template's "Section 1 / Section 2"). The design is the template's; the structure-of-meaning is yours.
• Customize lightly and consistently, if at all. If you do personalize—an accent color, a logo, a heading font—do it once, consistently, and in service of clarity, not decoration. One considered accent color applied consistently reads as intentional; three random color changes read as chaos. And never let a customization break the template's accessibility (don't swap the high-contrast body color for a trendy light gray).
• Respect the template's accessibility, and check it. A well-made template already handles contrast, heading structure, and spacing—a real reason to use one. But not all templates are accessible (especially older corporate or slide templates), so verify: are the headings real headings? Is the body contrast sufficient? Is anything color-coded without a second cue? If the template fails these, fix it within the template rather than abandoning structure.

The deeper point reframes the whole worry. Distinctiveness in technical documents should come from the content and its clarity, not from visual flourishes. A report isn't memorable because it had a unique font; it's memorable because it was clear, well-structured, and got to the point. The most respected technical and scientific documents in the world use rigidly standard templates (a journal article, an RFC, a standards document) and are distinguished entirely by the quality of their thinking and writing. "Generic-looking" is not the failure mode to fear; unclear is. A clean, standard, accessible template that lets your clear content shine is exactly what you want. Spend your effort on the writing and structure; let the template handle the pixels. This is theme 7 once more—the best design, like the best writing, is invisible: the reader notices your content, not your layout.

🔄 Check Your Understanding A coworker says, "Templates make everything look the same and boring—I design each document from scratch so it stands out." What two things are wrong with this?

Answer

(1) Designing from scratch usually makes it worse, not more distinctive. Most of us aren't designers; a template encodes good decisions (margins, type, hierarchy, contrast, often accessibility) that an from-scratch attempt is likely to botch—producing a document that stands out for being amateurish, not good. (2) "Generic" is the wrong thing to fear, and templates aren't actually the cause of it. Documents feel generic when content is dumped into a template thoughtlessly (default sections, no real hierarchy, no emphasis on what matters)—not because the template exists. Distinctiveness should come from clear content and structure, not visual flourishes; the most respected technical documents use rigidly standard templates and are distinguished by their thinking. Use the template's bones; supply your own structure-of-meaning on top.

📐 Project Checkpoint

Across Chapters 3, 4, and 5 you drafted, structured, and began revising your portfolio's technical report (piece 1 of 7): clear sentences (Ch 3), a top-down structure with informative headings and an executive summary (Ch 4), inside a sane writing process (Ch 5). The content is in good shape. This chapter's job is to make the report look like the careful document it is—because, as §10.1 argued, a reader judges before reading, and a well-written report in a hostile layout undersells itself.

Do a design pass on your technical report. Work through five checks, fixing as you go:

1. Typography. Is the body type comfortably sized (≥ ~11pt / 16px)? Is the line length reasonable (constrain the width with margins or a column if any line runs past ~90 characters)? Is the line spacing at least single, ideally a touch more? Left-aligned, ragged-right (drop forced justification)?
2. White space and hierarchy. Do your headings look like headings—unmistakably bigger/bolder than body text, with more space above than below? Are paragraphs short with visible space between them? Are the margins generous enough that the page breathes? Are related items grouped and unrelated ones separated (proximity)?
3. Emphasis. Have you over-emphasized? Strip emphasis back to the one or two genuinely most important elements (your key finding or recommendation). Plain body text everywhere else.
4. Accessibility. Are your headings real headings (so the hierarchy is semantic, not just visually styled)? Is any information carried by color alone—if so, add a second cue (label/icon)? Does your body text have sufficient contrast (no light gray)? Does every figure/table have an interpreting caption that doubles as alt-text (Ch 9)?
5. Template, if you used one. Did you adapt it to your content's structure, or just dump text in? Make the structure yours; let the template own the pixels.

Deliverable: your technical report, now with a deliberate design—readable typography, visible hierarchy, restrained emphasis, and verified accessibility. Keep the pre-design version for comparison; seeing the same content "before design" and "after design" is part of the learning, and you'll want it for the Chapter 40 growth narrative.

Next chapter (Ch 11, citing sources) turns from how the document looks to how it credits its sources—the integrity layer of technical writing: citation styles, paraphrasing honestly, and avoiding plagiarism. Your report is now clear, structured, and well-designed; next we make sure it's also honest about where its information came from.

10.8 Common Mistakes and Practical Considerations

Mistake 1: Treating design as optional polish. "The content is solid; I'll format it if I have time." The reader meets the visual surface first and judges before reading (§10.1). Hostile layout means solid content goes unread. Design is part of delivery, not an extra.

Mistake 2: Type too small, lines too long. The two most common typographic errors, usually committed together to "fit more on the page." Both punish the reader's eyes. Fix: bigger type, shorter measure (constrain the width). If it won't fit, cut words (Ch 3) or add a page—don't shrink the type.

Mistake 3: No white space. Edge-to-edge, single-spaced, no paragraph gaps, no margins—the wall of text (§10.1). White space groups, separates, and rests the eye; its absence reads as a data dump. Add margins and paragraph spacing; resist filling every inch.

Mistake 4: Over-emphasis. Bolding, coloring, and highlighting so much that nothing stands out (§10.5). Emphasis works only by contrast. Restrict it to the one or two most important elements; plain body text otherwise.

Mistake 5: Color as the only signal. Red/green status with no labels—invisible to color-blind readers and grayscale printouts (§10.5–§10.6). Always pair color with a label, icon, or shape. Use color-blind-safe palettes.

Mistake 6: Fake headings and low contrast. Big-bold styled text that isn't a real heading (invisible to screen readers); light-gray "modern" body text that fails contrast (§10.6). Use real heading styles; keep body text high-contrast.

Mistake 7: Dumping into a template thoughtlessly. Leaving default sections, never applying the document's own hierarchy—the real cause of "generic" (§10.7). Adapt the template to your content; supply your own structure of meaning.

It depends — when to spend more (or less) on design. Design effort should scale with stakes and audience. A throwaway internal Slack note needs almost none (white space and brevity suffice). A client-facing proposal, a published paper, a public-facing document, or anything that represents you to people who don't know you—spend the effort, because first impressions are doing real work and the audience is judging your competence partly by your document's care. A document read under stress or for safety (instructions, medical, Ch 22/36) needs design as function, not aesthetics—clear separation prevents errors. Match the investment to how much the document matters and how it will be read.

A note for multilingual writers. Design is a great equalizer. A clean, well-spaced, well-structured layout reads as professional and competent regardless of small wobbles in idiom, exactly as good structure does (Chapter 4). Readers extend more goodwill to a clearly-designed document, and visual hierarchy helps a reader (and you) follow the logic even when the prose isn't perfectly native. Invest in layout—it's rule-based, learnable, and pays a high return, and unlike idiom, the rules are explicit and the same in every language.

Frequently Asked Questions

Should I use a serif or sans-serif font for my document?

For body text, either works—choose a well-made, readable typeface and a reasonable size, and the serif-vs-sans choice barely matters compared to type size, line length, and line spacing. The old "serif for print, sans-serif for screen" rule has a historical basis but isn't a strong constraint with modern screens and fonts. Practical advice: pick one readable typeface for body text, optionally a second (often a sans-serif) for headings, and don't use more than two. Avoid decorative or novelty fonts for body text. Spend your attention on size (bigger), measure (shorter lines, ~45–75 characters), and leading (a bit more than single)—those drive readability far more than serifs.

What is the ideal line length for readable text?

Roughly 45 to 75 characters per line (about 8 to 15 words), with the mid-60s often cited as a comfortable target. Lines much longer than that make the eye's return sweep error-prone (you re-read or skip lines); much shorter chops the text up. The most common technical-writing mistake is letting body text run the full width of a wide page or screen—well past 100 characters. Fix it by constraining the width: add margins, use a column, or set a max-width on a web text container. This single change usually gives the biggest readability gain for the least effort.

How do I make a document accessible to people who are color-blind?

Two rules cover most of it. First, never use color as the only way to convey information—pair every color code with a second cue (a text label, an icon, a distinct shape). A "red = overdue, green = on track" table must also say "Overdue"/"On track" or use different icons, so readers with red-green color vision deficiency (about 1 in 12 men) and anyone reading a grayscale printout can still extract the meaning. Second, choose a color-blind-safe palette when you must categorize by color—avoid red/green pairings; blue/orange is far safer—and ensure colors differ in more than hue. Bonus: keep sufficient contrast (see below), which helps low-vision readers too.

What contrast ratio do I need for text to be readable?

Follow the WCAG guideline: normal body text should have a contrast ratio of at least 4.5:1 against its background; large text (about 18pt+, or 14pt+ bold) can pass at 3:1. The ratio runs from 1:1 (invisible) to 21:1 (black on white). You don't eyeball it—use a free contrast-checker tool by entering the two colors. The practical lesson: don't set body text in light gray or pale colors to look "subtle" or "modern"; that's unreadable for low-vision readers and tiring for everyone. Dark text on a light background (or vice versa) with a comfortable ratio is the safe default.

How do I use a template without my document looking generic?

"Generic" usually comes from dumping content into a template thoughtlessly, not from templates themselves. Use the template for what it's good at—typeface, sizes, margins, color palette, often accessibility—but supply your own structure of meaning on top: delete sections you don't need, add ones you do, write informative headings specific to your document (not "Section 1/2"), and emphasize your key finding. Distinctiveness in technical writing should come from clear content and structure, not visual flourishes—the most respected technical documents (journal articles, RFCs) use rigidly standard templates and are distinguished by their thinking. Let the template own the pixels; make the substance yours.

Chapter Summary

Key Takeaways

• Design is part of communication, not decoration. The reader judges the visual surface—and decides whether to engage—before reading a word (the flinch test). A well-written document in a hostile layout goes unread. This is the threshold concept: design carries meaning.
• Typography: bigger type, shorter lines, looser spacing. The serif-vs-sans choice barely matters; size (≥~11pt/16px), line length (~45–75 characters), and leading (a touch more than single) drive readability. Left-aligned, ragged-right is the safe default. Monospace for code.
• White space and hierarchy turn a block into a page. White space groups and separates (proximity) and rests the eye; generous margins frame content and shorten lines. Make heading levels look obviously different (size, weight, space), with more space above a heading than below.
• Emphasis works only by contrast. Emphasize one or two things, not twenty; over-emphasis cancels itself. Bold sparingly, italics for real uses, no underline-for-emphasis on screen, ALL CAPS only for tiny labels.
• Design for everyone (accessibility): sufficient contrast (≥4.5:1 body text), never color alone (pair with label/icon/shape; use color-blind-safe palettes), and real semantic structure—real headings, real lists, alt-text on images, meaningful link text—so screen readers can navigate. Most accessibility is just good design done properly; the same heading hierarchy serves sighted scanners and screen-reader users alike.
• Templates are a gift; use them well. Let the template own the pixels (type, margins, palette); supply your own structure and emphasis. "Generic" comes from thoughtless filling, not from templates. Distinctiveness comes from clear content, not flourishes.

Action Items

1. Run the typography check: type size, line length, line spacing, kill forced justification.
2. Add white space and make headings visibly distinct (size/weight/space, more space above).
3. Strip emphasis back to the one or two things that matter most.
4. Verify accessibility: real headings, contrast ≥4.5:1, no color-only meaning, alt-text on figures.
5. If using a template, adapt it to your content rather than dumping text into it.

Common Mistakes

Design as optional polish · type too small and lines too long · no white space (the wall of text) · over-emphasis · color as the only signal · fake headings and low contrast · thoughtless template use.

Decision Framework: a fast pre-send design check

Spaced Review

A few questions reaching back, to strengthen retention.

1. (From Chapter 8 — paragraphs) This chapter argued that a gap (white space) between groups of items signals "these belong together / these are separate," much like a paragraph break. Chapter 8 said technical paragraphs should be shorter than people think. Connect the two: why do short paragraphs with visible space between them serve the same reader goal that white space serves in §10.3, and what is that goal?
2. (From Chapter 4 — structure) §10.6 insists you use real headings (semantic), not text that's merely styled to look big and bold. Tie this back to Chapter 4's claim that screen-reader users "navigate by heading." Why is a fake heading (big bold body text) worse than useless for a screen-reader user, even though it looks fine to a sighted reader?
3. (Bridging — Ch 9 + this chapter) Chapter 9 taught that a caption should interpret a figure (say what it means), not just label it. §10.6 says every figure needs alt-text that conveys what the figure shows. Are these the same instinct or two different requirements? Explain how a single figure should handle both, for a chart of quarterly churn.

What's Next

Your report is now clear (Ch 3), structured (Ch 4), produced through a sane process (Ch 5), and visually designed to be read (this chapter). One layer remains before it's trustworthy: where did its information come from, and did you credit it honestly? Chapter 11: Citing Sources and Avoiding Plagiarism covers the integrity foundation of technical writing—the major citation styles (IEEE, APA, Chicago, ACS) and when each is used, how to paraphrase honestly instead of "patchwriting," reference managers like Zotero, and the gray areas that trip up honest writers (including AI-generated text). Good design makes a document inviting; honest citation makes it credible. Both are part of writing that readers can trust.

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