How to Write UI Copy That Communicates, Not Decorates

The cheapest usability improvement in any product is a rewrite. UI is Communication treats interface text as the primary channel of the conversation between product and user, and its lessons on copy are worth more than most redesigns.

Why does UI copy fail?

Because it is written from the inside. Teams label things with internal names (“Resources,” “Solutions”), buttons with system verbs (“Submit,” “Execute”), and errors with blame (“Invalid input”). Each of these is the product talking to itself in front of the user. McKay’s test cuts through all of it: read your copy as a first-time user who knows nothing about your system. Does it answer their question?

What are the practical rules?

• Labels are answers, not categories. “Billing history” tells users what they will find. “Management” tells them nothing.

• Buttons describe outcomes. “Get my invoice” beats “Submit.” A good button lets users predict the result of clicking.

• Error messages follow a formula. What happened, in plain words. Reassurance that the user is not at fault. What to do next. “We couldn’t save your changes. Your work is safe. Try saving again.” beats “Error 500.”

• Cut filler ruthlessly. Every word that carries no meaning dilutes the words that do.

What do teams gain?

UI copy sits at the intersection of design, engineering, and legal, which is why it is so often neglected. Treating it as communication gives writers and designers a shared standard: copy is done when a new user can predict outcomes from the words alone.

Why does Tremoloo share this book?

Because copy problems appear in nearly every audit we run, and they are the highest-ROI fixes we report. Sharing the book spreads a standard we apply daily: words are interface.

Does your product’s copy guide users or confuse them? Our content writing team can fix that.