How English Works | The Error Message

There is a particular kind of sentence we usually read when we are already annoyed.

Something went wrong.

It appears after the form refuses to submit.

After the password fails.

After the payment does not go through.

After the file disappears from the place we expected it to be.

After the application stops exactly when we need it.

At that moment, English has a difficult job.

The system already failed.

Now the words have to prevent a second failure:

the user not knowing what happened or what to do next.

That makes the error message one of the most revealing forms of practical English in the modern world.

It is tiny.

It appears under stress.

And it must repair communication while another system is already malfunctioning.

Quick Read

One-sentence answer: a good error message uses clear, specific, non-blaming English to tell a person what went wrong, where the problem is, what state the system is in and what useful action can happen next.

A useful error message usually answers some combination of five questions:

What failed?
Where did it fail?
What does that mean for me?
What can I do now?
How will I know I have recovered?

The World Wide Web Consortium’s accessibility guidance makes the first requirement explicit: when an input error is automatically detected, the item in error should be identified and the error described in text. Microsoft’s interface-writing guidance adds a complementary principle: useful messages should be conversational, clear, avoid blaming the user and provide a realistic way forward. Nielsen Norman Group similarly emphasises human-readable, precise, polite and constructive error language.

Those are interface rules.

They are also excellent English lessons.

“Something Went Wrong” Tells You Almost Nothing

Consider the message:

Error.

It contains one correct piece of information.

There is an error.

But the reader probably already knows that because the expected action did not happen.

The sentence adds almost no useful information.

Now compare:

The file is larger than 20 MB. Choose a smaller file and try again.

That message performs several jobs.

It identifies the object: the file.
It identifies the problem: larger than 20 MB.
It reveals the system boundary: 20 MB.
It gives a feasible next action: choose a smaller file.
It gives a recovery route: try again.

This is English turning a hidden machine state into a human-readable model.

The System Knows Something the User Does Not

When a machine rejects an action, there is often an information asymmetry.

The system may know:

which field is invalid;
which rule was violated;
whether the network failed;
whether the file format is unsupported;
whether the user is unauthorised;
whether a service is temporarily unavailable;
or whether the requested object no longer exists.

The user sees only the outcome:

It didn’t work.

The error message is the bridge between those two states of knowledge.

This is why generic error wording is so frustrating.

The system possesses information that could reduce uncertainty, but the language refuses to transmit it.

That is a communication failure layered on top of a technical failure.

Good Error English Starts from the User’s Point of View

A programmer may see:

AUTH_TOKEN_EXPIRED_401

The user sees:

I was writing a form and suddenly it stopped letting me continue.

Both describe the same event from different models.

Good interface writing translates the internal state into the user’s task language.

Your session expired. Sign in again to continue. Your saved draft is still here.

That is much more than simplification.

It identifies what changed.

It tells the user what to do.

And it addresses the fear that matters most:

Did I lose my work?

This is audience design at high resolution.

The technically deepest explanation is not automatically the most useful explanation.

A Good Error Message Names the Problem Precisely

Compare four messages:

Invalid input.
Invalid date.
Enter the date as DD/MM/YYYY.
Enter a date between 1 January 2026 and 31 December 2026 using DD/MM/YYYY.

Each version adds resolution.

The final version tells the reader both the required format and the valid range.

This reveals a broad principle:

Vagueness forces the reader to search.

Where is the problem?

What rule did I break?

What format do you want?

What counts as valid?

The more the message can answer those questions cheaply, the less work the user has to perform.

Nielsen Norman Group’s guidance captures this well: error messages should be explicit, human-readable, polite, precise and constructive.

Where the Message Appears Is Part of the Meaning

Suppose a page contains twenty fields.

The user presses Submit.

A red message appears at the top:

One field contains an error.

Now the user must hunt.

Which field?

What error?

Where?

If instead the relevant field says:

Postcode must contain six characters.

the physical position of the message reduces the search problem.

W3C guidance on error identification is important here because accessibility is not only about making an interface visible. The error must be described in text, and the person needs enough information to determine what is wrong.

This gives us a larger language lesson:

Meaning is shaped by placement as well as wording.

A note beside a sentence functions differently from the same note hidden three pages later.

A label beside a button functions differently from a paragraph in a manual.

Text lives in interfaces.

Do Not Blame the Reader

Consider:

You entered the password incorrectly.

Now compare:

The email or password doesn’t match our records. Check both and try again.

The second message describes the mismatch without confidently assigning fault.

Why does that matter?

Because the system may not actually know the cause.

Perhaps the user typed the wrong password.

Perhaps the account uses a different email address.

Perhaps the account no longer exists.

Perhaps the service has a fault.

Good English should not state more than the evidence allows.

This is exactly the same calibration problem we see in academic writing, journalism and argument.

Do not convert:

the system observed a mismatch

into:

the user caused the failure

unless you actually know that.

Error Messages Are Small Lessons

When people encounter an error, they are unusually motivated to understand the rule.

That creates a teaching opportunity.

Suppose a form says:

Invalid username.

The user learns little.

Suppose it says:

Usernames can contain letters, numbers and underscores only.

Now the message teaches the constraint.

The user is less likely to repeat the same failure.

This is why a useful error message can improve learnability rather than merely end frustration.

The same principle belongs in education.

Compare teacher feedback:

Wrong.

with:

Your evidence is relevant, but the explanation does not show how it supports your claim. Add the missing relationship.

The second is essentially an educational error message.

It identifies the state.

It narrows the failure.

It suggests a repair.

The Difference Between Problem, Cause and Solution

Many weak messages mix these layers.

It helps to separate them.

Problem

The upload did not complete.

Known cause

Your internet connection was interrupted.

Useful solution

Reconnect, then select Resume upload.

If the cause is unknown, the message should not invent one.

It might say:

The upload did not complete. Your file is still on your device. Check your connection and try again.

This is epistemically better because it distinguishes what the system knows from what it merely suspects.

That habit should be familiar from strong academic English:

observed fact is not the same as inferred cause.

A Useful Message Preserves the User’s Mental Model

Suppose you press Save.

The interface freezes.

Then you see:

Operation failed.

Your next question is not philosophical.

Did it save?

A good message should answer the state question if it can.

We couldn’t save your latest changes. The previous version is still stored. Check your connection and save again.

Now the user knows:

the latest change did not persist;
an earlier version still exists;
the task can be retried;
and the likely recovery path.

In other words, the message repairs the user’s model of the world.

That is a deep function of language.

“Try Again” Is Not Always a Solution

We have all seen it.

Something went wrong. Try again.

Sometimes retrying is exactly right.

A temporary network failure may disappear.

But if the system knows that the card has expired, “try again” is useless.

If the username contains an illegal character, “try again” is incomplete.

If the file exceeds a hard limit, repeated attempts will reproduce the same failure.

A recovery instruction should change something relevant.

Choose a file under 20 MB.

Update the expiry date.

Remove spaces from the username.

Reconnect to the internet, then resume.

This is cause-and-action alignment.

The suggested action should address the actual failure mode.

Tone Matters Most When the Reader Is Under Stress

Imagine losing access to an important account.

Now imagine the message says:

Oops! Silly you! Looks like you forgot your password again!

The wording is playful.

The moment may not be.

Tone must match context.

Microsoft’s writing guidance recommends friendly, helpful and concise language, while warning against blaming the user or overwhelming them with technical detail. Nielsen Norman Group likewise advises against cleverness when it obscures the message.

This is a useful lesson for students who have been told that “good writing” means making every sentence colourful.

Sometimes good writing is restrained.

A condolence is not a comedy routine.

A safety warning is not a place for ambiguity.

An error message is not a branding contest.

Error Codes Are for Machines and Specialists — Not Always for Readers

A code can be useful.

It may help support staff search logs or documentation.

But a code alone rarely helps an ordinary user recover.

Error 0x80070005

may identify the internal category precisely while communicating almost nothing to the person in front of the screen.

A better design can support both audiences:

You don’t have permission to open this folder. Ask the folder owner for access. Error code: 0x80070005.

Now the human receives the useful model while the code remains available for diagnosis.

This is translation between layers.

And translation between layers is one of the central jobs of English in complex systems.

Accessibility Makes Good Error Writing Better for Everyone

Colour can help signal an error.

But colour alone is not enough.

An icon can help.

But an icon alone is not enough.

W3C’s accessibility guidance emphasises textual identification because different users encounter interfaces differently.

A person using a screen reader may not perceive the page the way a sighted user does.

A person with low vision may miss a subtle colour change.

A person with a cognitive disability may need the correction expressed plainly rather than implied.

When we write the error clearly in text, we make the state more portable across human differences and technologies.

This is one reason accessibility is not a decorative extra.

It often exposes where communication was relying on unstated assumptions.

The Error Message as a Feedback Loop

A system receives an action.

The action fails.

The system returns information.

The user changes something.

The system tests the new action.

That is a feedback loop:

Attempt
→ failure
→ message
→ interpretation
→ correction
→ new attempt.

If the message is vague, the correction may be random.

If the message is wrong, the user may move farther from the solution.

If the message is precise, the next attempt becomes better informed.

This is exactly how useful educational feedback should work.

A mark alone reports outcome.

Good feedback improves the next attempt.

What Error Messages Teach Us About Teacher Feedback

Consider these comments on a student essay.

Weak.
Not clear.
Bad grammar.
Explain more.

All may contain some truth.

None gives the student a precise repair route.

Now rewrite them as diagnostic messages.

Your main claim appears only in the final sentence. Move it to the start so the paragraph has a clear controlling idea.
The pronoun this could refer to two different events. Replace it with the exact noun.
The subject is singular, so change were to was.
You quoted the evidence but did not explain why it supports your interpretation. Add the relationship after the quotation.

Now the feedback behaves like a high-quality error message.

It identifies location.

Names the problem.

Explains the relevant rule.

Suggests a feasible correction.

This is actionable English.

Primary School: Learn to Name the Exact Problem

Young learners often use very broad failure language.

I don’t get it.

That feeling is real.

It is not yet diagnostic.

A teacher can help the child increase resolution:

I don’t know what this word means.
I know the words but not what the sentence means.
I understand the sentence but not why the character did that.
I know the answer but cannot explain it.
I understand the example but cannot do the new question.

Each sentence is a better error message from the learner to the teacher.

Better diagnosis creates a better chance of repair.

Lower Secondary: Separate “I Don’t Know” from “I Can’t Retrieve”

By Secondary 1 and Secondary 2, students can learn to classify failure more precisely.

For example:

I never learned this rule.
I learned it before but forgot it.
I remembered the rule but applied it to the wrong case.
I knew which rule to use but made an execution error.
I wrote the answer correctly but failed to satisfy the question.
I understood the passage but could not express the inference precisely.

These are different error states.

They should not receive one generic response:

Practise more.

A useful learning system should return a message that matches the failure.

Upper Secondary: Error Messages Become Calibration

Advanced learners need to detect not only wrong answers but weak claims.

Imagine an essay sentence:

This proves social media destroys attention spans.

The sentence may not contain a grammatical error.

The error may be epistemic.

A useful internal message could be:

Claim too strong for evidence. Replace proves with a verb that matches the study design and limits.

Now the student is learning to build an editor inside the mind.

That is one of the highest forms of language learning.

The writer produces a sentence, detects the failure mode and generates a repair instruction before another person has to do it.

Ten Failure Modes of Error-Message English

1. The message merely announces failure

“Error” tells the user nothing they can use.

2. The message uses the machine’s vocabulary

The code is precise internally but meaningless to the reader.

3. The location is missing

The user knows something is wrong somewhere and must search the interface.

4. The rule is hidden

The system rejects the input without explaining the constraint.

5. The message invents a cause

The system observed failure but reports an unverified explanation.

6. The user is blamed

The wording assigns fault unnecessarily and may not even be correct.

7. The next action cannot solve the problem

“Try again” repeats an impossible action.

8. The message hides the system state

The user cannot tell whether data was saved, sent, deleted or preserved.

9. The tone mismatches the stakes

Playful wording appears during a serious loss or security problem.

10. The message is visually present but linguistically inaccessible

Colour or icons signal failure, but the error is not properly described in text.

All ten failures come from the same deeper mistake:

the system communicates from its own perspective instead of building the model the receiver needs.

How to Write a Better Error Message

Start with what the system actually knows.

Then translate that state into the user’s task.

A practical structure is:

Problem → relevant state → next action

For example:

We couldn’t send your form because the connection was interrupted. Your answers are saved on this page. Reconnect and select Submit again.

Then audit the wording.

Does it identify the problem?
Does it identify the affected object or field?
Does it state only what is known?
Does it use words the intended reader understands?
Does it preserve important information about data or progress?
Does it provide a feasible next step?
Does the tone match the stakes?
Is the error described in text rather than colour alone?

That is a small writing task with a surprisingly high standard.

Why This Matters Beyond Software

Error messages exist everywhere.

A teacher’s correction is an error message.

A returned application marked “missing document” is an error message.

A road sign that says “Bridge closed — use Exit 12” is an error-and-recovery message for a route.

A laboratory instrument warning that a sample is outside range is an error message.

A bank notifying a customer that a transfer could not be completed is an error message.

A friend saying, “I understood your point until the last sentence; I don’t know what this refers to,” is an error message about communication.

The common structure is:

expected state
≠
observed state.

Language then helps explain the gap.

The Deeper Idea: Failure Needs a Language

Complex systems do not become reliable by pretending failure never happens.

They become more reliable when failure can be detected, named, communicated and repaired.

That means language has a role after success breaks.

What failed?

What remains intact?

What is uncertain?

What can the person safely do next?

What should not be attempted?

When should the problem be escalated?

How will recovery be confirmed?

These are not merely software questions.

They are questions for classrooms, hospitals, organisations, transport systems, families and any place where humans have to recover from an unexpected state.

The error message is therefore a very small piece of civilisation.

A few words standing between failure and confusion.

When those words are good, they do not merely say that something went wrong.

They help the receiver find the road back.

Reader Checklist

What exactly failed?
Where is the problem?
What does the system know for certain?
What is it merely guessing?
What happened to my work or data?
What action can actually change the state?
Is the wording understandable without technical background?
Does the message blame me unnecessarily?
Can a person using assistive technology identify the problem in text?
How will I know the recovery succeeded?

Research and Further Reading

Final idea: the best error message does not merely report that the road ended. It tells the traveller where they are and gives them a credible next turn.