2

One thing I'm constantly thinking about for my mobile app is what to show users when something goes wrong. I try to avoid generic error messages like "Something went wrong. Please try again" but do I really want to have a specific message for every possible error (unauthorised, invalid credentials, request time-out, unexpected server response, response parsing error, etc)?

Basically what I want to know is, where do you draw the line on how many different error messages you should be able to display to the user?

Improve this question
1
  • it will depend on your app and your users. If this is for technical people, you won't need to tell it all, but some info would be appreciated. For example: Google Chrome shows a generic error page when it can't access a site. But you can expand the info and see the technical reasons that caused the problem. If you're a developer or a webmaster, this info is handy. If you're an old lady looking for kittens, probably not, and the generic message not only is OK, but it could be way over her head
    – Devin
    Commented Jan 23, 2017 at 17:03

4 Answers 4

Reset to default
1

It depends on the technical expertise of your users

For highly technical products like mobile phone WiFi scanners, it's appropriate and appreciated to include detailed and accurate error messages. For general public apps, perhaps just enough errors.

Remember that an error is the app/program saying "Something broke and I can't fix it. I need you to fix it." If your error messages don't enable your users to fix that problem, then you have failed.

My favorite example of complete, I mean complete, error messages is IBM MQ. For absolutely everything that can go wrong, there's an error code and description to go with it. Granted, this product is for highly skilled and dedicated users but it illustrates the completeness that error messages can have.

On the other extreme, "an error occurred. Try again later". This will kill your UX instantly. Full stop.

For your app, you'll want to include error messages for all the things that your users can do something about. If possible give them pointers on how to fix it. In really off the wall circumstances, perhaps an error code and a link to where they can look up more info and possible resolutions.

Error codes and messages cost developer/UX time so you probably will never do all errors. Conversely, you have to have some or the product isn't usable. It will depend on your all and your users.

Improve this answer
2

Display a message that tells the user if the error is on his side or on the server side.

Give details if the user is able to fix it or do something about it accompanied with a suggestion. For example: "Please reload the page in a few minutes". If the user can't do anything about it, then you could give a generic message.

You could give a non-technical message and a technical message for both kinds of users.

Improve this answer
3
  • So, supposing an SQL-related error occurs server-side, on the mobile app side you would display something like this: "Something went wrong unexpectedly. Please contact support and show them this error: 500 - SQLException" ?
    – Anubis
    Commented Jan 23, 2017 at 14:30
  • @Anubis I'm suggesting a general approach. In that case, it looks to me like a good message: 1.Error notice 2.Server side 3.How to fix it (contact support) 4.Error code (useful for tech user and to fix the problem). Possibly the "and show them this error" could be skipped and left in a different line as the message for tech users.
    – Alvaro
    Commented Jan 23, 2017 at 14:39
  • @Anubis you might want to leave the question unanswered for some time in case others have better opinions or suggestions.
    – Alvaro
    Commented Jan 23, 2017 at 14:41
-1

Error message is a UX antipattern & the best error message is the one that does not show up. always try to build interface that does not allow technical error messages.

  1. keep it simple - the less the input from user is needed, the better. User's focus is rare resource.
  2. be restrictive - if app relies on user input, use a proper component; for example don't use text input for dates, use calendar component.
  3. If needs to be - be helpful and think about the processes behind the error messages. You either need to link "Reset password" after unsuccessful login in dialog or need to automatize the queue of errors on the backend; but don't expect the user to proactively solve the issue. If there is an request error that runs in background, you could handle that internally inside your app and try it later or queue it for later.

Great read on this topic can be found at this article at Medium. However, if you need to show error messages, don't bother with showing technical details. These are always (>95%) ignored by the users.

Good luck! :)

Improve this answer
3
  • 6
    an error message is an antipattern? If you're talking about that article in UXmatters, they even applaud good error messages towards the end of the article. Granted, a flawless system where no error is possible would be amazing, but this is impossible in 99.9999% of cases. In those cases, I'd consider an antipattern the lack of error messages! As for technicality, Chrome shows a generic error message, but if you want to know more, you can expand the technical side of the error, which means a lot for a lot of people
    – Devin
    Commented Jan 23, 2017 at 16:58
  • 1
    Error messages are most definitely not an antipattern. for virtually any non-trivial software that is actually useful for people, it is impossible to sensibly leave them out. To leave them out will result in one of two things happening: your application swallows any errors leaving users clueless that an error occured, or what to do about it, or, when an error inevitably occurs your software will catastrophically crash.
    – whatsisname
    Commented Jan 24, 2017 at 3:05
  • 1
    The thinking that error messages are an antipattern is what brings us applications that just get stuck during lengthy processes without providing any feedback, because someone was afraid to show an error message and instead opted for "Please be patient. This could take a while."
    – O. R. Mapper
    Commented Jan 25, 2017 at 11:51
-1

In case of error:

If you expect some action from the user let him know what to do.

Otherwise a generic error message is enough, optionally with time stamp and some random number. Include a logger in background for you to know what has happened.

Never show any technical details as this is a security issue.

Improve this answer
2
  • Hopefully you don't actually mean random when you say a random number, and that you mean an error code that the user could use to find help on the internet, or provide to you to diagnose their troubles. As for your last statement, that is far from absolute, many softwares showing technical details is just fine, e.g. if MSPaint crashed and showed you technical information.
    – whatsisname
    Commented Jan 24, 2017 at 5:07
  • For a web application you need some ID number (random of whatever), to identify the error in your logfile, if a user sends a screenshot to you. In desktop apps it is a completely different approach!
    – Doc
    Commented Feb 11, 2017 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.