5 Common UX/UI Failures with Simple Remedies

Photo by Lauren Mancke

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” page title paired with “Sign In” form label

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.

“No thanks, I prefer to be miserable in the morning”

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.

Sort your filter

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.

Absolutely nothing is indeed an invalid ID.

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.

Meditator, experience designer, technologist, international public speaker, writer, family man, soccer addict, activist ✊🏻