Alternatives to "Unknown error"

Question

What would you suggest as a better alternative from a UX perspective to "Unknown error" when the error is not found in the error registry?

Answer 1

Here's a few example from other companies:

• Google: "An unknown error has occurred. Please try again later"
• EA: "EA Desktop encountered an unknown error. Try again a bit later"
• Apple, Samsung, Meta: "An unknown error has occurred"

Considering that these companies with large UX teams use very simple error messages it might be best to follow their example and not try to change the wording too much.

Hope this helps!

Answer 2

Error messages should always be informative and actionable for the average user.

This means that your average user should be able to either fix the error based on what you tell them or be able to escalate the issue to someone who can fix the error.

In the case of known errors, we should tell the user exactly what the problem is and what steps they need to take to fix the issue.

In the case of an unknown error, there may be steps we can offer the user ("turn it off and on again") or there may be nothing we can tell them beyond the fact that there is a problem.

At these times you need to be able to fall back on your product/corporate "tone of voice". This should tell you when you can say "Oops, something went wrong!" or when you should say "Sorry, there is a problem." - These two both mean the same thing but say it in different ways.

The way we use microcopy helps our users to engage with the product on a more personal level but we must choose our tone of voice wisely: Being too formal or not formal enough can actively disengage users. A piece of medical software that says "Oops" implies a level of carelessness that very few users will be comfortable with. On the other hand, an entertainment website that says "danger!" sounds like something much more involved than a user should expect.

Another thing we could do is to offer the user a way to escalate the issue. Adding a "Report this error" function to the page can go a long way to making the user feel more confident that someone actually cares about their experience. If this is not entirely possible (due to engineering overheads for example), then just telling the user that the event has been recorded and will be investigated (using the correct tone of voice) could be enough to prevent a serious drop-off.

Finally, when there is an unknown problem, we need to offer a path back to safety. This could be as simple as a link to the home page or something more complex like returning to a previously stored state.

Answer 3

Depends on the context and importance of the action that failed. If its a end action (shoping cart, registration etc) -> Then any sort of redoing the action, or contacting support in a quick way could be offered.

If its something unimportant it can be just link to redo it or to homepage.

For the error self neat tone like "Something went wrong and we're on it" should be sufficient.

Answer 4

What is your context of use? The solutions will depend on this context. Do you have examples? Can you be more precise?

A good thing to do is to give feedback to the user to help him do his action. So you can think about a generic sentence that explain why the system does not respond to the specific action.