4 ms·
It's nice to see this raised as an important issue for designers. It can be really hard to get anybody outside engineering interested in error messages until t
by dkarl 9y ago
It's nice to see this raised as an important issue for designers. It can be really hard to get anybody outside engineering interested in error messages until they see them show up in production.
I also like the emphasis on giving explanations that help the user understand what they can and can't do next. When users see errors, they immediately go into the mode of trying to make it work. They get hyped up and focused; they don't relax. A vague "friendly" message will just frustrate them further if it doesn't help them understand what to do next.
I think this is one aspect of UX where engineers can provide a unique perspective. I think designers and product managers are often surprised by the amount of energy a user can pour into struggling with an error, and the level of anger and frustration that can result. As programmers we can identify with that experience better than most, so we need to take it on ourselves to write good error messages and, when possible, present them to the designer as part of the design that needs their attention and vetting.
- Alex3917 9y ago> It can be really hard to get anybody outside engineering interested in error messages until they see them show up in production. IMHO any given request should be able to return multiple errors for the different stakeholders who will be consuming them. A good JSON error response could be something like: { 'display_error': '', 'field_errors': { 'field1': []}, 'internal_error': '' } The idea is that display error is something shown to the user, possibly a form-level error when relevant. Field errors are validation errors for user-submitted data. And internal errors are things that aren't shown to users, and are only meant as a way for backend and frontend devs to communicate amongst themselves to help debugging.
- mdaniel 9y agohttps://tools.ietf.org/html/rfc7807 https://tools.ietf.org/html/rfc7807 ("Problem Details for HTTP APIs") may interest you (but just for clarity: I only know about it, but haven't attempted to apply it to any situation)