One-time passwords –vs– embedded links
I was recently working on a project for a customer account portal with over 450,000 active users. Part of the project involved helping users who’d forgotten their password or username (or sometimes both) as well as verifying any major changes they made to their account. The current method of verification token was to email a reset link, as it gave users an easy one-click solution. But what happens if their email account wasn’t readily available on the device they’re currently using? I decided to look for a better solution, and these are my findings.
Clickable links are the most convenient for users
There were reservations from senior stakeholders around the merits of using a one-time password (OTP) rather than just clicking an email link. Making users read, recall, and type a password (usually 4-6 digits) was not as fluid an experience as just clicking a link. So why give the user something else to do?
On face-value, a clickable link looks like the obvious choice for an easy user experience. Especially when, in the example (below) from NOW TV, the usual hyperlink text is replaced with a clearly identifiable CTA button. Their particular approach has additional benefits as many people are suspicious or reluctant to click on traditional text links – we’ve all been schooled on the dangers of embedded links within emails. In contrast, the Amazon method looks cheap and lazy, not helped by the layout, design and small size of the emailed OTP in question.
It’s worth noting that both OTPs and embedded links can be sent via SMS. For the purposes of this write-up, SMS was out of scope on this particular project due to the technical architecture being used, as was two-factor authentication.
What if we focus instead on the users’ primary goal?
I looked at how a user could ultimately achieve their goal. Namely to regain access to their account after forgetting their password or username, or to make an important change to their account, such as confirming a new password or an update to their bank details or address.
Senior management were very much in favour of the embedded link solution. It was already in place, and they viewed having to input a code manually as unnecessary friction. They also wanted to “encourage” users to adopt their native app, and so were looking for a more mobile friendly solution to the whole user account experience. But this in turn assumed all users would have their email accounts on their mobile devices – or on the same mobile device they started the journey with. Many people have smartphones and tablets, and some even have both work and personal phones.
I created a quick slide deck for senior stakeholders, as they were in multiple locations, and my personal access to them was limited (being a lowly design contractor). In the sample diagrams below, the specified primary goal was for the user to successfully register an account. Therefore it was imperative that this was front of mind when deciding which verification token method to use.
The happy path :)
Pic 1: Users can complete their task on a single device (or computer).
While a clickable link or button is the easiest user input method, it only works in optimal journeys (or “happy paths” as I once overheard and have now adopted), namely that the user is able to start and complete their task using the same device.
The unhappy path :(
Pic 2: Users cannot complete their task on a single device due to lack of email access.
However when a user does not have access (or easy access) to their email account on the same device, the task is impossible (or awkward) to complete. This is where the perceived convenience of an embedded link falls down. If the user is trying to update their bank details, or recover a forgotten password, this can be immensely frustrating, and most likely result in a call to the customer services team (probably with an automated menu and then a healthy dose of hold music). Not ideal, especially if making a call isn’t convenient at that moment.
The users' primary goal
OTPs however, while adding some friction to the process, do allow a greater opportunity for completing a task because they don’t rely on the happy path scenario. Users are free to switch to a more convenient method of accessing their email account. And this doesn’t necessarily mean just those who don’t have an email client installed. What about scenarios where users need to sign into email on the computer they’re using, but have it to hand on their phone? Or the “It’s just easier to see on my phone” when recovering a forgotten password while online shopping on a laptop (as in the case of my partner). In today’s multi-device world, holding users to a single device is not ideal, nor as it seems at times, convenient.
Pic 3: Users can switch devices if need be (or choose) to complete their task.
Remember the app download bit?
As I mentioned, senior management were very keen to increase the user adoption of their native app. In the case of an email link, this would have proved problematic for all users not routinely accessing emails on their smartphones or tablets. Currently around 46% of emails are opened on mobile devices. (source; Sleeknote.com). With the OTP route, that could conceivably mean more account registrations via App downloads as users have a higher chance of successfully completing the task (as seen in pic 3). Otherwise the whole journey could be abandoned if using an embedded link.
Security
I spoke with the development team and system architects from the company, before I committed to selling the OTP route to ‘upstairs’, just in case there’d been a valid reason embedded links had previously been implemented. It turns out there wasn’t. There’s no difference in security for either method. “Both are equally successful at delivering the verification token required by the system”, I was told. With both methods, including a one-time use and time limit is also best practice.
One difference with links however is that they can be subject to spam filters, and potentially get blocked. More worryingly, (since I started writing this and sharing with engineering contacts) I’ve been told of instances with certain email clients, where embedded links were clicked without the user opening the email, through a process called ‘enhanced security’. Another reason to favour OTPs!
But haven’t you heard of Magic Links?!
Yes of course, and they’re great at doing what they’re designed to do – to allow the user to quickly and easily log in to their account without the need to create and recall a complex password. But they still don’t solve the issue of helping the user in a critical flow to navigate around a problem such as not having access to the email account on the same device.
One possible hybrid approach might be to include a ‘copy link’ function within an OTP solution, enabling users to copy and paste the OTP (assuming they continue to use the same device), thereby removing the need to type at all.
Conclusion
Users have a higher chance of completing their goal with a code-based solution rather than a direct link.
My recommendation to senior stakeholders, from a user experience perspective, was to implement an OTP approach as, in this particular case, it gave a far greater chance for users to complete their journeys successfully by;
Allowing choice on how best to access their email account
Giving control on device(s) used (eg: convenience of a full-size keyboard rather than using a phone, or easily accessing their email on another device as they're already signed into it)
Supporting user preference on browser choice (links will open additional browser windows, and even a different browser depending on system configurations.)
The assumption could also be made that users who can complete their end goal are less likely to need customer support, freeing up these channels for those with more challenging queries. Well the evidence will be there soon enough, as the OTP method was agreed by all stakeholders, and is currently in build.