5 Common UX/UI Failures with Simple Remedies
--
As a UX practitioner, I see digital UIs through an acute lens. I notice all of the nuances and quirks, inherently making judgments about successes and deficiencies.
There are a handful of deficiencies that continually degrade my experience on websites. They are the UX faux pas that I love to hate, and I wanted to share them with you.
All five of these issues can be resolved by hiring a UX designer, but I have included simple solutions that you can use at home.
1. Authentication Labels (Log/Sign In/On Out/Off)
About six years ago I wrote a post about this. It’s as relevant today as it was then. Look closely, and you’ll see this everywhere.
Login vs. Log In: the phrases “login” and “log in” are different. The former is a noun and represents a location such as a “login page.” The latter is a phrasal verb which represents the act of logging in, such as “log in below.” Hyphens serve the purpose of fluidity in sentence structure such as “log-in details.” (This also applies to the act of signing up, used as “signup” and “sign up.”)
In/Out vs. On/Off: consistency is important. Once you’ve logged in you can’t log off, and vice versa. You either log in and then out, or on and then off.
Log vs. Sign: again — consistency. It is more common to log in than sign in, but either is acceptable. What is important is that once you have logged in you can not sign out.
Log vs. Sign vs. In/Out vs. On/Off: finally — you can never, ever log in then sign off. The process of authentication is not a square dance, a quilt, or a cocktail. You log or sign, in and out, or on and off.
Solution
I believe the issue here is a lack of communication between writer/information-architect (authors the label), designer (prints the label on the button/link), and developer (writes the URL and title tag). We can easily get this right with a predefined taxonomy that’s available to the entire team. Or a little communication with each other. Or both.
2. Shaming People for Opting Out
Auto-launching modal windows are quite common, but they always disrupt the flow in UX because they force people to disengage from the task at hand. Most of the modals ask people to sign up for an email newsletter or engage in a live chat.
In recent years I’ve seen more of these modals include language intended to be clever or humorous. But the end result most often focused on shaming people into submission.
TheSkimm assumes that their newsletter is the key to my happiness. My mornings are actually awesome, and I’ve never subscribed to their list.
Solution
Sure, be clever. But do so with kindness. A simple “no thank you” is perfect.
3. Using Filtering and Sorting Interchangeably
Filtering and sorting are two completely different interactions. Filtering uses deduction to condense a list of items, while sorting simply reorders them. This should be simple, but people get it wrong all the time. And not too infrequently, the worst offenders actually mix the labels together in the same view.
Solution
Understand the difference. Use one, the other, or both. Just use them correctly.
4. Premature Form Validation
At some point, someone realized that a hint of javascript could be used to validate a web form before submission, in real time. Client-side validation has pros and cons, which I won’t get into here. What I will note, however, is that if we’re going to validate on the client side, we need to do it correctly. That means not validating before people enter a value into a field (on focus). It means waiting until after they have exited the field (on blur).
I often complete data entry for a field, tab to the next, then — BAM! — an error appears. What exactly is being validated if there’s no data? We have to stop doing this to people. It’s startling. And rude.
Solution
Use client-side validation. It’s productive and usable. But please do so with integrity, by validating on blur rather than on focus.
5. Using the Label “Cancel” to Close a Modal or View
The word “cancel” has an explicit meaning in UX: “I do not want to complete this task.” It does not mean “I want to go back to where I was.” Alas, it is often used for this purpose, such as closing a modal or going back to a previous view.
A common example I see is when a checkout form is opened in a modal or a view. A “cancel” label is in view, which has context because I may want to cancel the task of checking out. Submitting the form reveals a success message in place, with the “cancel” option still in view. Before the form is submitted, “cancel” means “I don’t want to make this purchase.” After the form is submitted, “cancel” may now mean “I want to cancel my order.” This is the ambiguity that gives people pause.
Solution
The word “cancel” is not interchangeable with “back” in the context of a view or “close” in the context of a modal. Simply choose a better label that is contextually appropriate.
Good UX is important. It makes products more delightful and easier to use. These are common patterns that compromise UX. But with a little care, we can fix that. Happy UX-ing.
- Please click or tap that clap if you enjoyed this article.
- View my site to learn more about me and my work in UX/IA/research.
- Say hello if you want hire me for a project or speak at your event.
