313. The reader's own words

The product team calls it “contour direction normalization”. A forum thread from last spring calls it “my cutter goes round the letter twice”. The second phrase will never appear in a menu. It is still the better headline, because it is the sentence the reader typed when they went looking for help.

Readers search, scan and decide in their own vocabulary. Copy written in the company's vocabulary asks them to translate before they can recognize themselves. This chapter is about collecting the reader's words, checking them and using them without putting words in anyone's mouth.

Why the maker's knowledge misleads

The people who build a product know it from the inside: how it is implemented, what it was called during development, which part was hardest to make. That knowledge is necessary for accuracy and unreliable for marketing. Readers meet the product from the outside, with a job to do and a word for that job. The feature the team is proudest of may not be the one buyers mention. The problem buyers mention most may sit in a dialog the team considers minor.

So listen before writing. The listening is cheap and the sources are already there.

Where to listen

Support mail. Every repeated question is a sentence the product page did not answer. Review it regularly for repeats, for competitors named, for the words people use to describe a symptom. A question asked three times deserves a help page; the question asked most this month is a candidate for the month's article, email and video.

Forums and Q&A sites. Look for people describing problems in their own words, not people giving advice. Search a forum for a topic and a question mark. Read the replies too: they show what people tried and why it failed.

Comments under tutorials. The comments under a video often hold more reader language than the video itself. They also show what confused viewers.

Reviews, ours and others'. Reviews of the tools readers compare us with show which expectations went unmet. Read for patterns, not for ammunition.

The site's own search log and the questions in contact forms, when they are available.

Conversations. A week of answering pre-sales questions personally teaches a writer more than a month of reading summaries.

Use public material and material people sent to us. Respect each site's terms. Strip personal data before sharing anything internally.

Keep a phrase bank with provenance

Record what you find in a simple table:

Phrase (verbatim)	Where	When	What it is about	Writer's note
“my cutter goes round the letter twice”	[forum thread URL]	2026-04	Overlapping strokes in exported SVG	Symptom, not cause
“cut file”	[comment URL]	2026-06	The exported vector file	Makers' noun
“can I sell fonts I make with it?”	support mail	2026-08	Licensing of output	Recurring; answer on license page

These rows are fictional examples. Keep verbatim words in one column and your interpretation in another. The separation matters later, when someone asks where a headline came from: a claim in the copy should trace back to the verbatim column, not to the writer's guess.

Some phrases are useful for understanding and wrong for publishing: shorthand that will not survive translation, a technically incorrect term that the page should gently correct. Record them as “noted, not used”.

Sort, count, then choose

When the phrase bank has grown, sort the entries into a few bins: what readers want, what they firmly believe, what they half believe, how they describe themselves, how they describe the problem. Count. The most frequent and most strongly felt theme is a candidate for the page's main idea. The long tail becomes FAQ entries, objections to answer and ideas for later.

Firm beliefs deserve respect. If makers firmly believe that auto-tracing ruins line quality, a page that contradicts them head-on will lose them. Show what the tool does with a real image and let them judge. Half-held beliefs are the objections worth answering with a mechanism.

Stop collecting when new sources stop adding new themes. Research has a point of diminishing returns, and it usually arrives earlier than the next round of reading suggests.

Interview about the last time

When you can talk to customers, ask about behavior rather than wishes. “What features would you like?” produces a polite list. “Walk me through the last time you prepared a family for release” produces the actual steps, including the ones they skip and the ones that take an afternoon.

Useful questions:

• What were you making, and what happened the last time it went wrong?
• What did you use before this, and what made you look for something else?
• Which step takes longest? Which one do you put off?
• If you could not use this tool tomorrow, what would you do instead?
• What would have to be true for you to recommend it to a colleague?

Ask for permission to record and to quote. Polite enthusiasm is a lead, not evidence; continued use and payment say more than praise. Write down the words people use for their own work, exactly.

Stop collecting phrases when ten further sources bring no new theme; more reading after that refines wording, not the message.

When you cannot talk to customers, a short survey can stand in. Ask recent buyers one question with fixed choices first: how they heard of the product, or whose advice they followed when choosing. Send follow-up questions only to those whose answer makes them relevant: what the colleague said, how the buyer would describe the product to someone else. Owners who skipped an upgrade can be asked one open question, what kept them on their current version. Ask only what you will act on, one subject per question, in plain words, without leading or loaded phrasing. Offer nothing in return for a quotable sentence; a rewarded testimonial is advertising.

Use the words, not the speakers

The reader's words belong in headings, opening lines and FAQ questions:

Company vocabulary: Contour direction normalization for plotter output

Reader vocabulary: Why your cutter goes round a letter twice, and the fix

Keep exact interface labels where the reader must act. The heading can use the reader's phrase while the step names the actual control.

What you must never do is turn the reader's words into a testimonial. A phrase from a public thread is not an endorsement. A paraphrase is not a quotation. A composite of three customers is not a customer. If you want to quote someone, ask them, quote them exactly and attribute them as they approve.

Write the message before the copy

The phrase bank feeds a message document: a page written before any copy, in plain sentences. It answers what the product does and how, then five questions:

1. Why would this reader consider it?
2. Why ask us?
3. Why change what they use now, including doing nothing? (Never invent a cost of staying put.)
4. Why this product rather than another?
5. Why now, if there is a true reason?

Every answer must be provable. The fifth is often empty, and empty is an acceptable answer. Filling it with pressure is not.

Then compress the message: say it in a hundred words, in fifty, in ten. The ten-word version is the test. A section that does not serve it belongs on another page. A one- or two-sentence positioning statement should let a reader who is not served rule themselves out; if a colleague outside the team cannot restate it, rewrite it.

Some messages have two readers: the person who uses the tool and the person who approves the purchase. Write for each in their own vocabulary, in separate sections. The approver needs a forwardable block: price, seats, compatibility, terms.

Test the words on a reader

Before publishing a page that matters, show its opening to one person who matches the reader. Ask what they think the product does and what they would do next. If their answer is not the page's ten-word message, the opening has not said it yet. Record what they actually said; silence is not rejection and politeness is not intent.

Practice: from thread to heading

Use this fictional set of phrases, gathered from public threads about a line-art app:

• “the SVG has thousands of tiny pieces”
• “my laser engraves the same line twice”
• “can I edit the lines after?”
• “does it work from a phone photo?”

Sort them into bins. Choose the one that most readers share and feel most strongly about. Write a help-page heading in the reader's words, then a first sentence that answers it, marking any missing product fact with [CONFIRM: behavior]. Then write a message document for the app in a hundred words and compress it to ten.

For the second pass, check that every claim in your heading and first sentence traces to a supplied phrase or a confirmed product fact. Remove any sentence that presents a reader's phrase as praise.

Checklist

• Research came before drafting, from support mail, forums, comments, reviews and conversations.
• Verbatim phrases, sources, dates and interpretations are recorded separately.
• Themes are sorted and counted; the main idea comes from the strongest shared theme.
• Firm beliefs are respected; half-held beliefs are answered with mechanisms.
• Interviews asked about past behavior, with permission to record and quote.
• Headings and openings use the reader's words; steps use exact interface labels.
• No paraphrase, composite or public phrase is presented as a testimonial.
• A message document answers the five questions, and an empty answer stays empty.
• The message compresses to ten words, and every section serves it.
• The opening was tested on a matching reader, and their actual answer was recorded.
• Buyer surveys ask one question with fixed choices first; follow-ups go only to those whose answer makes them relevant, and nothing is offered in return for a quotation.