Writing Clearly

Count up an honest working day. The Slack threads, the ticket descriptions, the design rationale, the feedback on somebody else's work, the email to the client, the comment on a pull request. For a lot of designers, the hours spent writing beat the hours spent in the design file.

Clear writing makes designers easier to hire. Learn it by ear, wherever you are.

Listen to the full Writing Clearly course on DesignPath
Share
A single sharpened pencil tip on a plain gray background
Share

That writing carries more of your design than it feels like it should. A good flow described in a vague ticket gets built wrong. A sharp decision buried on page two of a doc gets ignored, and the version that ships is whatever the engineer assumed you meant.

So the words are part of the craft. Most people can recognize clear writing and can't produce it on demand, because recognizing is passive and writing is a set of moves. This module gives you the moves: a structure to hang a document on, and an order to put its parts in. It ends with an edit pass that catches what you stopped seeing.

Structuring a Document

You open a blank doc to write up a decision and start typing at the top. Twelve hundred words later there's a lot of background, two paragraphs of options, and a recommendation somewhere near the end that you're no longer sure you believe.

Then somebody comments "what are you actually asking for?" on paragraph nine. They're right, and the problem happened before the first sentence. The document was structured while it was being typed, which means it wasn't structured at all.

Outline Before You Write

Write the headings first, with nothing underneath them. It takes about five minutes and it's the cheapest edit you'll ever make, because moving a heading costs nothing and moving four finished paragraphs costs an afternoon.

That order also surfaces the gaps. A list of headings reading Background, More background, Some options, Conclusion is visibly missing the thing the reader came for. You can see that before you've written a word you'd be sad to lose.

Minto's Pyramid

The most useful structure for work writing came out of consulting. Barbara Minto was the first woman McKinsey hired into its consulting staff, in 1963, and she spent years working out why the firm's reports were so hard to read. She published the answer as The Pyramid Principle in 1978.

Her rule is that ideas stack in a pyramid, and you deliver it from the top down. The single answer goes first. Underneath it sit the two to four arguments that support it, and underneath each of those sits the evidence. Every level is a summary of the level below, so any reader can stop at whatever depth they have time for and still have something complete.

That inverts how most people write, because thinking runs bottom-up. You gather evidence, you group it, and a conclusion emerges. Minto's point is that the reader doesn't need to repeat your journey, and making them do it is the single most common reason a document wanders.

She added a grouping test that's worth stealing on its own: MECE, mutually exclusive and collectively exhaustive. Your three supporting arguments shouldn't overlap each other, and together they should cover the case. Two overlapping arguments make a reader wonder whether they've missed a distinction, and a gap makes them supply their own objection.

SCQA, the Four Lines That Open Anything

Minto also gave the opening a shape, which she called SCQA.

  • Situation: the part your reader already agrees with. "Checkout converts at 61% on desktop."
  • Complication: what changed, or what's wrong. "On mobile it converts at 34%, and mobile is now two-thirds of traffic."
  • Question: the question the complication forces. "What's costing us the mobile conversions?"
  • Answer: your answer, stated flat. "The address form. Cutting it from eleven fields to five recovers most of the gap."

The order matters because it builds agreement before it asks for any. Starting at the situation gives the reader something to nod at, and the complication makes the question theirs rather than yours by the time you reach it.

Matching the Shape to the Document

The pyramid holds everywhere and the proportions change with the job.

  • A decision doc puts the recommendation in the first two lines, the options considered underneath, and the detail last. Somebody reading only the top should be able to approve it.
  • A status update is answer-only. What's done, what's next, what's blocked, whether the date still holds.
  • A spec front-loads the intent in a paragraph and then goes deep, because its readers arrive at different sections on different days.
  • A research readout leads with the finding rather than the method, and the method goes in an appendix for the two people who'll check it.

Because a document is read by people with different amounts of time, write so it can be abandoned. A reader who stops after the first paragraph should still know what you want. A reader who stops after the headings should know why.

Pro tip: When you finish a draft, delete every paragraph sitting above your recommendation and read what's left. If the document still makes sense, that material was throat-clearing and you've just found your real opening.

Found this useful? Pass it on.
Share