How designing a dialog error pattern library can make your product consistent and friendly
If you’ve ever worked on a global cross-functional design team, you’ve probably run into problems with scaling. It can be hard to get everyone on the same page and maintain consistency. On my team, we were experiencing growing pains regarding creating uniformity across dialog errors.
When it came to designing dialog error handling, we noticed a lot of back and forth not only between Dev, PM, and designers but also between the design team itself. Every time someone used a dialog (UI) in their flow, there was the question of how we would handle errors and success messages. We were starting to notice multiple types of user experience behaviors related to this issue. As a solution, we created a UX pattern library around error handling for dialogs so that our products could scale in a sensible/manageable way.
Basic principles behind error dialogs:
- It’s intuitive, no learning curve needed.
- It makes the user feel powerful and informed.
Nothing makes a user feel more uncomfortable with an application than when they can’t trust the system. We wanted to design patterns that provide people with the right content and informs them of what they can do next. We want them to be guided and make sure that they don’t end up feeling more lost.
- We want the UX to be seamless.
- We want to be intentional and confident.
Here’s a breakdown of the finalized set of dialog error patterns we made. They are divided into 3 main categories:
Category A - Dialogs that support complex content or are subject to a higher risk of server failure.
Category B - Dialogs that support simple content or are subject to a lower risk of server failure.
Category C - Dialogs that support special cases. We use these to delight people via illustrations and provide clear guidance to move forward.
Below is a visual chart of these categories that explain it further.
Category A
Applies to dialogs that support uploads, infrequent forms, multiple functions like input fields, checkboxes, dropdown, toggles, etc.
These types of dialogs usually interrupt the flow; they are annoying. They include conversational UI which provides people with confidence that something is happening.
Category B
Applies to dialogs that support frequent forms and light information to be processed.
These types of dialogs are very efficient and used for commonly performed actions.
Category C
Support special cases where people return to an empty state. We use this as an opportunity to add delight via illustrations and provide guidance to people and suggest that they to do something.
How creating a dialog error pattern library helped:
It kept us (all teams) on the same page. We reduced rework and coming back to the same questions every time we had a new dialog design. Everyone now speaks the same language and refers to the patterns created. Designers can’t make new dialogs up as they work, they have to choose from one of the 3 categories already made. We now have access to a consistent pattern that can be used across all teams without any confusion.
As it turns out, it’s really hard to design consistent and beautiful things at scale without patterns. This is one of the first steps on a long journey of defining a set of UX design patterns. The key thing is we now have a set of foundational guidelines to share and hold ourselves accountable to. This process of establishing a set of core principles isn’t isolated to design teams. I believe product, engineering, and other teams can all take advantage of creating pattern processes, and we hope ours serve as an inspiration for your team.
