The words in your game: buttons, tooltips, errors and item text

Buttons name the outcome, not the mechanism

A button label should let the player predict what happens without reading anything else on the screen. Most bad labels describe the system rather than the result.

• Start with a verb for anything that acts, and use a noun only for navigation.
• Two or three words. Longer labels break in translation and in small layouts.
• Match the title of the screen it opens, so the player knows they arrived.
• Never label two different actions with the same word anywhere in the game.

The confirm dialog, where bad writing costs money

The confirmation is the highest-stakes text in most games, and the default version of it fails at exactly the moment it matters: a tired player, moving fast, pressing the button under their thumb.

1. The title asks the actual question. "Sell Ironbrand Blade?" not "Confirm".
2. The body states the consequence, specifically, including what cannot be undone and anything that is lost: "You will get 240 gold. This item is not recoverable."
3. Both buttons are verbs. "Sell" and "Keep". Not Yes and No, and never OK and Cancel, which force the player to reconstruct the question to know which is which.
4. The destructive option is not the default focus, and is not sitting where the previous screen's confirm button was.
5. Numbers appear at the decision point, not on the previous screen.
6. If the action is reversible, do not ask at all. Do it, and offer an undo. A dialog everybody dismisses is training players to dismiss dialogs.

Tooltips and item text

Item and ability text has to do three jobs and usually attempts them in the wrong order: what it does, what that means for me, and what it feels like in the fiction.

• Function first, flavour second. A player hovering an item wants to know whether to equip it. The story of the forge that made it goes underneath, in a different style.
• Numbers, not adjectives. "Greatly increased damage" is unusable. "+18% damage" can be compared.
• Compare to what they have. The single most useful thing an item tooltip can show is the difference from the equipped item, marked as better or worse in shape as well as colour.
• Explain your own vocabulary. If a stat is called Resolve, the tooltip says what Resolve does, every time, because nobody remembers eleven invented stats.
• Set a length limit and design to it. Tooltips that grow to fifteen lines get skipped whole.
• Say when it applies. Conditional effects are where confusion lives: while airborne, after a dodge, once per fight.

Errors: what happened, and what to do

"Something went wrong" tells the player two things: something is broken, and nobody thought about them. Every error message has the same three parts.

• No codes without words. Include the code if support needs it, in small text, after the sentence a human can read.
• No blame. "You entered an invalid name" becomes "Names can be 3 to 16 characters."
• No jokes in failures involving money, saves or progress. A funny error message about a lost purchase reads as contempt.
• Name the file, item or action that failed, so the player knows the scope of the problem.
• Say whether it is safe to keep playing. That is the actual question behind most error dialogs.

Empty states are writing, not blank space

The inventory with nothing in it, the friends list with nobody on it, the search that found nothing. Each of these is a screen a real player sees on their first session, and each is usually blank.

• Say why it is empty, briefly, and without implying the player did something wrong.
• Say how to fill it, with the action attached: "Complete a contract to earn your first blueprint", plus a button that goes there.
• Distinguish empty from filtered-empty. "No items" and "No items match your filters" need different text and different actions.
• Distinguish empty from broken. If the list failed to load, say so, rather than showing an empty state that makes players think their items are gone.

Voice, and where it does not belong

Games have personality and interface text is a legitimate place to express it. The line is drawn by what the player is doing when they read it.

Write it so it can be translated

Almost every rule that makes interface text easier to translate also makes it clearer in English, which is why this is worth doing even if you never localise.

1. Short strings, whole sentences. Never assemble a sentence from fragments, because word order differs and your "You found" plus item name plus "!" will be wrong in several languages.
2. No idioms, puns or wordplay in functional text. Save those for the places where a translator can rewrite freely.
3. Avoid gendered and pluralised assumptions. "1 items" is a bug; so is text that assumes the subject's gender.
4. Leave room to expand. Many languages run substantially longer than English, so any layout fitted exactly to an English label will break, as covered in designing game UI for Unity.
5. Give translators context. A note saying whether a word is a button or a heading, and what it does, prevents a whole category of wrong translations.
6. Check your font covers the languages you ship, or the fallback face will quietly undo your typography.

One word per concept

Games accumulate synonyms: currency called gold in the shop, coins in the HUD and credits in the tutorial, because three people wrote three screens. Players assume different words mean different things, and then look for the difference.

• Keep a glossary. One page, one word per concept, owned by someone. This costs an hour and saves an argument per sprint.
• Include the words you have banned, and what to use instead.
• Use it for the interface, the store page and the marketing, so the game people bought matches the game they play.
• Test your vocabulary in playtests. If players consistently call it something else, consider changing your word rather than theirs, as covered in how to run a playtest.

Interface text is read under pressure, once, by somebody who did not want to be reading. Write for that person.

A pass over your own strings

1. Export every interface string into one sheet. Most teams have never seen them in one place.
2. Find every OK, Yes, No, Submit and Confirm. Replace each with a verb and an object.
3. Find every "Are you sure?" and rewrite the title as the actual question.
4. Find every "Something went wrong" and write the three parts: what, what it means, what to do.
5. Search for adjectives in item text: greatly, slightly, massively. Replace with numbers.
6. List every name you use for each currency, resource and stat. Pick one of each.
7. Open every empty state in the game. Write the two sentences and attach the action.
8. Read every tutorial prompt out loud. Cut anything you would not say to a person.
9. Take your longest label and make it 40 percent longer. Check nothing breaks.
10. Hand the sheet to someone who has not played and ask what each button does.