Designing Around Alerts
When we designed Flinto for Mac, there were countless opportunities to solve a design problem by showing an alert. You know, something like “Error Saving File” or “Invalid Input” or “Lost Connection”, anything where the user has to dismiss the alert before moving on.
I try to be careful to design around these situations. In Flinto for Mac, there are very few alerts, even for things that would traditionally display them. In a review of the code for Flinto for Mac, I located all the alerts. There are 15. They can be broken down into three types.
1. Requested Information
There are seven “requested information” alerts in Flinto for Mac. This includes things like, your license information, or the results of “Check for Updates” which are displayed in an alert window when the customer asks to see them. Since the customer is invoking these alerts, I don’t see these as a problem.
2. Accident Prevention
I found two preventative alerts in Flinto for Mac. One asks, “Are you sure you want to revert all changes” when you press the “Revert” button in the transition designer. That action is infrequent and intentional enough that showing the alert is appropriate, if it were more frequent, I’d consider an undo action rather than an alert.
The second is “Are you sure you want to delete this transition?” That one only shows up if the transition is currently being used on multiple links. If it’s only used on the current link, we delete it without confirmation (don’t worry, you can undo this action). My thinking was that you might not realize you are deleting something that is used elsewhere in your prototype, but if the transition isn’t used elsewhere, we won’t bother you.
3. Errors
Flinto for Mac has five error alerts. These are usually the most common type of alert and the the kind that are best to avoid. In some apps, entering invalid input into a text field will cause an alert to appear. This frustrates users when they are working fast and make a simple mistake which could be fix quickly, but now an alert must be engaged with first.
In Flinto for Mac, inspector fields with invalid input are reset without showing any alert. Flinto assumes that you will notice that your change didn’t take effect and you can fix that.
One of these error alerts warns customers that the home screen of their prototype is missing. There isn’t supposed to be a way to remove the home screen, if you delete the home screen, Flinto automatically assigns it to another screen. If somehow the home screen is removed through some unforeseen set of actions, this alert will be displayed upon opening the file. This one has an easy workaround. Flinto should simply assign the home screen to the first screen in the prototype rather than show an alert. Rest assured, I’ve already filed an issue, it’s on the to-do list.
Another error message that gets displayed in Flinto for Mac happens when there is an error with the live preview. These are infrequent, and usually make sense to show. It might be possible to show some custom UI near the live preview button that explains the error without getting in the way. I didn’t think it was worth the effort, and I don’t have any immediate ideas for what that UI might look like, so I’m happy to leave it as-is. UI design is all about tradeoffs, just make sure you’re actually making a tradeoff, and not just defaulting to the easiest solution.
Raise Your Threshold
Usually working around an error message requires some custom UI work, and an alert is much easier to implement. You’ll need to decide on your threshold for when it’s appropriate to simply show an alert, and when it’s worth the extra effort to design around an alert completely, or to use some other UI that is less obtrusive. I hope that after reading some of my thoughts and experiences, you’ll recognize those situations and set the your threshold a little higher in favor of not displaying alerts.