Omni Experience Design

Adaptive Authentication


Experience Designer


Sept 12, 2019


March, 2020


Your security, comes with adaptivity.

The Team

I was the only experience designer for this project. I was in charge of everything on my own through the whole product cycle.

The Time

I spent around three months on this project and tested three highly feasible concepts, of which I picked one to proceed.

The Deliverables

Aside from high fidelity mockups, I delivered three user research reports, three different service blueprints, two workshop briefs, one concept testing result, two usability testing results, and other miscellaneous items.




I woke up early on a Saturday morning to check my billing information as the billing reminder text Verizon sent to me seemed to be wrong. I turned on my computer, typed in Verizon website URL, and waited for the Verizon login screen to load.

I sipped a coffee, stretched my arms and legs, and started to type my phone number and passw... Wait, what is my password again?

After a few tries, I stared at that miserably orange warning banner, "The information you entered does not match the information we have on file." and finally decided to reset my password. "It is a piece of cake!" I thought, and...what is my security answer again?

My account was locked, unsurprisingly, and I felt so defeated. To unlock it, I had to go through a "one-time security code" process and reset my password. It was definitely not a good start for a pleasant day, and you know, I was not the only one. There were millions of Verizon loyal consumers facing the same embarrassment as I did.

I gotta fix it.



An even more serious problem lies under...

Ten million user authentications failed in the year 2018, and more than half of them got their accounts locked at least once. Ironically, scammers pretending to be Verizon representatives took advantage of "one-time security code", and were able to trick users to read back codes, and then bypass the current Verizon security system to cause millions of dollars losses each month, including hardware, services, and identity theft. The problem is always there, and it has to be resolved.

The recognition gap was obvious here: Even in the security messages that Verizon sent to users stressed clearly that Verizon will never ask you for this code", users either never read, or still read back the plain code to scammers as they thought it was a one-time exception, as scammers sound quite credible and convincing. We cannot blame users for not following our warnings, of course, and we cannot stop users from reading back plain code to scammers...Oh wait, can we?

The goal is pretty straightforward: I want to design a new robust authentication approach that
1. Allows users to easily and securely authenticate themselves (hopefull they do not need to remember anything).
2. Prevents scammers from bypassing the Verizon security system in place.

I called it Adaptive Authentication.



What is the Status Quo?

As always, I started with users and listened to what users say. With help from the Research Team, I found eight fraud victims to talk with us regarding how they fell into traps when scammers tried to trick them. The interview results were surprisingly unsurprising.

Four of them ignored reading the whole text. They only searched for plain code contained in the text message and read back. Two of them read the whole message and saw the warning "Verizon will never ask you for the code", yet still read back the text without any suspicion, thinking it was a one-time exception since they were on the phone with self-claimed "Verizon representatives". Two of them had some doubts but were convinced by scammers as they sounded credible.

Data from the Security Team and the Fraud Prevention Team further validated what we got from user interviews. Due to security reasons, I cannot publish any data here, but I can explain further why our existing security structure is inherently faulty from the user's perspective.

At the moment of design, Verizon used User ID (including Phone Number) and at least one of the three credentials to authenticate a legitimate login attempt: password, security question / answer (including zipcode), and one-time security code. Let's examine these three types of credentials:

1. Password: Password is very easy for users to forget while easy to leak in any data breach. Common users tend to use the same password across different accounts.
2. Security Question / Answer (including zipcode): This type of credentials can be easily "social engineered" by hackers.
3. One-Time Security Code: This type of credentials does not need any memory burden, but it can be easily intercepted, forwarded, or read back as it contains plain codes.


Quantifiable Success Metrics

Define a success that I need to achieve.

We used many internal data sets to measure success but due to security reasons, which I cannot publish online. One of the key metrics was the fraud rate, which was X% before the design. The goal was to cut the fraud rate from X% to Y% through a new design, which is over 80% drop. (I can only tell you the difference, not exact data for confidentiality reasons)

Let's save our customers and ourselves.


All inclusive activities

Persona + Pain Point + Use Case + Channel

I invited key stakeholders from the Security Team and Omni Channel Team to my workshop to provide me with valuable feedback and key data points when I worked on different personas, use cases, and proposed user journeys. As I mentioned before, every type of credentials that Verizon used has some kind of vulnerabilities that either need to be enhanced or replaced completely.

1. Password. Increasing password complexity is not an option as it will for sure increase the authentication fallout rate. Ideally, I should eliminate the password.
2. Security Question / Answer. I should remove them as well.
3. One-time security code message. I need to replace it with something that is non-forwardable, non-readable, and non-replicable.

Overall, this new experience should have nothing for customers to remember, and nothing for hackers to take advantage of, in a bad way.

We identified four typical scenarios with that in mind:

1. Step Up: This is when customers know the correct password but in an unrecognizable or unsafe location.
2. Forgot Password: This is when customers forgot the correct password and need to reset their password.
3. Sign In: This is when customers log in at a recognizable safe location.
4. Unlock Account: This is when an Account Owner or Account Manager wants to unlock the account.

We created four personas to accommodate four different scenarios.

As it is an Omni Channel Experience, it would work on both My Verizon Website and My Verizon app.


Concepts & Service Blueprints

From How Might We to concepts, sailing with ideal Service Blueprints & System Paradigms

I want to explain three common factors used for authentication as it played a great role in the following conceptualization process: something you know, something you have, and something you are. A more robust authentication system needs to take advantage of the latter two.

1. Something you know (least secure but replaceable): It could be a traditional password, or security question / answer.
2. Something you have: It has to involve something physical, a smart device, a smart card, etc. For example, a QR code that needs your device to scan falls under this category.
3. Something you are (most secure but irreplaceable): It could be a fingerprint, your voice, your iris, your interaction pattern or other biometric method.

A simple fact: 94% of the customers always take phones with them. This data makes it valid to use their physical devices as "something you have" to replace "something you know". With this in mind, I started to create different concepts and user journeys.

"Something you know" was what I needed to replace with "something you have" or "something you are". After several rounds of discussions with the Security Team, we decided to take a phased approach due to business situations, focusing on "something you have", and in the future, on "something you are" for maximum security. Thus, at the stage of this design, I only focused on "something you have", namely, users' smart phones,

Talking with the Security Team has been always fruitful, not only did they tell me the common pattern of scams, but also what information we knew about users: We always know users' devices and SIM cards to provide services, and their devices are the perfect credentials/authenticators to authenticate themselves. So the direction is clear now: I want our customers to use their phones as authenticators to authenticate themselves.

The next question goes to what a smartphone commonly can do: It has a screen to send/receive text messages and open webpages, it has a camera to take photos or scan QR code, it can install My Verizon app, and it can also record voice. We started to list them all in the workshop. Finally, after balancing out the requirements between users and businesses, I created different concepts for the team to review based on different ways of authentication.

1. QR code. If users want to sign in to our My Verizon website on desktop, we can ask them to take out their smartphones and use My Verizon App to scan the QR code. The good thing is it is contactless, no input of any kind whatsoever, the bad thing is they have to be app users.
2. Push notification. If users want to sign in to our website, we send a push notification. The good thing is it is more secure than Text Message, the bad thing is they have to be app users.
3. Text Messages. Text messages can be vulnerable or invulnerable, depending on what information we send to users. If we send some transferrable information such as plain code to users, it is considered vulnerable. However, if we can send some untransferrable information to users, it is considered invulnerable (and yes we actually can).



Proof of concept

I designed different concepts and partnered with the Research Team to validate. Here is what we got in general:

1. QR Code. In QR code concept, if a user wants to login on the desktop website, this user needs to have My Verizon app installed and use app to scan the QR code. Apparently, this only applies to those who have the app installed in order for us to authenticate, and QR code will exist on the desktop website only. Although it was quite an idea, concept testing shows QR code, unlike in Asia, is not at all popular in the U.S., so I put it in my parking lot with my focus on push notification and text message.
2. Push notification. Push notification is secure as it is non-transferable. Users treated push notification as a common interaction while they interact with different apps every day, and thus there is no recognition gap. It is only valid on the app.
3. Text message. As a fallout option for those who do not have the app, text message is still used, in which plain security code is replaced by a non-transferable tokenized link (thanks to the knowledge from the Security Team). This link is encrypted and can be only opened on the device intended, and if it is forwarded to another device, it will only show an error message. Some testers did express the concerns over the authenticity of the message sender (as to how they can tell it was really from Verizon). However, since they only receive this kind of messages right after they want to perform something critical, it can be highly unlikely forged. The risk is very low.


Initial Design

Initial Design

The initial design cared for login (including step-up) and reset the password, for both app users and non-app users, to cover the majority of our customers. The whole process is imperceptible and adaptive to users as we decide, in the background, if we should send a push notification or a text message, depending on if at this exact moment a user has the app or not.

The legal team insisted that I should add Billing Zipcode for some legal reasons (and I cannot publish here), so I put it back. Fighting with the legal team is a fight that you can never win.

The initial design was pretty much the same as the final design. I will show my design part in the "Final Design" section.


Usability Testing

To be happy, or not to be happy.

We conducted one round of usability testing and received positive feedback from eight participants with almost no complaints on the experience itself. The changes were mostly on copy.

Both text message approach and push notification approach were well received by participants. When asked about Billing Zipcode, participants did mention while it did not impact the overall experience, it was still not necessary as long as this adaptive authentication process is secure. Still, it is all about legality.


Final design

Final Design.

I did not change anything major about the experience, as our usability testing results came back pretty solid.

Please reach out to me for an interactive demonstration.



Impact, data tells you.

After the implementation of the new authentication design, our fraud rate dropped significantly from X% to Z%. After follow up with the Security Team, I realized that Z% happened on some users lost their phones, or on some users who are non-smartphone users. It is a 90.8% fraud rate drop. (Data redacted for confidentiality reasons)

I don't need to remember anything now. Thank God!

Verizon Customer

Research Participant

...fortunately link was not working after I forwarded it to scammer.

Verizon Customer

Real use case

Secure, smooth, simple.

Verizon Customer

Real use case

Really beyond my expectation!

Verizon Customer

Real use case

It was quite easy (to change password).

Verizon Customer

Real use case



I did not stop here.

If I had more time, I would try hard on QR code interaction as it is an input-less experience, which I believe would have a lot of potentials in the U.S as well.

I learned two key things from this project:

80/20. Once my mentor told me, "Think 80% of your time and design 20% of it." and this is how I design in every project. Think again and again before the actual design. It saved me a lot of hassle afterward.

Be bold, think big. Don't hesitate to try if you believe you are right, even it was not part of the final design.