3 ms·

What I've never heard is how messages like "Oops! Something went wrong. Please try again" actually result in a better experience for anyone at all - yet UX desi

What I've never heard is how messages like "Oops! Something went wrong. Please try again" actually result in a better experience for anyone at all - yet UX designers seem to love them. Ok, there's no need for errors to be totally cryptic and meaningless to end-users, but the basic principle is a) if the problem is something the user might be able to do something about, explain what they'll need to do (e.g. free up disk space) b) if not, give the user everything they can to ensure if they need to go through a support channel or search elsewhere for info about the error they can get the help they need, i.e. at least some sort of unique message or code. c) if it's a transient error that's not the user's fault, explain that and suggest at what point they should retry (and reassure them that nothing destructive/unwanted/irreversible has occurred or will occur on retrying).

kevmo314 4y ago
> how messages like "Oops! Something went wrong. Please try again" actually results in a better experience for anyone at all Didn't you just explain how? > c) if it's a transient error that's not the user's fault, explain that and suggest at what point they should retry Many times when I've sent this type of error but it's not actually transient was a mistake in misclassifying the error. So if the code doesn't actually know it's a or b, it's not surprising it defaults to c.
- wizofaus 4y ago
  > Didn't you just explain how? "Something went wrong" I don't consider as a message that provides a good experience. Actually I didn't even mind the example given in the original article "Token not provided in guest headers", though that very much sounds like a b) error, where it's not transient but there's nothing the user can do about it, but at least they have some sort of unique identifying message/code that can help support figure out the problem. And sure, classifying errors can be tricky, and it absolutely requires following best-practices throughout the codebase to ensure that errors are passed around in a reasonably consistent manner where you can distinguish transient from non-transient errors, or errors where the user can take reparative actions. But the end result makes everything vastly better for the user and developers/testers etc., so is well worth the investment.
jodrellblank 4y ago
It's better for the developers because they don't have to do a) or b) which involve work. Modern software development is thick with optimizing for developer convenience and externalising the cost of that to everyone else. Better for the company because they don't have to pay to develop or test or maintain a) or b), can release the simpler product sooner and move the developers onto new features which increase income. You're unlikely to stop being a customer because an error said "Oops! Something went wrong" instead of "Error: {fb964102-bac4-4f9e-b671-62c047cb350e}".
- wizofaus 4y ago
  I don't buy that it's better for developers at all, because a significant % of the time you get such errors is because of an issue in the code that we then have to track down and fix. And it's never the developers arguing for such messages. Lazy devs might think nothing of popping up a message showing just the exception name/message or error code which I'd argue is better than just "oops...".

kevmo314 4y ago

> how messages like "Oops! Something went wrong. Please try again" actually results in a better experience for anyone at all Didn't you just explain how? > c) if it's a transient error that's not the user's fault, explain that and suggest at what point they should retry Many times when I've sent this type of error but it's not actually transient was a mistake in misclassifying the error. So if the code doesn't actually know it's a or b, it's not surprising it defaults to c.

wizofaus 4y ago
> Didn't you just explain how? "Something went wrong" I don't consider as a message that provides a good experience. Actually I didn't even mind the example given in the original article "Token not provided in guest headers", though that very much sounds like a b) error, where it's not transient but there's nothing the user can do about it, but at least they have some sort of unique identifying message/code that can help support figure out the problem. And sure, classifying errors can be tricky, and it absolutely requires following best-practices throughout the codebase to ensure that errors are passed around in a reasonably consistent manner where you can distinguish transient from non-transient errors, or errors where the user can take reparative actions. But the end result makes everything vastly better for the user and developers/testers etc., so is well worth the investment.

jodrellblank 4y ago

It's better for the developers because they don't have to do a) or b) which involve work. Modern software development is thick with optimizing for developer convenience and externalising the cost of that to everyone else. Better for the company because they don't have to pay to develop or test or maintain a) or b), can release the simpler product sooner and move the developers onto new features which increase income. You're unlikely to stop being a customer because an error said "Oops! Something went wrong" instead of "Error: {fb964102-bac4-4f9e-b671-62c047cb350e}".

wizofaus 4y ago
I don't buy that it's better for developers at all, because a significant % of the time you get such errors is because of an issue in the code that we then have to track down and fix. And it's never the developers arguing for such messages. Lazy devs might think nothing of popping up a message showing just the exception name/message or error code which I'd argue is better than just "oops...".