UX4: Journeys and information architecture
Content design: plain words on screen
🎯You'll be able to
Write headings, labels, buttons and messages in plain language that people understand at a glance.
🏠The everyday picture
A good bus conductor shouts the stop names, not the route code. Words on screen should be the ones people already use.
📘What it really is
- Content design decides what words appear, where, and why. Words are part of the interface, not decoration.
- Plain language: short sentences, common words, active voice. "Choose a time", not "Slot selection".
- Users' words: research shows them. P1 didn't understand "OPD"; "walk-in clinic hours" is clearer.
- Buttons say what happens: "Book appointment" rather than "Submit"; "Clear search" rather than "Reset".
- Labels and hints: the label names the field; a hint gives format or reason ("10 digits. The clinic sends a reminder by SMS.").
- Error messages: say what's wrong and how to fix it, without blame. "Enter your mobile number as 10 digits", not "Invalid input".
- Front-load: put the important word first, because people scan.
- Languages: plan for translation from the start; leave room for longer words, avoid text inside images, and write so that a translator can understand each string out of context.
📝A worked example
Input: words in the starter.
| Starter | Problem | Rewrite |
|---|---|---|
| "Book OPD" | Jargon (P1) | "Book a doctor near you" |
| "Go" | Doesn't say what happens | "Search" |
| "Submit" | Doesn't say what happens | "Book appointment" |
| "Done!" | Doesn't confirm what was booked | "Your appointment is booked" and a summary |
| Placeholder "Phone" | Disappears; no format | Label "Mobile number", hint "10 digits. The clinic sends a reminder by SMS." |
Expected output: a content table for every screen, reviewed by reading it aloud.
🌍Where it's used
- Government services that publish style guides with plain-language rules.
- Banks, where unclear words on a transfer screen can send money to the wrong person.
- Health apps, where medical terms are explained or replaced.
📝Case scenario
An insurance app's claim button said "Initiate claim intimation". Calls to the helpline asked what it meant. Changed to "Make a claim", the button was used three times as often in the following month.
🖱️Try it
Rewrite these: (a) "Authentication failed", (b) "Proceed", (c) "Kindly furnish your contact number", (d) "No data". Success: each is plain, says what to do or what happens, and would make sense to someone who hasn't used the app before.
⚠️Common mistakes
- Internal jargon. Sign: words from the organisation, not users. Fix: use research quotes and test labels.
- Vague buttons. Sign: "OK", "Submit", "Proceed". Fix: say the action.
- Blaming messages. Sign: "You entered an invalid number". Fix: "Enter your mobile number as 10 digits".
🛠️For your project
Project 2's tests 4 and 5 look for messages that tell people what to enter, and the reference design replaces every starter word in the table above.
✅Quick check
What should a button label say?
Show the answer
What will happen when it's pressed, such as "Book appointment".
What makes a good error message?
Show the answer
It says what's wrong and how to fix it, in plain words, without blame.