A recording error is not just a technical status. It is a decision point for someone who may have just delivered a take they do not want to repeat.
The most useful question for an error message is: what can this person safely do next? Here is a product-design checklist for answering it without promising recovery that the application cannot actually provide.
Separate the failure from the recording
“Something went wrong” leaves two questions unanswered: did capture fail, or did a later step fail? A person needs to know whether their performance still exists before deciding to retry.
Treat these as separate states in the interface:
- No recording was captured.
- A take exists locally, but a later operation did not finish.
- A saved take exists and can be reopened.
- The application cannot confirm whether a take is recoverable.
These are proposed UX categories, not claims about every browser or recording library. Your implementation must establish which category is true before displaying it.
Write the recovery contract first
For each state, write a short contract: what remains available, what the button will do, and what the user might lose. Then make the message match that contract.
For example, if a take is still playable, a message could say: “Your take is available below. The video export did not finish. Listen to it before trying export again.” That copy is appropriate only if the player really works and retrying export does not overwrite the take.
If nothing was captured, be equally direct: “No take was recorded. Check your microphone selection, then record this line again.” Do not use “restore” or “resume” when the next action is actually a fresh recording.
Give buttons precise scopes
“Try again” can mean reacquire microphone access, repeat processing, resend an upload, or discard the current take. Those are not interchangeable actions.
Prefer scoped labels such as “Record this line again,” “Retry export,” or “Choose another microphone.” Put destructive actions apart from safe recovery actions. If replacing a take is unavoidable, explain that before the replacement starts.
Do not make reassurance outrun evidence
Avoid “Your work is safe” unless the application can substantiate that promise. A local preview may disappear if the tab closes. A completed upload may not mean the final output exists. A success animation is not a persistence guarantee.
A narrower statement is often more useful: “This take is still available in this tab.” Pair it with an actual next step, not an instruction to refresh that could remove the only accessible copy.
Test the message with a small scenario table
| Scenario | Question the UI must answer |
|---|---|
| Microphone unavailable before capture | Was anything recorded? |
| Interruption midway through a line | Is there a usable partial take? |
| Processing fails after capture | Can I listen before retrying? |
| User presses retry twice | Does another action start or is one already running? |
| User wants to leave | What remains available afterward? |
Run these checks with the actual product behavior. If the message and behavior disagree, fix the contract rather than adding more reassuring words.
Review copy alongside the interaction
I work on ChoicerVoicer, a browser-based voice-acting and dubbing project. This checklist is a general design exercise, not a claim that a particular recovery guarantee exists there.
The broader lesson is simple: error copy belongs in the same review as state transitions and destructive actions. A beautiful message is still misleading if its button performs the wrong kind of retry.
Top comments (0)