Overhaul Every Error and Empty State

Workflow area: Content & UX Writing · Tier: Core · Hands-on time: ~35 minutes

Error and empty states are written at the end of every project, by whoever is left, in whatever tone survives the deadline. The result is archaeological: five eras of apology stacked in one product, "Oops!" next to "Error 4092: transaction failed." Nobody has time to rewrite two hundred states by hand — which is exactly why this is one of the highest-leverage AI content jobs in design. The model drafts against a rubric at scale; you judge tone and truth.

When to use — and when not to

• Use it when support tickets quote your error messagesusers pasting "something went wrong" into tickets means the message did no work; the rewrite pays for itself in deflected tickets.
• Use it before a major release or design-system migrationyou are touching every screen anyway; touch the words too.
• Use it when a content designer joins an established productthe inventory is the fastest possible map of the product's worst moments and inherited debt.
• Skip it one string at a timea single error rewrite doesn't need this machinery; the playbook's value is batch consistency across a whole surface.
• Skip states whose cause you can't explainif engineering can't tell you why an error fires, the honest fix is upstream; no copy rubric can make an unexplained failure feel explained.

The recipe

1. 1.

   Build the inventory before touching a word. Sweep the surface — Figma files, string files, and the live product — and list every error and empty state with: string ID or screen, current copy, trigger (what actually causes it), and whether the user can fix it. Ask engineering to export error strings from code; design files always miss states that only exist in exception handlers. Expect the count to be 3–4× your guess.

2. 2.

   Adopt the rubric. Every state must answer three questions in plain language: what happened, why (if the cause is known and useful), what to do next. Plus tone rules: no blame, no double apology, no humor in destructive or money-touching moments, and error codes visible but subordinate. Empty states get a variant rubric: orient ("what this area is"), then one action ("how to fill it").

3. 3.

   Rewrite in batches of 15–20 with full trigger context. Paste a batch with this prompt:

   Copy

   You are rewriting error and empty states for [PRODUCT]. Rubric:
   1) Plain language a stressed non-technical user understands.
   2) State what happened, the cause if known, and the next action.
   3) No blame, no double apology, no exclamation marks, no humor
      in destructive or payment contexts.
   4) Keep error codes, but subordinate: body text first, code last.
   5) Titles max 50 chars, body max 160, button labels name the action.
   
   For each item below, return: NEW TITLE / NEW BODY / BUTTON(S) /
   and a CONFIDENCE note — flag any item where the trigger info given
   is too thin to write an honest next action, instead of inventing one.
   
   ITEMS
   ID: ERR-114 | Current: "Something went wrong" | Trigger: payment
   processor timeout, retry usually works | User can fix: yes, retry
   ID: EMPTY-07 | Current: "Nothing here yet!" | Trigger: new user,
   no invoices created | User can fix: yes, create invoice
   [PASTE 15–20 ITEMS]
   

   Good output looks like this:

   Copy

   ERR-114
   Title: Payment didn't go through
   Body: The connection to our payment provider timed out. Your card
   wasn't charged. Trying again usually works. (Code ERR-114)
   Buttons: Try again · Use a different card
   Confidence: OK — trigger and recovery are clear.
   
   EMPTY-07
   Title: No invoices yet
   Body: Invoices you create will appear here, ready to send.
   Button: Create an invoice
   Confidence: OK.
   

4. 4.

   Review each batch against truth, not just tone. The dangerous failure is a fluent lie: "Your card wasn't charged" is only good copy if it is true. For every rewritten error, confirm the stated cause and next action with engineering or docs. Mark each string keep / edit / escalate — escalate meaning the copy exposed a design or engineering problem the words can't solve.

5. 5.

   Land the strings and the debt list. Update the Figma components and the string files, then hand the escalation list to the team: unexplainable errors, dead-end states with no recovery action, empties with nothing to offer. The rewrite makes the copy honest; the escalation list makes the product better.

Make it yours

• Claude Project with the rubric pinned: put the rubric, tone rules and ten best rewritten states in a Project's instructions so every future error written by anyone on the team starts from the same standard — this is the natural companion to your pb-27 voice engine.
• Frontitude for the in-Figma pass: run the rewrites where the text layers live, and sync the approved strings to the copy library so the next file reuses them instead of re-inventing "Oops."
• Screenshot-first for legacy surfaces: where no string inventory exists, screenshot each state and let a multimodal model transcribe copy, guess the trigger, and build the inventory table for you — then verify triggers with engineering before rewriting.

Quality check

• The inventory came from code and canvas botha design-file-only sweep misses the states only exception handlers know about.
• Every rewritten error states a true cause and a real next actionverified with engineering, not inferred by the model; fluent guesses are the failure mode.
• No invented recovery"Try again" is only a next action if retrying can work; a confident dead-end is worse than an honest one.
• Tone matches stakesscan the batch for humor or breeziness inside destructive, payment or data-loss moments; the model reverts to cheerful under pressure.
• The escalation list left the documentstates you flagged as design problems became tickets, not footnotes.