Error and system messages components

[dontpanicgr]

How do we handle errors in the product?
Currently, we have:
2 custom components (resources, schedulers [new])
3 defined components in styleguide (system messages, notifications, status)
& coming soon solutions like (toast, flag messages...) #7

---

I started with a question though we all know that we handle errors in a complex inconvenient way for users which doesn't comply with simplicity and modularity principles of our design system.

This uncertainty of which element to use has an effect on development and design and for many times we saw ourselves scratching our heads and iterating again and again on existing elements.
Most of us experienced repeated conversations of what to choose in each use case and re-inventing the wheel -- a process that is not productive.

I suggest we should explore and discuss again the structure and semantics of error messages component which by completion will save us hours! in development and decision making.

@mikegianno @codegaze @yiotaz ^^

[codegaze]

I'm going to add this #4 (comment) which is a comment that might be related and try to give a summary on a discussion we had today with @dontpanicgr.

1. We tend to use/create different type of error messages (even in the same workflow) depending on the case, which are not documented.
2. Each time we might reinvent the wheel like it was mentioned.

And some questions on this:

1. How many different feedback messages are too many? :P
2. Does this mean that all the previous solutions are obsolete?
3. How can we improve this process and have some guidelines on when we use something and how, aka how a new team member can have the same context as everyone else on decision making about this subject.

PS. Though I love when we create something new that is more visually appealing, imho consistency > visual beauty, so I'd be more happy with a less attractive but consistent messaging.

[mikegianno]

Agree with all things you said. Wii try to add only new remarks!

1. It might help if we treated the error message as part of a bigger component (form, modal, dont-know-what). Then finding the proper component for a UI will be the main question and all other things will be decided! :)
2. On top of what @codegaze said on Design principles  #3: We had done a similar exercise way back, where we ended up with the error formats of the styleguide. Obviously, we're missing something - otherwise we wouldn't be in this place right now-. Could we be missing one or more generic guidelines about messaging (consistency, proximity, follow color conventions, follow message structure)? So as long as those guidelines are followed we're consistent with our design system.

[dontpanicgr]

📖Further reading

• Preventing User Errors: Avoiding Unconscious Slips
• 10 Usability Heuristics for User Interface Design
  
• Error Message Guidelines

Update if you find an article or reference worth mentioning.

[dontpanicgr]

Error prevention
10 Usability Heuristics for User Interface Design

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

[kouk]

Would it also make sense to monitor certain components for unexpected errors? So, a component could have a fallback error condition (for when something unexpected happens) which would log some information so that we can see if we missed something that should be handled by the component in a better way or if something is just breaking and needs to be fixed. It could even be a message to the user, "if this error persists please contact us with this reference number."

[dontpanicgr]

Found another article with good/bad examples.
https://uxplanet.org/how-to-write-good-error-messages-858e4551cd4?ref=uxdesignweekly