Why the words decide whether people finish

A customer opens a transfer screen. The heading says Initiate transaction. The fields are labelled Beneficiary account, Beneficiary institution and Narration. At the bottom is one button: Proceed.

She hesitates over that button. Does Proceed send the money now, or show her a summary first? If she taps it and it sends ₦20,000 to the wrong person, there's no getting it back. So she closes the app and walks to the banking hall instead.

Nothing was wrong with the layout, the colours or the code. The words stopped her. This module is about writing the words in an interface, and this first lesson is about why they matter as much as anything you draw.

Words in this lesson

Words are part of the interface

Look at any screen and remove every word. What's left is boxes and colours that nobody can use. The words are what tell people:

• where they are (headings, navigation labels),
• what they can do (buttons, links),
• what to enter (labels, hints),
• what just happened (confirmations, errors), and
• what to do next (instructions, empty states).

That's why this module treats writing as design work, not decoration added at the end.

People don't read, they scan

In 1997, Jakob Nielsen published a study of how people read websites. 79% of test users always scanned any new page, and only 16% read word by word.

In the same research, NN/g rewrote one website several ways and measured how usable each version was, compared with a promotional original:

The study is old, and it tested websites rather than apps. But the lesson has only become more important on phones, where screens are small and attention is short: fewer, clearer words make products easier to use, and you can measure the difference.

From the same research, NN/g recommend:

• meaningful sub-headings, not "clever" ones
• bulleted lists
• one idea per paragraph
• starting with the conclusion
• half the word count, or less, of conventional writing

What changes when you fix the words

Here's the transfer screen again, rewritten using ideas you'll practise in this module:

And on the review screen: Send ₦20,000 to Adaeze Okafor. There's no doubt left about what the button does.

Voice and tone

Every product's words have a personality, whether anyone planned it or not.

NN/g describe four dimensions of tone of voice, each a scale between two ends:

Your voice stays the same across the product. Your tone shifts with the moment. A welcome screen can be warm and a little enthusiastic. A failed payment must be calm, serious and clear.

NN/g warn that if people are frustrated when they see a message, or see it often, a humorous tone might be irritating. GOV.UK's Design System goes further for error messages: don't use humorous, informal language like "oops". Nobody whose money has disappeared wants a joke.

The best way to know which tone works, NN/g say, is to test with your users.

Design with real words from the start

The most common beginner habit is to design a screen full of "Lorem ipsum" and "Button", then add the words at the end. It causes three problems:

1. Real words don't fit. "Button" is 6 letters. "Save and come back later" is 24. The layout breaks.
2. You design the wrong thing. You can't tell whether a screen makes sense until you've written what it says.
3. Nobody tests the words. The part people struggle with most never gets checked.

So in this module, you'll write first, or at least write alongside sketching:

1. List what the screen must tell people, in plain sentences.
2. Write the heading, labels, button and any messages.
3. Read them out loud. GOV.UK's guidance for error messages suggests exactly this: read the message aloud to see if it sounds like something you would say.
4. Then design the layout around the real words.

Common mistakes

The short version

• Words tell people where they are, what they can do, what to enter, what happened and what to do next. They're part of the interface.
• NN/g (1997): 79% of users scanned new pages; only 16% read word by word. Concise, scannable, objective writing combined was 124% more usable.
• NN/g's four tone dimensions: formal–casual, serious–funny, respectful–irreverent, matter-of-fact–enthusiastic. Voice stays consistent; tone adapts to the moment.
• No jokes when people are frustrated. GOV.UK advises against "oops" in error messages.
• Write real words first, read them aloud, then design around them.

Try it yourself

1. Choose one real Nigerian app you use. Screenshot three screens, and list every word on them.
2. Circle every word or phrase a customer might not understand, or might hesitate over.
3. Rewrite the words on one of the screens. Keep the same features, but change only the words.
4. Describe your product's voice in three short phrases, such as "clear, calm, friendly". Then write how its tone should change for a welcome, a success and a failed payment.
5. Take your Module 6 key screen, and replace any placeholder text with real words. Fix anything in the layout that breaks.
6. Read every word on that screen out loud to someone else. Change anything that made them pause.

You'll know you've got it when every button on your screen says what will happen, nobody you show it to hesitates over a word, and your error messages sound calm rather than cute.