Best way to verify Email/Mobile

Question

I am currently trying to figure out the best user experience for VERIFYING an email or mobile phone number.

Our company deals with money, so this has to be secure. Also our demographic is skewed a bit older now or less tech savvy. So this has to be as easy as possible. Also, They must verify their email/mobile before they can use their account. Unfortunately, This is non negotiable. We have to be able to communicate with them somehow.

Here are some details of what we're looking at right now.

1. A user can verify their mobile/email by typing in a verification code on the site. The user gets a text/email with a code that they fill in on the page. This is the best option for non-tech-savvy users. Downfalls are that they have to type a number. basically... It's just not inventive and feels old.

2. A user can verify by clicking on a link in text/email and going to a dead-end page. This is nice only because they don't need to copy and paste anything (unless their email is non-HTML, then they copy and paste a link). What happens after they click the link? Right now, the link leads to a dead-end. A page opens and says "you're verified". The downfalls are that the user has to find their old tab, which could potentially be on a different browser now (assuming the default browser was different than where they started). The user could feel like there is nothing else to do, even with messaging directing them back.

3. A user can verify by clicking on a link in text/email and continuing the process from there. The user can click on the same link as above, but the page is not a dead-end anymore. The fear is that the browser is not default and they could be placed into a bad browser that does not support javascript (for example). Also, their last tab then has to die. This is possible, but leaves the user with a dead tab. Again, there's a big fear that they couldn't continue on a default browser assuming it is different. Also, session management would be a bit difficult, having to use server-side code to connect a token to their "session"

What are your thoughts out there? We currently have a link (#2) and the verification code as two options. We have a time limit of 10 minutes to make sure the registration doesn't expire.

Answer 1

This decision can be made by analyzing design constraints

I (and I'll bet many other designers) have worked through this exact decision several times. I'll lay out a typical set of pros/cons:

---

1. Type in a one-time code (OTC)

• Pros: If your app is global/international and needs to address markets where some users may not have smartphones (e.g. developing countries), then this is one of the best ways to ensure users can actually use the interface because a mobile link will not work.
  • Note that some companies now (e.g. Google Voice) take this a step further and give users the option of receiving their OTC using a voice message (Twilio offers this capability), for situations where users may not even be able to receive SMS.
• Cons: For the majority of users (who do have smartphones), typing in the code is a waste of time and effort when they could just follow a link. It creates unnecessary friction in the UX, and is more likely to result in input errors which can be frustrating to users.

---

2. Click a received mobile/web link and continue the process from there

• Pros: In theory this can improve overall flow because users only have to context switch once (to their mobile phone or email client) and can continue the process from there after clicking the link.

• Cons: In practice, this is usually a poor approach. To illustrate, a user may be signing up via desktop. She then receives an SMS and follows the link on her phone. She now is forced to continue on her smartphone when she expects to finish the signup and use the app on the desktop. She could certainly copy the link to her desktop or finish the signup process then log back in on the desktop, but this is not a guided process and is likely to elicit frustration.

  • It's usually better to assume the user wants to finish using the same client as she started with, so this approach is rarely the right one.
  • This approach can be used successfully with mobile-only apps, where you know that the user is starting with the mobile app client and will finish with the same client...so providing a link that leads back to the app can work well. There are still hazards though, because the user may for example pull up the OTC email via desktop.

---

3. Click a received mobile/web link and get to a landing (dead-end) page

• Pros: This fixes the issue with approach #2 and allows the user to continue using the same client/session as he started with.
• Cons: The approach requires an additional step for the user to switch back to his signup client. The additional step needs to be clearly communicated on the landing page, because users may feel anxiety about closing a window/tab as part of a signup process.
  • e.g. "Congrats, your email has been verified! You can safely dismiss this window and continue with your signup process".

---

Only you can decide which approach is best because the pros/cons need to be evaluated against your app needs and user base.

If it helps, I think the state-of-the-art practice today is to combine approaches:

• Provide multiple paths of verification so users can verify via SMS, voice or email. You already incorporate some of this by giving users the option of email vs mobile.
• Make verification the last step of signup so that if users screw up page dismissal (e.g. accidentally close the entire browser, or abandon after the landing page) you've captured all the other signup information and can create the account and remind users to verify later.
• Allow verification post-account creation. If users don't want to verify now, allow them to create the account then require them to verify later (e.g. to access account features which require added security). This reduces friction on signup.