The words are part of the design, so I write them on purpose.

Write from the person's side of the screen

The fastest way to make copy feel like it was written for the team that built the product, rather than the person using it, is to write from the system's point of view. Name things by what people recognize and control, never by how the thing was wired. A person manages notifications, not webhook config. Headers and labels address the person directly, so they say your, not my. The interface belongs to me and I am leading the person through it, which means I never put words in their mouth.

A control says exactly what it does, and keeps its name

Buttons are promises. The label states the outcome in the person's terms, and that same word survives the whole flow. If the button says Publish, the confirmation says Published, not Your submission was successful. Submit is a system word; it describes what the form does to a database, not what the person came to do. Active, specific verbs are the signposts people use to learn their way around, so cohesion here is not a nicety, it is navigation.

The verb on the button is the verb in the toast. Send invites becomes Invites sent, so the person sees their own action confirmed back to them in the same words.

Frame the choice, not the fear

Copy reads better when it names the action the person is taking rather than the thing they want to avoid. The test I run on a line is simple: what decision is the person actually making here? A toggle labeled by its outcome beats one labeled by a complaint. This is not relentless cheerfulness. It is choosing the framing that tells the person what will happen, in terms they would use about their own intent.

Each stronger line is a setting the person sets, phrased as the action it performs. The weaker lines describe a grievance and leave the control ambiguous.

Spend please, thanks, and sorry only when they are earned

Courtesy words lose their meaning through repetition. Across a multistep flow, a please on every screen stops reading as politeness and starts reading as filler. I reserve them for the moments that actually warrant them: thanks when the person did something for the product's benefit rather than their own, sorry when the product genuinely inconvenienced them, such as asking them to redo work after a failure on my side. Everywhere else, the instruction stands on its own.

• Fill out this form. A plain instruction needs no please. The person is already here to do it.
• Thanks for the feedback. Earned. The person gave time to help the product improve.
• Something went wrong on our end. Fill out the form again. A sorry would be earned here, because the redo is my fault, not theirs.

Treat errors and empty states as direction, not mood

An error explains what happened and how to fix it, in the interface's voice rather than a person's. It does not apologize its way around the problem, and it is never vague about what failed. An empty state is the same opportunity pointed forward: it is an invitation to take the first action, with enough context that the person knows what they will get. Both are high-value real estate precisely because the person is stuck or starting, which is exactly when clear language pays off most.

The small mechanics that keep copy readable for everyone

A set of conventions sits underneath everything above, chosen because they hold up for screen readers, translation, and quick scanning. They are unglamorous and they matter.

• Ranges use the word to, not a dash. 1 to 3 business days, not the en dash form. A screen reader announces the word cleanly, where the dash is unreliable.
• Boldface for emphasis, never italics. Italics are harder to read at small sizes and on lower density screens. Bold the name of a page or control when naming it in text.
• Sentence case everywhere. Titles, section labels, and buttons. Title case is bouncy to read and all caps reads as shouting.
• Numerals over spelled numbers. Get 5 leads, not Get five leads. Numerals are faster to catch while scanning.
• Name the action, not the gesture. Open file, not click here. Not everyone is using a mouse, and a descriptive link is easier to land on and to skim.
• Log in is a verb, login is a noun. Two words for the action, one word for the page. Small, but it keeps labels honest.

Pick one word for one thing, then never drift

The most common source of confusion in a product is not a bad sentence, it is the same concept called three different names across three screens. If a thing is a saved home in one place, it is a saved home everywhere, not a favorite here and a bookmark there. I keep a short running list of the canonical terms for a product and treat it as binding. The vocabulary of an interface is how people build a mental model, and every synonym quietly resets that model.

A standard, not a style opinion

This system travels with me onto a project as a working reference, the same way a design system travels. On a real build, the kinds of products I work on make these rules load bearing rather than cosmetic. A health coaching flow like Range has to deliver a correction without making the person feel judged, which is the failure and emptiness rule and the positive framing rule doing real work at the same time. A compliance agent like Conformly has to state a violation plainly and then hand back the fix, which is the error rule applied under pressure. The rules do not change by product. The stakes do.