Skip to content

Empty States and Error Copy: Test Before You Ship, or Trust the Design Review?

Open a product in a fresh account and count the empty states and error messages a new user hits before finishing one task. That copy usually shipped untested. For a Head of Product weighing how much rigor first-session copy deserves, the real question is narrower: does this text change what a new or existing user does next, or does it just look fine in a design review?

Why untested copy is a real cost, not a style problem

Empty states are often the first meaningful text a new user reads after signup, whether onto a bare dashboard, an empty inbox, or an empty project list. Error messages arrive when trust is most fragile, when something has broken and the user does not know whose fault it is or what happens next.

Nielsen Norman Group's usability research finds that unclear error messages increase task abandonment and erode trust in the product and the brand, and that effective error copy needs plain language, a specific description of the problem, and a constructive next step rather than an apology (Nielsen Norman Group, "Error-Message Guidelines"). A related NN/g breakdown of the "help users recognize, diagnose, and recover from errors" heuristic makes the same point about diagnosis and recovery, not just wording (Nielsen Norman Group, "Usability Heuristic 9").

Neither source is a Subconscious result; no Subconscious-run experiment, customer result, or benchmark exists yet for empty-state or error-copy testing specifically. That gap matters: this is a smaller, more tactical call than the launch, pricing, or positioning decisions causal experiments typically inform. The case for testing rests on the cost of guessing wrong at a first-session moment, not a proven lift number.

What a controlled comparison actually isolates

Design review answers "does this look right to us." A controlled comparison answers a narrower question: does this variant change what a defined audience segment says it would do next, compared with the version currently shipping.

Testing copy against a defined segment is message and copy testing, not a broad usability study, clinical evaluation, or proof of market performance. Kept narrow, a comparison isolates three things:

Errors are not one message: they are three different situations

Most products use near-identical language across error types that call for different tone and next steps. A useful comparison separates the situations before testing the copy:

Error typeWhat happenedWhat the copy needs to do
RecoverableForm validation failedState the specific field problem and the fix
TransientA request timed outName the delay, offer retry, avoid blame
CatastrophicData loss or an authentication failureState severity plainly, give a concrete recovery path

Treating all three the same, using the generic "something went wrong, please try again," is the pattern Nielsen Norman Group's guidance argues against: it is neither specific about the problem nor constructive about the next step (NN/g, "Error-Message Guidelines").

From a simulated comparison to a real answer, without changing the question

A copy comparison against a defined segment narrows candidates fast, before anything ships. When the decision warrants it, Subconscious can also validate the same comparison with real human participants, moving from a simulated read to a real-human one without changing the underlying causal question. Use that step when the empty state or error sits on a path with real revenue or retention consequence; for most microcopy decisions, the simulated comparison alone is enough.

Where this fits, and where it does not

This stays a tactical, first-session decision. Treat any win-rate or before/after conversion figure attached to a specific copy variant as unverified unless it comes from a real test against a real segment; general claims like "one phrasing beats another" are not evidence for your audience. Run the comparison against your own defined segment rather than borrow someone else's result.

Teams that test their worst empty state or error message first, the one everyone already flags internally, get a concrete answer: keep the current copy, or ship the variant that changed what the segment said it would do. See how this fits into a broader research workflow, or how Subconscious works before scoping a first test.

Path: "Copy ready to ship" to "Design review," then "Controlled comparison" (comprehension, motivation, variant). Splits at "High-stakes path?": most ship there; high-stakes copy adds "Real-human validation."
Design review confirms copy looks right; only a controlled comparison confirms it changes what the user does next.

Ready to test the copy your team already argues about internally? Book a walkthrough or read how other teams structured a first comparison in case studies.