There are two people reading your interface. The first is skimming, in a good mood, looking for the one thing they came for. Most design advice is written for them: clear hierarchy, obvious primary action, nothing in the way.
The second person is in trouble. Something failed, or the number on the screen does not match the number in their head, and they are now reading every word carefully, including the ones you wrote in a hurry. Almost nobody designs for this reader, and they are the one who decides whether your product is trustworthy.
The second reader is slow on purpose
When people are confused they stop scanning and start parsing. They read labels literally. They look for the exact word they saw on the previous screen, and when it is missing they assume they are in the wrong place.
This is why inconsistent vocabulary does more damage than an ugly layout. If a button says Save, the confirmation says Updated, and the settings page calls it Publish, a skimming reader will never notice. A worried reader concludes that these are three different things and goes looking for the difference.
Decisions that only help the second read
Say what happened, not that something happened
"Something went wrong" is a sentence written for the developer's convenience. Compare it with "We could not reach the payment provider. Nothing was charged." The second version answers the question the reader actually has, which is almost never what broke, but what it cost them.
Keep the reader's own words on screen
After a form submits, show what was submitted. After a filter is applied, show the filter. A worried reader spends most of their effort reconstructing state that you already had and threw away.
Make the recovery as prominent as the problem
An error with no next step is a dead end with punctuation. Every failure message should sit beside the thing that resolves it: retry, edit, contact, or an honest wait.
The typography part
Reading carefully takes more visual comfort than skimming does. Line length near sixty five characters, line height with real room in it, and enough contrast that the text does not thin out on a laptop screen at an angle. Sixteen pixel body text is fine for a layout made of headlines and buttons, and slightly cruel for a paragraph somebody is trying to parse.
I set body copy at eighteen pixels for anything meant to be read rather than glanced at, and I keep the number of type sizes on a page down to four or five. A page with nine sizes is not expressive, it is undecided.
If your interface reads well to somebody who is annoyed, it will read beautifully to everyone else.
A test that takes five minutes
Pick your most important flow and break it on purpose. Turn off the network mid-submit. Enter a card that declines. Rename something to a string with an emoji and a quote mark in it.
Then read every screen out loud. Not skim, read. Most of the writing you find was placed there by whoever was closest to the code at the time, and improving it is the cheapest quality work available to you.
Written by
Ari Bennett
Software engineer and writer
I build web software for a living and write about the parts that are hard to search for: the trade-offs, the dead ends, and the small habits that make a codebase pleasant to come back to a year later. A decade in, I still keep a paper notebook next to the keyboard.
More about the writer
