Microcopy Is Design: The UI Text Players Actually Read

A playtester picks up the Ember Dagger, opens the equip menu, clicks, and the game says:

Requirements not met.

She tries again. Same message. She shrugs, drops the dagger, and keeps swinging the starter sword for the next forty minutes. In your build notes this becomes "tester ignored the fire weapon." It was never a weapon problem. The dagger needs 12 Dexterity, she had 9, and nothing on screen said so.

Microcopy — the handful of words on buttons, tooltips, denial messages, objective titles and item cards — is the layer where your systems either become legible or stay private. It is usually written last, by whoever is closest to the keyboard, and it is the cheapest thing in your game to fix. Here is a workflow for treating it as design work instead of filler.

Make an inventory of your strings first

You cannot improve text you have never listed. Before rewriting anything, spend an hour enumerating every surface where your game speaks to the player. For most small projects it comes out to eight:

1. Buttons and menu labels — Continue, New Game, Options, Rebind
2. Objective and quest titles — the one line in the HUD tracker
3. Item and ability names plus their descriptions
4. Denial and error messages — can't equip, can't build here, inventory full
5. Confirmation prompts — overwrite save, abandon run, spend currency
6. Status and state text — Burning, Overencumbered, Out of Range
7. Tutorial and hint lines — including the ones on your loading screens
8. Failure and results screens — death, defeat, run summary

That list is also your localization scope. If you keep item and ability text in your GameDesignerX items module and objective titles in the objectives module, you already have two of these surfaces in structured form; the gap is usually category 4 and 5, which live in code as hardcoded strings nobody owns.

Set word budgets before you argue about word choice

Most bad game text is bad because it was written without knowing how much room it had. Decide the budget per surface, write to it, and the arguments about tone get much shorter.

Surface	Budget	Why
Button label	1–3 words	Must fit a controller prompt and a translated string
Objective title	4–8 words	Read at a glance mid-combat
Status effect name	1–2 words	Appears next to an icon, often at 60% scale
Denial message	8–14 words	Must carry cause and fix
Item description	15–35 words	Mechanics line plus one flavour line
Tooltip body	25–50 words	The only place detail belongs
Loading hint	10–20 words	Readable in one pass before the screen changes

Then add the localization headroom: budget roughly 30–40% extra pixel width over your English string for European languages, and design your UI so a two-line button does not break the layout. A label that fits perfectly in English is a label that will be clipped in German.

The denial message rule: cause, then fix

Every "no" your game says should answer two questions in one sentence: why did this fail, and what do I do about it? Compare:

Before	After
Requirements not met.	Needs 12 Dexterity. You have 9.
Cannot build here.	Too close to the river — needs 2 tiles of dry ground.
Inventory full.	Pack is full (24/24). Drop or stash something first.
Not enough resources.	Needs 40 scrap. You have 18.
Invalid target.	Out of range — move 3 tiles closer.

None of these got longer than fourteen words, and none of them needed new systems. They needed the numbers the game already had. A good test: for every denial string in your project, ask whether the player could act on it with the message alone. If not, it is a bug report waiting to happen in your next playtest.

Item descriptions: mechanics first, flavour second

Players scan item cards for a decision, not a story. Put the decision on top.

Ember Dagger — Dagger · 12 Dex 9 damage. Hits apply Burn: 2 damage per second for 4 seconds. Forge-seconds, sold cheap to militia who never asked why they were warm.

The first line is the gate. The second line is the mechanic in units the player can compare to the weapon they are holding. The third is voice, and it is the only line you should be willing to cut for space. If your flavour text is doing load-bearing work — "feels unusually light in the hand" meaning +15% attack speed — move the number up and keep the poetry as decoration.

Two rules that save real pain later:

• Never state a number in prose that lives in a data table. Write descriptions with placeholders (Burn: {dps} damage for {duration}s) so a balance change does not silently make your text lie.
• Name the unit. "Faster reload" is unusable; "Reload 0.4s faster (1.6s → 1.2s)" lets a player choose.

Write a one-page voice sheet

A voice sheet is not a style manifesto. It is a lookup table that stops three people inventing three names for the same thing.

• Canonical terms: the player's money is scrap, never credits, gold or currency. The dash is a dash, never a roll or dodge. Enemies are the Hollowed, never zombies.
• Capitalisation rules: systems and stats take caps (Burn, Dexterity, Stamina); common nouns do not (pack, run, floor).
• Person and tense: second person, present ("You cannot carry this"), not "Player cannot carry this."
• Banned words: the ones that mean nothing — invalid, error, failed, unavailable, requirements.
• Numbers: digits always, including one through nine; units always attached (3s, 40 scrap, 2 tiles).

If your project already keeps a terminology list in a lore bible, extend it rather than starting a second glossary — the fastest way to get inconsistent text is to maintain naming in two places. The point is that a writer, a programmer and an artist can all answer "what do we call this?" without a meeting.

Keys, not strings

The single highest-leverage technical habit: nothing user-facing is a literal in code. Every line is a key in one table.

• Key naming that stays sortable: ui.equip.denied.stat, item.ember_dagger.desc, objective.find_the_tower.title.
• One key per concept, not per sentence fragment. Never build a message by concatenating "Needs " + stat + " to equip." — word order differs across languages, and the fragments are untranslatable alone.
• Plurals go through a plural rule, not an if (n == 1).
• Ship a comment field with each key saying where it appears and what the max length is. Translators guess otherwise, and they guess wrong.

Doing this before you have 2,000 strings costs an afternoon. Doing it after costs a sprint, which is exactly why the localization module in a design doc tool is worth filling in while the string count is still small enough to be boring.

A one-hour review pass

Run this before every playtest build:

• Every denial message names a cause and an action.
• No string contains the words error, invalid, failed or requirements.
• Every numeric claim in prose comes from a placeholder, not a typed digit.
• Longest button label still fits at 140% string length.
• Objective titles read correctly out of context, with no pronoun referring to a previous line.
• Status effect names match their tooltip names exactly.
• The results screen says what the player did, not just that they died.
• Every new key has a location comment and a length cap.

What this buys you

The practical payoff shows up in playtest notes. Sessions stop generating feedback like "I didn't know what that did" and start generating feedback about your actual systems — pacing, difficulty, whether the dagger build is fun. Text is the cheapest clarification you will ever ship: no new art, no new code, no rebalancing. It is also the layer that quietly decides whether the systems you spent three months building are visible to the person holding the controller.

Write the strings into your design document, budget them, and review them like any other deliverable. The Ember Dagger does not need to be stronger. It needs to say what it wants.