Delighting and satisfying the users of a website or app is the goal of good user experience and of good design. After all, smart design decisions lead to great user experiences, and those experiences translate into happy users.
In order to avoid frustrating and annoying your end users, here are some common usability mistakes to look out for...
Neglecting empty states
Simply put, an empty state occurs on a screen when there is no data to display. The empty state can be the result of a user completing all tasks in the task list or not yet adding any contacts to an address book. With either scenario, the user is seeing a blank screen or section of a screen without understanding why it’s blank. For all they know, it could be due to some sort of an error. (I’ve conducted many usability tests and trust me, the first conclusion they usually jump to is that they did something wrong.)
Instead of leaving that area blank, use this as the perfect vehicle for instructing the user. Let them know a bit about the feature, why it has no data, and any actions they can take. (Yay! You’ve completed all your tasks!! Use the Add Task button to create some new ones.) Designing for the empty state is a great opportunity to add value to the user’s experience and help them use the application.
Not designing error pages
I’m sure by now most of you have seen some of the very creative thinking that goes into designing the 404 or 500 error pages. And why not? It’s a great opportunity to extend your brand, add some fun messaging, and make this glitch a more delightful experience for the user.
More importantly, gracefully displaying an error message reassures the user that while things may have gone wrong, it’s not the end of the world. With that in mind, when designing these pages be sure to show the user some next steps, either via search box, links, or page copy, so they are not stuck. They may have reached a dead end, but you’ll show them the way out.
Unclear button labels
Although not as common as it used to be, I’m starting to see Submit labels crop up more frequently. Such an unhelpful word! It gives no indication of what the button click will do for the user and no indication of what to expect. If they’re a bit knowledgeable, your user may surmise that the information will be written to a database, but quite honestly that still doesn’t tell them much.
Button labels should tie back to the action the user is doing (e.g., Create Account, Save Updates, Delete Contact), so that when the user clicks the button they know what to expect. The account was created, the updates were saved, the contact was deleted. Descriptive button labels may seem redundant since the user is on the form specifically to take that action, but letting the user know what happens builds trust in the site.
No user feedback while waiting
There are many activities that could cause a user to wait for a page to load, especially on complex sites with complex queries. If it’s the direct result of an action taken by the user (e.g., uploading or filtering versus clicking on a navigation link) they may have a higher level of tolerance. Their patience, however, is not infinite.
In order not to try their patience, make sure you design for these scenarios. Let the user know why the page hasn’t yet loaded or why the table isn’t showing any data. Provide visual clues, such as a spinning animation or a progress bar, along with an explanation of why the page is not showing anything (e.g., we’re retrieving your search results). Letting the user know why this is happening relieves their anxiety that something went wrong and may even increase their tolerance a bit.
Not catching form errors up front
There is nothing more frustrating than filling out a form, submitting it, and then receiving back an error message that could have easily been corrected while filling it out. This happened to me recently when the address fields were populated from my password manager app. Once submitted, my info was quickly rejected due to the zip code being too long. They failed to inform me that only five digits were needed for the zip code.
This is a long-winded way of saying wherever possible, alert users to errors before they submit the form. There’s no excuse for not catching syntax errors, no data in required fields, passwords not matching when creating accounts, etc., while the user is filling out the form. A bit of effort up front avoids frustration and potential abandonment on the user side.
As for my experience, a silver lining is that the site didn’t lose my data when the form was redisplayed. Remember to do that, as well, whenever possible. It’s good usability.
The above tips are the details that will reduce the annoyances we often encounter while using an application. Keeping an eye on those details will contribute towards making an app that’s enjoyable to use.
Alice Toth
