A customer spends ten minutes filling out your signup form.
They enter their company details, choose a plan, create a password and click Create Account.
Then the page shows:
“Something went wrong.”
Nothing else.
Which field is wrong?
Was the account created?
Should they click again?
Will they be charged twice?
The user does not know.
Your development team may see this as a small error message problem.
The customer sees something very different:
“This product is difficult to use.”
Sometimes they try again.
Sometimes they contact support.
Sometimes they simply leave.
This is why Error Message UX deserves much more attention than it normally receives.
Error messages appear when users are already experiencing a problem. That means the interface has one important job at that moment:
Help them understand what happened and show them how to continue.
Nielsen Norman Group recommends that error messages be visible, written in human-readable language, explain the exact problem and help the user recover without losing unnecessary work.
A good error message can turn a frustrating moment into a quick correction.
A bad one can turn a ten-second problem into abandonment.
Why Error Messages Matter More Than Most Teams Think
Product teams naturally spend time designing the happy path.
The user:
Creates an account.
Adds a payment method.
Uploads a file.
Completes checkout.
Everything works.
But real users do not always follow the perfect path.
They mistype passwords.
Cards get declined.
Internet connections fail.
Files are too large.
Permissions are missing.
APIs time out.
Required information is forgotten.
The quality of your product becomes very clear during these moments.
A polished interface that works only when nothing goes wrong is not truly easy to use.
ZA Technologies describes UX/UI design in a similar way. Good design should guide users through tasks clearly rather than simply making a product look attractive.
The Worst Error Message: “Something Went Wrong”
Imagine trying to open your front door and seeing a message:
“Door problem.”
That does not help you.
Is it locked?
Is the key wrong?
Is something blocking it?
Do you need another key?
Digital error messages often make the same mistake.
Messages like:
“Something went wrong.”
“Invalid input.”
“Request failed.”
“Unknown error.”
tell users almost nothing.
A better message answers two questions:
What happened?
and
What should I do now?
Instead of:
Invalid input
write:
Enter your phone number using 10 digits, for example 6045550123.
Instead of:
Upload failed
write:
This file is larger than 10 MB. Choose a smaller file and try again.
The problem becomes understandable and fixable.
Error Messages Should Speak Like People, Not Developers
Developers need technical information.
Customers usually do not.
Consider:
Error 422: Validation exception on field usr_email_addr
That may be useful inside a log.
It is terrible customer communication.
The user simply needs:
Enter a valid email address, such as name@example.com.
This does not mean hiding useful technical information from your engineering team.
You can log detailed error codes behind the scenes while showing customers simple language.
A useful rule is:
Logs should help developers debug. Error messages should help users recover.
Those are different jobs.
Put the Error Where the Problem Happened
Suppose a form contains twelve fields.
The user clicks Continue and sees:
“Please fix the highlighted errors.”
They scroll up.
Nothing seems obvious.
They scroll down.
Still nothing.
Eventually they notice a small red border around the postal-code field.
This creates unnecessary work.
Nielsen Norman Group recommends placing messages close to the source of the error because proximity makes it easier for users to understand what needs attention.
Instead of placing every error at the top of a page, show the problem next to the relevant field whenever possible:
Postal code
V2Y
Enter a valid Canadian postal code, for example V2Y 0G9.
Now there is no guessing.
For products with complex forms or workflows, this is exactly the kind of friction that structured Usability Testing can uncover before launch. ZA’s testing approach observes whether real users complete tasks, where they hesitate and what mistakes they make.
Do Not Delete Everything the User Already Entered
Few UX mistakes are more frustrating than this:
A customer spends five minutes filling out a long form.
They submit it.
One field is incorrect.
The page reloads.
Every field is empty.
Now the customer has to start again.
Nielsen Norman Group specifically recommends preserving user input when errors occur so people can correct the problem instead of repeating completed work.
If the email address is wrong, preserve:
Name.
Company.
Address.
Phone.
Plan selection.
Everything else that was valid.
Then ask the user to fix only the email address.
The product should help people recover from errors, not punish them for making one.
Do Not Blame the User
Compare these messages:
You entered the wrong password.
and
The email or password does not match. Try again or reset your password.
The second feels more helpful.
The goal is not to make error messages artificially friendly.
The goal is to remove unnecessary blame.
Users are already dealing with a problem. Messages such as:
You failed to provide…
You entered this incorrectly…
You made an error…
add frustration without helping.
Use neutral language:
Enter a date after September 16.
Choose at least one team member.
Your session has expired. Sign in again to continue.
Simple language works better.
Timing Matters
Imagine entering your email address.
You type:
john@
Before you finish typing, a red message appears:
Invalid email address!
You already knew that.
You had not finished.
The interface is treating an incomplete action like a mistake.
Nielsen Norman Group describes premature errors as a hostile pattern because they can interrupt users before they have actually done anything wrong.
Validation should happen at the right time.
For some fields, immediate feedback is useful.
Password requirements are a good example:
At least 8 characters
1 number
1 uppercase letter
The requirements can update while the user types.
But avoid shouting ERROR simply because someone has not finished entering information.
Do Not Use Red Color Alone
A red border may look obvious to some users.
It may not be enough for everyone.
Someone with a color-vision deficiency may not recognize the difference clearly.
A screen-reader user cannot depend on visual color at all.
W3C guidance recommends that errors be identified clearly and that users receive understandable instructions about how to resolve them.
Use more than color.
For example:
⚠ Card number is incomplete. Enter all 16 digits.
Now users have:
A visual indicator.
Text.
A clear instruction.
Accessibility should not be something you add after designing the error state. It should be part of the error experience from the beginning.
Payment Errors Need Special Care
Payment screens are one of the worst places for vague errors.
Suppose a customer clicks Pay $499.
The system responds:
Payment failed.
The user’s immediate questions are:
Was I charged?
Why did it fail?
Should I click again?
Could clicking again charge me twice?
A better experience might say:
Your payment was not completed and you have not been charged. Your bank declined this card. Try another payment method or contact your bank.
The customer now understands the situation.
Different payment failures may need different messages.
A card decline is not the same as:
Expired card.
Incorrect security code.
Payment gateway timeout.
Unsupported card type.
Missing billing address.
Do not combine every payment failure into one generic message if you have enough information to guide the user more clearly.
Login Errors Need a Balance Between UX and Security
Login screens create another challenge.
You want useful communication without revealing information attackers could abuse.
For example, saying:
No account exists for john@example.com
can reveal whether an email address is registered.
A safer message might be:
The email or password does not match. Try again or reset your password.
Then provide a clear Forgot password? option.
Good error UX does not mean showing every technical detail.
It means providing the safest useful next step.
Error Messages Should Offer Recovery
An error message without a recovery path is only half finished.
Imagine:
You do not have permission to view this report.
Fine.
What now?
A stronger version might say:
You don’t have access to this report. Ask your workspace administrator for Reporting permission.
Even better, where appropriate:
Request access
Now the error becomes part of the workflow.
This principle works across many situations.
Instead of:
No internet connection
offer:
Check your connection and try again.
Instead of:
Session expired
offer:
Sign in again to continue where you left off.
Instead of:
File type unsupported
offer:
Upload a PDF, JPG or PNG file.
Every error should answer:
What can the user do next?
Prevent Errors When You Can
The best error message is often the one users never need to see.
If your system accepts only dates from today onward, disable past dates in the calendar.
If a username can contain no spaces, explain that requirement before submission.
If uploads cannot exceed 10 MB, show:
Maximum file size: 10 MB
beside the upload button.
If deleting a project is permanent, ask for confirmation before deleting it.
Nielsen Norman Group’s usability heuristics treat error prevention separately from error recovery because preventing predictable mistakes is usually better than explaining them afterward.
Research can help teams discover which mistakes are predictable. ZA’s UX Research service uses interviews, behavior analysis and user journey mapping to find the points where people become confused before design decisions are finalized.
A Small Error Can Become a Big Drop-Off
Consider an ecommerce checkout.
A user enters:
Name.
Shipping address.
Phone number.
Payment information.
Then they click Place Order.
The form scrolls back to the top and says:
There are errors in your form.
Somewhere near the bottom, the phone number format is wrong.
That is technically a small problem.
But from the customer’s perspective, checkout just became difficult.
They may fix it.
Or they may decide:
I will buy this somewhere else.
The same thing happens in SaaS onboarding.
A confusing API-key error can stop integration setup.
A vague permission error can stop team invitations.
An unclear password rule can stop account creation.
Small interface problems can create surprisingly large business consequences when they occur at important moments.
How to Test Your Error Message UX
Do not test only whether the message appears.
Test whether someone understands it.
Give real users realistic tasks and deliberately introduce problems.
For example, ask someone to create an account but provide a password that is too short.
Then watch.
Do they notice the error?
Do they understand it?
Do they know how to fix it?
Can they correct the problem without losing previous work?
This is why usability testing is valuable. ZA Technologies evaluates task success, time on task, error rates and user behavior instead of relying only on whether the interface technically functions.
A useful error UX review should check these seven things:
- Visibility: Can users easily notice the error?
- Clarity: Can they understand what happened without technical knowledge?
- Location: Is the message close to the source of the problem?
- Recovery: Does it explain exactly what to do next?
- Preservation: Does the interface keep work the user already completed?
- Accessibility: Can users understand the message without depending only on color?
- Tone: Does the message help rather than blame?
If your error message fails several of these checks, rewrite it before changing the visual design.
Final Thoughts
Error messages are easy to ignore during product design because nobody wants to think about things going wrong.
But errors are part of every real product.
Users mistype information.
Networks fail.
Payments decline.
Permissions change.
Files break.
APIs time out.
The question is not whether your users will encounter problems.
They will.
The real UX question is:
What happens next?
A bad error message leaves users confused.
A good error message tells them what happened, protects the work they already did and provides a clear way forward.
That is why messages like:
“Something went wrong.”
should rarely be the final user experience.
Replace vague errors with useful instructions.
Place them where users can see them.
Write in normal language.
Preserve user input.
Make them accessible.
And test them with real people.
Because a customer usually does not leave your app thinking:
“That application had poor error-message UX.”
They simply think:
“This is too difficult.”
Then they close the page.
For product teams that want to catch these friction points before customers do, ZA Technologies combines UX/UI Design, UX Research, and Usability Testing to identify confusing interactions and turn them into clearer digital experiences.
