8

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.

Improve this question
8
  • Explain the 'dead tab'. Why is that? Does your software not support running in multiple tabs?
    – DA01
    May 1, 2015 at 21:42
  • Also, a 10 minute time limit seems very heavy handed, though maybe it's necessary for your situation.
    – DA01
    May 1, 2015 at 21:42
  • @DA01 I don't know the situation but it seems reasonable as it's dealing with money.
    – Jon
    May 1, 2015 at 22:17
  • @DA01 either the old tab would be a dead tab or the new tab would be one. Just simply saying you can't go any further on that specific tab. Which scenario were you asking about?
    – ntgCleaner
    May 1, 2015 at 22:27
  • @Chipperyman, You're correct. We are dealing with personal accounts that hold money. Think, like a bank account.
    – ntgCleaner
    May 1, 2015 at 22:27

1 Answer 1

Reset to default
6

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.
Improve this answer
6
  • tohster, You've made some great arguments here. Let me comment on a couple: 1a. We only need to worry about the U.S.A., so we can focus on the statistics given by major carriers. 1b. We do offer voice OTC at the moment. 2. We are thinking of making the verification process different depending on where they start (Either Mobile or Desktop). We could serve different ways of verification depending on the platform. (1/2)
    – ntgCleaner
    May 2, 2015 at 0:22
  • (2/2) - Regarding your wrap-up at the end, I agree with you on all fronts. I'm going to see if our legal department will allow us to move verification to the last step. Our developers have warned against making verification a post-account process, simply because it will take a lot of time to "disable" the features not available. I would like to also explore the inverse of your second point - making verification a first act of the sign up process. I know it would be worse than the original concept, but if legal doesn't like the original, maybe we can find a good UX dependent on this.
    – ntgCleaner
    May 2, 2015 at 0:25
  • Thanks for the informed feedback. It's great that you have the resources to offer client aware flows here. For a financial institution, the additional steps/friction can actually be communicated positively to users as evidence that you care about their security (for your security, we need...), which can help change the user perception of friction.
    – tohster
    May 2, 2015 at 0:28
  • 1
    That's absolutely how we treat it. We try to make this very arduous process have the guise of a very secure operations. Which we are of course. Dealing with customer's money is a very strict process which is not friendly for a UX person (i.e. Having to agree to ALL legal agreements before moving on, and having to show the first 5 lines at least of each agreement)...... You've given me some great ideas. Thank you!
    – ntgCleaner
    May 2, 2015 at 0:34
  • FYI, developing countries are more likely to be accessing the internet via a smartphone.
    – DA01
    May 2, 2015 at 5:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.