.png)
During the past years, I have been working on several projects that have allowed me to help define interactions for the apps we were designing. Alongside the little that is written about mobile standards on the design side, and how fast new patterns arise as technology advances and mobile becomes more prominent in our lives, it can become pretty challenging finding answers to specific questions.
There are usually a lot of different ways to solve two problems.
Error handling is a big part of the app you are designing as it’s a crucial piece of direct communication with the user.
I’ve helped define guidelines for the different design systems in the projects I’ve worked on. And the behavior of error handling was a recurrent topic we tried to solve in each and every team. This is why I have decided to grab the information I’ve gathered throughout these years, analyze it, and define some established patterns that would scale and work well, to maybe help someone out there.
ALERTS:
For the sake of knowing what we are referring to when reading the article, I established as an alert everything that the system needs to trigger to give feedback to the user. For the different types of alerts, I have classified them into 3 types: feedback, warnings and errors.
To help decide when to use which component I defined a system based on the level of gravity. Keep in mind that the naming I am using in the article is a personal choice, but you might want to adapt it to your own needs. This guide is just intended to be a reference and is open for interpretation and iteration. It’s just one solution amongst others :)
So to sum up: there are different types of alerts, and alerts are always triggered by the system.
Alert types:
No Blocker/Low impact: Feedback → Snackbar
Somehow a blocker/Mid impact: Warning →Dialog
Blocker/High impact: Error →Dialog and Full page/Section
— — — — — — — — —
Feedback
Usecase 1:
The user performs an action to change something (e.g profile/settings: inputs (address etc.) or selections (toggle selection etc.). Then a Snackbar appears for feedback on if the action was successful or unsuccessful for x seconds and hides. The actions performed by the user can be undone easily. For example, Gmail uses snackbars to let the user know when an email was deleted. The snackbar allows undoing the action.
Warning
Usecase 2:
The user performs an action that requires confirmation/consent of any type, usually for actions that can’t be undone or require revision after a big flow. These actions allow to go back and change things or not perform the action. (eg. Making a payment, deleting something, exiting a flow…)
Errors
Usually, errors are based on and will happen while navigating through the app, as it is directly associated with the calls the app needs to perform.
Usecase 3:
The user Is navigating through the app and the call for a section couldn’t be done, then we show a section inline error state. Users can reload or go back and try to navigate back. All parts of the screen that don’t require calls or are preloaded will be shown.
Usecase 4:
User is navigating through the app and a call can’t be made for an entire screen: Full screen error. User can reload or go back and try to navigate back. Navbar and tabbar are visible.
Usecase 5:
The user is navigating through a flow and a call can’t be made on the last step: Full-screen error (unsuccess screen). Users might have a retry button or an x to close the flow.
Usecase 6:
The user tries to enter a flow and an error happens: Block navigation to flow and show dialog error with a button to dismiss. The user can try again.
— — — — — — — — —
Proactive network management:
Something to take into account when thinking about alert management is network issues. It’s a particular use case that will determine the app’s functionality.
When we can do proactive network management and determine network failure: We show a prominent Snackbar. Block navigation to screens that require making calls. Users can navigate through pages that don’t require making calls and/or are preloaded. You can see other apps that manage this, for example, Spotify.
I hope this was useful and that it helps you establish a system for your own error handling.
As always, thank you for reading :)