UX Writing 101: Clear Words, Clear Decisions

Session 7 moves from interface actions to interface language. The central teaching point is that words are part of the product surface. They tell the user what the screen is for, what information is needed, what will happen next, what state the system is in, and how to recover from a problem.

This lecture should avoid treating writing as a beauty exercise. The question is not: Does this sound nicer? The stronger question is: Does this help the user complete the task with less uncertainty, less effort, and less risk?

The artifact is a clear interface text rewrite. It should include the original screen copy, the job of each text moment, a rewrite, a rationale, accessibility notes, terminology choices, and one product decision.

The learner should understand the difference between writing a sentence and designing interface content. Interface text has a job in a system. It sits beside layout, actions, states, data, and policy.

A useful beginner distinction is this: content design decides what content is needed and where it belongs; UX writing shapes the words people see in the interface; microcopy is the small text that helps at the exact moment of decision.

The session should also challenge a common misconception. Plain language is not childish. It is precise language chosen for the user situation. Expert users also benefit from clear, scannable, direct writing because they are busy and task-focused.

A rewrite should start from the user need. Without this, learners may make copy shorter but less useful. A short label that hides consequence is not better. A warmer error message that does not help recovery is not better.

The copy job is the bridge between product thinking and writing. For example, the job of a page title is to orient. The job of a form label is to name expected input. The job of a button is to predict an action. The job of an error is to help recovery.

For product ownership, this creates a repeatable review method: user need, copy inventory, copy job, rewrite, risk check, decision.

People often scan an interface before reading it carefully. This does not mean they are careless. It means they are looking for the fastest path to task completion.

Good interface text supports scanning by putting important words first, using descriptive headings, avoiding vague link labels, and making repeated patterns predictable.

A useful teaching exercise is to ask whether the screen still makes sense if the learner only reads headings, field labels, buttons, and links. If those elements do not carry the task, the screen may be depending on body text that many users will miss.

Plain language is often misunderstood as removing complexity. The better definition for this course is: say the necessary thing in the clearest responsible way for this user, task, and context.

Some specialist terms are necessary. The learner should not remove legal, safety, pricing, eligibility, or technical meaning just to make a sentence shorter. Instead, explain the term the first time it appears, then use it consistently.

Plain language also includes structure. A paragraph can use simple words and still fail if the important answer is buried at the end.

Headings are interface structure. They help the user scan, predict what is coming, and understand where they are in a flow. For screen reader users, headings can become a navigation map.

A good heading is descriptive enough to stand apart from the paragraph below it. It does not need to be clever. It needs to help the user recognize the task, topic, or decision.

Question headings can be useful in forms because they align with the user decision. However, they must still be clear and connected to the controls that answer the question.

Labels and hints are the copy most closely tied to successful input. A label should tell the user what information is expected. A hint should add information the label cannot carry: format, consequence, example, or context.

A common beginner mistake is to use placeholder text as the only label. Placeholder text disappears during input and can be harder to review after typing. A visible label gives the user a stable reference point.

Labels should be reviewed with errors. If the label says Delivery postcode, the error should usually repeat that language so the relationship is clear.

Action text is where writing and interaction meet. A button label is not just a word. It is the visible promise of behavior. The learner should ask: If I press this, what do I expect will happen?

Generic labels can work when the context is obvious and the risk is low. But when money, data, deletion, eligibility, or submission is involved, the label should usually be more predictive.

Link text should describe the destination, object, or result. Avoid relying on nearby text to make a generic link meaningful. Link text should still be understandable when read out of context.

State copy helps the user understand what is true right now. Empty, loading, success, warning, and confirmation messages all change the user sense of progress and trust.

The copy should not overpromise. Loading text should not say something is complete before it is complete. A success message should confirm the result and, when useful, point to the next action.

Empty states are especially useful for beginners because they show that a blank area can still teach. A good empty state explains what is missing, why, and what the user can do next.

Session 6 introduced errors as action-state behavior. Session 7 focuses on the words. A good error message should help the user recover, not merely announce that the system is unhappy.

For form errors, the message should be specific to the actual problem. Empty, too long, too short, wrong format, and disallowed characters are different problems and often need different messages.

The tone should be calm and non-blaming. If the system failed, say so. If the user needs to change something, give the next action.

Voice is the consistent character of a product. Tone changes with context. A product can have a friendly voice while using a calm, direct tone during errors, payments, deletion, eligibility, and personal data moments.

The learner should be careful with humor and personality. Personality that feels delightful in onboarding can feel dismissive during a failed payment or lost data moment.

Inclusive tone avoids judging the user, assuming identity or ability, or making the user feel blamed for a system or product limitation.

Accessibility makes UX writing more concrete. Descriptive headings and labels help users navigate, remember, and complete tasks. Labels and instructions help people understand what information is expected.

The learner should check both visible text and accessible meaning. A screen reader user should not receive a weaker or more confusing version of the task.

Copy should also avoid instructions that depend only on visual position or color, such as click the green button or use the box on the right. The instruction should refer to the meaningful label or action.

Terminology is product architecture because it shapes the mental model. When a product uses different words for the same concept, the user may wonder whether the meaning changed.

A small terms list can prevent this. The list should include the preferred term, terms to avoid, and a short explanation of the concept.

Product owners should treat inconsistent vocabulary as a real product issue. It can cause support questions, onboarding friction, and mismatched implementation across teams.

AI is useful for generating rewrite options, finding inconsistent terms, checking tone, and spotting missing copy states. But it can also produce polished copy that removes necessary meaning.

The learner should use the prompt to force structure. AI should name the copy job first, then rewrite, then explain risk. This helps prevent surface-level editing.

The human decision is essential. The learner should accept useful phrasing, adapt it to the product context, and reject anything that invents behavior, hides consequence, or reduces accessibility.

The course project example is a recommendation experience. This is a useful copy exercise because it includes product objects, filters, actions, and saved states.

The weak version says Your results, Budget, Save, and No items. None of these are completely wrong, but they are thin. They force the user to infer what kind of results, what budget means, what Save saves, and where saved items go.

The stronger version names the object and destination: recommended laptops, maximum price, save laptop to shortlist. The product decision is to improve the action and empty-state copy first because those moments affect trust and repeat use.

The studio output is a clear interface text rewrite. It should not be a random list of improved sentences. It should show system thinking: user need, copy jobs, rewrites, rationale, risk, accessibility, terminology, and decision.

For home study, the learner should collect one confusing screen and rewrite it using the same structure. The tutor should ask the learner to defend one rewrite that became longer because it preserved important meaning.

The lecture can close by reminding learners that a Product Owner with design specialist capability should be able to explain why important words are present, what they help the user do, and what product risk they reduce.