Create Better User Experiences by Applying Confirmation and Authentication in the Right Places

 

Let’s face it, no one wakes up in the morning and jumps out of bed looking forward to going to the login page. For a long time, authentication has been something we’ve been forced to do on the way to doing what we really intend to do. 

This begs the question: Are applications, in fact, negatively impacting the user experience by requiring users to go through the painful and lengthy process of signing in before they actually get on with the task at hand – whether it’s making a purchase or depositing money into a bank account?

From my perspective, the answer is yes. Fortunately, there’s a movement afoot to de-emphasize authentication in favor of confirmation. 

When does authentication matter? 

Let’s examine some typical transactions. When a user engages in a transaction online, there is a whole set of actions they take with varying levels of assurance about their identity at every step. As the user moves closer and closer to an action that has consequences, businesses and other organizations need to look at the actions in the sequence and ask: “How important is it for us to know who that person is, and how confident are we that we know who is involved in the transaction?” 

The answer is that it all depends. In many cases, the identity of the person performing an action hardly matters at all. Let’s say you’re paying a traffic ticket online. Does your municipality really care about who pays the ticket? You do, of course, because you don’t want your car impounded, but all that matters to your city or county is that they receive the money in one form or another.

Similarly, when you purchase an item online, the e-commerce company is primarily concerned that the method of payment is valid and appropriately approved. They really don’t care who is buying that toaster, hair dryer, or eBook. 

Financial services organizations have also realized that multi-factor authentication is not required for every single online interaction. For example, when it comes to mobile apps, many banks are now giving their customers the option to automatically see their account balance on the “Hello” page. Banks know that displaying this information isn’t really risky until the user wants to do something, and, at that point, the user needs to authenticate with a password, face ID, or thumbprint. 

Here’s an example where the need for authentication was questionable. Recently, there was a mandate that U.S. government agencies were required to use Level 3 authentication (two-factor authentication). The Department of Labor decided to do an analysis of the resources they made available online and discovered that this level of authentication was completely unnecessary because many of the documents were public access information. In the physical world, you could simply walk into one of their offices and pick up the hard-copies. So they questioned why they made it onerous for the user to get those documents online and made some changes to simplify access.

In other instances, authentication does matter at the outset. For example, when an individual flies home from a foreign destination, it’s important to make sure the person who is entering the country is really who they say they are.

And there are times when applications call for occasional authentication. But if not handled properly, that can break the user experience if the authentication request comes at an inopportune moment. Mobile payment apps are really convenient for paying toll charges while you’re driving, but what if the app asks you for your password when you’re at the toll booth? And what if that password is in a password manager on your laptop – which you left at home? 

So the lesson here is to evaluate whether and when you really need authentication. All these real-world examples underscore the notion that validation for various transactions and activities require different levels of assurance. But I do believe that the general approach organizations can take for most applications is this: if they feel fairly comfortable about who the user is, they don’t have to get in their way. If they do the job of knowing who the user is really, really well, then they should be able to reach a point where the user isn’t even aware that this is happening. The process of going to the login page should be almost invisible. In fact, there probably isn’t even a login page!

By using confirmation rather than authentication where it makes sense, the user experience becomes more natural, more like the real world. When you go into a department store, you load up your shopping cart, and then, when you get to the checkout counter, you are asked to show that you can pay for the merchandise. And most of us feel okay about that. It’s a quid pro quo transaction – you’re expected to produce a valid form of payment and ID, and you receive something in turn. 

Amazon is a master at this. After you’ve shopped at Amazon a few times, you don’t get asked for any form of authentication. For Amazon, it’s far more important to show you merchandise that you may want to buy. When you’re ready to purchase, you just add to cart and place your order. If the item is pricey, Amazon does have certain paths to identity authentication. It’s obvious that Amazon is very cognizant of where the consequential actions are being made – and where certain levels of assurance should be applied. 

It really comes down to this: as long as it’s a recognizable device and browser doing things that the user normally does, we can be somewhat confident that the user is who they say they are or who we think they are. Where there are transactions of consequence, they can verify that this transaction is being performed with appropriate authorization.

If an organization’s goal is to retain customers and acquire new ones, it wants to make things as easy as possible for them so they’ll keep coming back. Maybe it’s time to rethink how to handle authentication in applications. Where does it truly matter, and where is confirmation sufficient? When the right balance is achieved, users will be happier and more loyal. And that just makes good business sense. 

Click here to learn how to deliver exceptional login journeys for your customers. 

Stay tuned for my next blog on “User-Managed Access and Everyday Experiences.”