When it comes to very basic errors like the ones you’ve outlined (e.g., form validation errors, account not existing etc.), this thought process really works.
While most apps/software follow these ‘good practices’, there’s a whole bunch of technical errors that users are left to fend for themselves. Even Facebook gives the occasional ‘oops…something went wrong’ error. I will admit that in common practice, e.g., a Facebook session, these technical errors might not matter much, and that a reload will most likely fix things.
However, how do you look at communicating error messages for more technical software? Or maybe a software intended for a tech/dev user? There are a lot of cases where you’ll end up relaying error messages from underlying systems — and in most such cases, there will be undefined errors. Of course, it’s also not possible to get into very fine details of those just in order to communicate.
Coming to the UX side of this, I’ve always believed it’s worthwhile giving error codes in such cases. Whenever there are these undefined (or undefineable) errors, the first instinct is to go Google it. In which case, it always helps to have an identifier that differentiates between 5 different types of ‘oops…something went wrong’ messages.
