How I write interface copy.

Write from the person's side of the screen

Copy written from the system's side sounds like it was written for the team that built it. Name things by what people see and control, not by how they work underneath: people manage notifications, not webhook settings. Labels speak to the person, so they say your, not my. The product is the one talking, so it never puts words in the person's mouth.

A button says what it does, and keeps that name through the flow

A button label says what will happen, in the person's words. The same word carries through the whole flow. If the button says Publish, the confirmation says Published, not Your submission was successful. Avoid Submit: it describes what the form does to a database, not what the person came to do. People learn their way around a product by these verbs, so keeping them the same helps people find their way.

The verb on the button comes back in the confirmation. Send invites becomes Invites sent, so the person sees their action confirmed in the same words.

Name the action, not the thing being avoided

Label a setting by what it does, not by what the person wants to avoid. Ask what decision the person is making, then name that. This is not about sounding cheerful. It is about telling the person what will happen, in the words they would use themselves.

Each stronger line names the action the setting performs. The weaker lines describe a complaint, so it is unclear what the control actually does.

Use please, thanks, and sorry only where they are earned

Courtesy words wear out when you repeat them. A please on every screen of a long flow stops sounding polite and starts sounding like filler. Say thanks when the person did something to help the product, not just themselves. Say sorry when the product caused them trouble, like making them redo work after something failed on our side. Everywhere else, the plain instruction is enough.

• Fill out this form. A plain instruction does not need a please. The person is already here to do it.
• Thanks for the feedback. Earned. The person spent their time helping improve the product.
• Something went wrong on our end. Fill out the form again. A sorry is earned here, because the redo is the product's fault, not theirs.

Errors and empty states say what happened and what to do next

An error says what went wrong and how to fix it, in the product's voice. It does not hide behind an apology, and it is specific about what failed. An empty state works the same way: it tells the person what to do first and what they will get. People see these screens when they are stuck or just starting, so clear words matter most here.

Small habits that make copy easier for everyone to read

These habits sit under all the rules above. They work with screen readers, translate cleanly, and are easy to scan.

• Write ranges with to, not a dash. Write 1 to 3 business days. Screen readers read the word clearly, but not always the dash.
• Use bold for emphasis, not italics. Italics are harder to read at small sizes and on lower resolution screens. Bold the name of a page or control when you mention it in text.
• Use sentence case everywhere. Titles, section labels and buttons. Title case is harder to read, and all caps reads as shouting.
• Use numerals, not spelled out numbers. Get 5 leads, not Get five leads. Numerals are easier to spot when scanning.
• Name the action, not the gesture. Open file, not click here. Not everyone uses a mouse, and a link that says where it goes is easier to find and skim.
• Log in is a verb, login is a noun. Two words for the action, one word for the page. A small detail that keeps labels accurate.

Use one word for one thing across every screen

The most common cause of confusion in a product is not a badly written sentence. It is one thing called by three names on three screens. If it 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 list of the agreed terms for each product and stick to it. People learn a product through its words, and every new synonym makes them learn it again.

How I use these rules on a project

I bring these rules to every project as a working reference, the same way I bring a design system. They matter most when the words carry real weight. An interview coach like Criterion has to tell someone their answer fell short without making them feel judged. That needs the error rule and the framing rule at once. A compliance agent like Conformly has to state a problem plainly and give the fix, which is the error rule under pressure. The rules stay the same from product to product. What changes is how much is at stake.