Seven Deadly UI/UX Sins
With Halloween right around the corner, it’s fun to think about the kinds of things that haunt software engineers: bugs in the code, security vulnerabilities, and yes, bad UI/UX design.
Maximizing software usability is an art and a full-time job. Every button, every menu, every icon is riddled with potential pitfalls that could confuse, frustrate, and ultimately drive end users away.
Thankfully, there are some guiding principles application designers can use to navigate this house of horrors. Avoid these seven deadly UI/UX sins, and your users will live to log in another day.
#1: Ambiguous Binaries
Is the toggle below on, or will it turn on when you slide the button over?
Users don’t like being put in a position where they have to use a control in order to figure out what it does. (After all, what if the action is difficult or impossible to undo?) Uncertainty creates fear, and fear inspires low adoption rates.
Let’s also consider the dialog button options. If confronted with the modal below, would you have to think twice about which button to click?
In both these cases, the user is presented with an ambiguous binary: two options whose functions are poorly defined. In the toggle scenario, the confusion comes from the fact that the ON label is part of the toggle rather than outside it, making it difficult to tell whether “on” is meant as an adjective (“this switch is on”) or an adverb (“switch it on”). Placing the label adjacent to the control disambiguates it as an adjective, and a little extra highlighting makes the design even more user friendly.
The dialog buttons are ambiguous because they make use of both green and red. Green connotes a confirmation and safety whereas red connotes declination and caution. Unfortunately, the way the question is phrased, both buttons fit both connotations. For example, should the “Yes, delete it” be green because the user is confirming her intention, or should it be red because she should exercise caution in deleting the album? Changing the options from Yes/No to Cancel/Delete, as in the dialog below, makes it clear to the user that in consenting to the deletion, she is performing a critical action. This frees her of the UX double-bind.
To avoid ambiguous binaries in your own software, put every new control through an interpretation test by asking whether its function or state could be misunderstood. If so, check message boards like UX Stack Exchange to see what designers have done to untangle these mixed signals.
#2 Invisible Controls
Have you ever found yourself clicking or poking at a screen trying to ferret out the mechanism that will let you interact with the environment? This lack of interactive signaling is what the Nielsen Norman Group calls “no perceived affordance.”
“Drag-and-drop designs are often the worst offenders when it's not apparent that something can be dragged or where something can be dropped,” writes Jakob Nielsen. Dotted lines are sometimes used to denote a drop zone, but users typically need instruction to find the draggable items to drop there. Exago BI handles this UX pitfall using tutorial graphics.
The graphic disappears once the user has added her first field because she has learned the mechanic and no longer needs instruction.
Once the field has been added, however, the user encounters a new control in the radial menu button. Though Nielsen Norman doesn’t mention it, new or innovative UI controls also run the risk of giving no perceived affordance because the user is unfamiliar with their form and function. Exago BI’s ExpressView signals its interactivity using color and positioning next to the field name.
It’s vitally important to give users the ability to discover a UI’s controls and, once identified, understand what they do. Which leads us to the next sin!
#3 Poor Signposting
This is especially a problem with mobile devices, but you see it in web applications, too: give your users tooltips, especially when you’re giving them “mystery meat” icons like these.
Exago BI is a terrific example of an application that requires lots of non-standard icons. Sure we use the save floppy (), but we also use a house-created show-visualization-at-the-bottom-of-your-ExpressView button (), which is why we do this:
Signposting doesn’t just apply to tooltips either. Notifications explaining changes that have occurred but might not be readily apparent to the user also go a long way to supporting the user.
#4 Unhelpful Error Messages
The Nielsen Norman Group’s guidelines on error messages may be from the dark old days of 2001, but they’re still spot-on. It can be difficult to anticipate all the ways an application might error out, so replacing default error messages with more context-specific and helpful text can be a bit of a process, but it’s an important one.
According to Nielsen, the first rule of error messaging is that there should be an error message when an error has occurred. (Of course, to do this, you might need to do some usability research and expand your application’s definition of what qualifies as an error.) But once you have a message, make sure it also:
1. Explains what happened.
2. Uses intelligible and polite language.
3. Tells the user what to do next.
4. Explains how to avoid the error in the future (when applicable).
On this last point, Nielsen actually suggests linking error messages to relevant documentation.
#5 Problematic Default Values
Not supplying default values means more work (and perhaps some guesswork) for the user. Supplying bad default values forces users to make good decisions (often before they are equipped to do so) in order to avoid errors and other undesired outcomes. Therefore: only apply a default if it satisfies 80% or more of cases. If no value meets this qualification, do not apply a default and, instead, clearly communicate that a decision is required from the user.
#6 Tiny Text
Tiny text, tiny drop zones, tiny icons: avoid them! Screens are rough enough on people’s eyesight without the addition of miniature UI elements. Browsers enable users to zoom in on web applications, but designers would do well to save people this added step. Tiny text is easy to overlook and/or misread, tiny icons are difficult to distinguish from one another, and tiny drop zones result in wasted time as users attempt again and again to complete a drag-and-drop action.
More and more, software developers are adjusting their UI designs to better accommodate users with color blindness, deafness, dyslexia, autism, and other physical and cognitive conditions. Making sure color and contrast ratios meet WC3 guidelines for low vision is as important as providing text alternatives for images and icons, which computers can then read back to the blind. Transcriptions and subtitles may be provided for those with auditory disabilities (or anyone without access to sound). Making font face and size easy to adjust can help those with dyslexia and autism understand text more readily. And lastly, designing for the physically impaired means creating alternate means of manipulating UI controls and perhaps relying less on things like right-click menus and multi-stroke key commands.
If you enjoyed this, you might also like How Sketch Revolutionized My UI Design Process, in which UI Designer Duke Kisch explains why Sketch became his all-time favorite design application. Happy Halloween from Exago!