Focusing On What Our Users Shouldn’t Focus On

Thanks to Marco Dini for the Italian translation to this article.

“What can we help you with today?”

“I’ve been locked out of my account and I can’t get your app to display my boarding pass.”

Everyone in the immediate area of Gate B6 could hear the ongoing support call, because the woman had her phone on speaker. It was the only way she could follow the support representative’s directions.

The woman passenger was trying to keep calm, but you could see the situation was taxing. The plane was starting to board and the app wouldn’t display her boarding pass, even though it worked when she went through airport security. At some point, the airline’s app decided she need to enter her username and password one more time, and that’s when she locked herself out of her account.

Now she’s talking to the fourth airline representative on the phone. Whoever answered the phone the first time couldn’t help her. That person transferred her to the Web Services Technical Support Desk, where she waited on hold, then started to talk to a nice person, but they were disconnected. Another call back to reservations, more hold time, and another transfer to the tech support group.

All because she couldn’t type or remember her password. The airline had recently updated their security and required tougher password rules. Rules that made it difficult to use the on-screen keyboard on a small mobile phone. You know, something like 22mFYvjzF4A(}7. Try typing that into an iPhone without making mistakes.

The woman couldn’t type the password, or maybe she was reading the writing in her address book wrong, but she wasn’t getting the right password in. Or maybe she had the wrong email address for the username? Or maybe she didn’t know what her username was, if it wasn’t her email address? After a few attempts, the airline’s security feature decided she wasn’t who she knew she was and locked her out of her own account.

Authentication Is, By Design, Selectively Usable

This woman didn’t wake up this morning thinking how awesome it would be to be locked out of her account. She probably wasn’t thinking about authenticating into the airline’s system. Instead, she was thinking about her trip and what she would accomplish on it. She didn’t want to think about whether she knew how to type her password into her phone.

Now, sitting at Gate B6, listening to the zone boarding announcements, she’s not focusing on her flight. She’s focusing on the hoops she has to jump through to get the airline’s app to display her boarding pass. She’s obviously frustrated and no one can blame her.

Authentication is a necessary evil in today’s world of trust, privacy, and security. It is designed to be selectively usable. A good authentication system needs to be unusable for unwanted intruders. However, it needs to be extremely usable for the legitimate users. Poorly designed authentication systems fail in two ways: either they let in the wrong people or they make it too hard for the right people.

But authentication shouldn’t be the focal point of a users’ experience with our designs. In fact, if the person is the right person, it shouldn’t be anywhere on their radar.

Authentication as Microinteraction

Most of the time, when we ask our users to “log in,” it’s just a quick entry of a well-worn username and password. They don’t give it much thought and it passes quickly.

However, we rarely account for all the things that can wrong. What happens when it fails? Suddenly, what should’ve been a small interaction becomes a big deal.

Authentication is a piece of the design—what Dan Saffer would call a microinteraction. (Dan coined the term and wrote a book on the topic, coincidentally named Microinteractions.) Microinteractions are small moments where the user and design interact. When well-designed they enhance the user’s experience with the design. When poorly-designed they hurt the experience.

When people talk about microinteractions, they rarely talk about the authentication screens. They often talk about fancy animations to indicate a successful outcome or a clever way to notify the user of an important new piece of information. Yet, authentication is one of the most prevalent microinteractions we see today. And it’s rarely done well.

Microinteractions that Steal the User’s Focus

Authentication steals the focus of the user. The user is no longer focused on accomplishing their intended goal. They are solely focused on convincing the application to let them in.

Authentication isn’t the only microinteraction that steals the users’ focus. Inscrutable error messages can have the same effect, dragging the user away from their objective to interpret what the system is trying to tell them. Or when the user scrolls to the bottom of a “infinite scrolling” list, only to not know if the system is still fetching more data or has finished. Or when the user receives an important system notification, but when they bring up the app to learn more about it, the screen doesn’t show the update because it hasn’t updated yet.

For a moment, the microinteraction has stolen the focus of the user. Maybe the system catches up and it resolves quickly? Even when that happens, it’s still a momentary distraction and distractions are…well…distracting.

Yet, what happens when it doesn’t resolve quickly, like when our poor airline passenger was locked out of her account? Now it’s downright front-and-center, preventing any further progress.

What’s happening is we have revealed our system’s architecture to our users. The users don’t need to know how the client application synchronizes data with the server. They don’t need to know how the system prevents malicious intruders.

Delivering Designer Love To The Focus Stealers

When we’re designing our applications and services, we rarely think about the microinteractions. When we do, it’s usually the flashy ones with cool animations.

When walking through the design mockups of a new feature, it’s rare to see an authentication screen. Even when a team is sharp enough to include that, they rarely show the screens that happen when the user can’t remember their password, tries multiple variations, hits the password reset link, has to jump through the hoops of resetting their password, and (hopefully) gets back on track. If they did, those screens would quickly outnumber the screens for the new feature.

Authentication is such a miserable experience because it never gets the love of the designers. It’s usually a byproduct of an engineering process that has evolved over time without any reflection or critique.

When in the design process do we look at all the places where the design can just go wrong for the users? Where do we get to design the interaction we’d want that woman to have while boarding her plane?

Rethinking the Authentication Microinteractions

To improve authentication, there are some simple things we can do. First, locking a user out is a bit harsh, especially after a small number of failures. If an intruder is trying a brute force attack, they’ll probably fail a dozen or so times. Why not increase the number to 12 or 20 times before a lockout?

Warning the user of the imminent lock out would be a nice courtesy. Even better would be giving better ways to talk to a support person, like a direct link to the knowledgeable counselor. (Our poor airline passenger had to copy the phone number from an error message, then manually dial it. Mobile phones have dialing phone numbers as their superpower. A good design would take advantage of that.)

These are a couple of simple things, but there’s even more sophisticated ways to design the authentication experience. For example, you can create a more detailed threat model, which outlines which information or actions in the application are sensitive (like a credit card number or the ability to purchase a ticket) and which provide little risk (like showing the boarding pass). Then, as long as the application knows the user’s identity, it can grant access to the low risk elements, while still protecting the user from fraudulent acts.

Dan Saffer has a framework that divides the design of microinteractions into four components: feedback, modes and loops, triggers, and rules. When should the authentication request be triggered? What feedback should the system give? What rules should the system use to trigger the request or to let the user through? Under which conditions (modes) or how frequently (loops) should the system insist on authenticating the user.

Focusing on What the User Shouldn’t Focus On

All of these are questions that the design team should focus on. I’d go so far as to say the most important microinteractions to focus on are those that our users should never (or rarely) need to focus on themselves.

We need to ensure our design efforts include those items where our system architecture is trying to leak out. We need to push it back and cover it with a delightful experience that we intentionally render for our users. That’s good experience design.