An Error Message Should Open a Door
A practical way to turn a dead end into a useful next step.
“Something went wrong” is a peculiar thing to tell somebody who has just watched something go wrong. It confirms the one fact already available. The missing information is what happened to their work and what they can do now. A useful error message begins there.
Imagine a person adding a photograph to a fictional community noticeboard. They choose a file, wait, and see a red banner: “Upload failed.” Should they try again? Choose another photograph? Leave the page open? Their uncertainty is part of the failure, even if the underlying technical problem is unavoidable.
We can improve the banner without pretending that words will repair the upload service. First, identify the obstacle in terms the person can recognise. Suppose the selected file is too large. “This photograph is too large to upload” is more helpful than “Invalid asset.” It connects the problem to something visible rather than introducing a new mystery.
Next comes the boundary. If the system accepts photographs up to a certain size, say what that size is. A limit without a measurement turns the person into a tester, repeatedly guessing which file might work. In this hypothetical design, the message might read: “Choose a photograph smaller than 8 MB.” The number belongs here because it changes the next action.
Then protect the work surrounding the error. “Your notice text is still saved” answers a question that may matter more than the photograph. People do not experience a page as a collection of isolated technical components. They experience a task. Trouble in one corner can make the whole task feel threatened.
Put those pieces together and the message becomes: “This photograph is too large. Choose one smaller than 8 MB. Your notice text is still saved.” A nearby button labelled “Choose another photograph” makes the route forward concrete. The message now names the obstacle, describes the repair, and explains what remains safe.
That is a useful pattern, but it should not become a rigid template. Consider a different failure: the upload service is temporarily unavailable. Telling somebody to choose a smaller photograph would send them on an unnecessary errand. A friendly instruction is still a bad instruction when it points towards the wrong remedy.
In that case, honesty might sound like this: “We couldn’t upload your photograph. Your notice text is saved. Try uploading again in a moment.” If retrying could create duplicate notices, the design needs to resolve that risk before encouraging another attempt. Good wording depends on understanding the behaviour behind it.
There is also a difference between what the system knows and what it suspects. “Your internet connection failed” is a strong claim. If the system only knows that a request timed out, it should avoid assigning blame. “The upload didn’t finish” is less specific, but more accurate. Precision means staying within the evidence, not using the most detailed explanation available.
Tone should follow the size of the interruption. A light joke might seem charming to the writer and irritating to the person trying to finish. Excessive apology creates its own delay. “Oopsie! Our gremlins have escaped!” asks the reader to decode a performance before finding the instruction. Plain language is often the more considerate choice.
To test a draft, cover the rest of the screen and read only the message. Can you tell what needs attention? Can you identify a reasonable next move? Do you know whether anything has been lost? Then restore the screen and check whether the relevant control is close enough to find without a search.
Finally, remove any sentence that merely narrates the interface. “Please review the error below” adds little when the error is directly below. Keep the sentences that reduce uncertainty. The aim is not to produce the warmest possible banner or the cleverest microcopy. It is to return a person to their task with their understanding, their work, and as much of their patience as possible intact.
One final check is to read the message immediately after attempting the task yourself. The surrounding experience changes how words land. A sentence that seems adequate in a document may feel unhelpful after a long wait or a repeated failure.
About the Creator
Shane Murphy
Shane Ian Murphy: co-founder/partner, Tri-Party Tokenisation; founder/CEO, Global Secure Technologies (planned 2027 launch); co-founder/partner, Dual Party Capital. Partner, RougeN International Corp. Formerly of Limitless Mobile.
Enjoyed the story? Support the Creator.
Subscribe for free to receive all their stories in your feed.
Comments
There are no comments for this story
Be the first to respond and start the conversation.