Goal

Design a simple and intuitive login experience while providing security protections from potential bad actors.

Why two-step verification?

Two-step verification, or sometimes called two-factor authentication (2FA), was disabled due to measures to address self-support during COVID at the request of the customer support team. At least 50% of customers would be impacted by this update. When the company was ready to enable 2FA again, there were several goals in mind:

1. Increase security by re-enabling 2FA with minimal user impact.
2. Increase remembered devices to simplify the login experience.
3. Re-examine the flow as a whole.

My role

I was the designer working under the lead for the login and authentication journey. I also worked cross-functionally with various stakeholders and teams including project manager, researcher, copywriter, digital security, design systems, accessibility and engineers

Examining the current experience

Since I was improving upon an existing flow, it was crucial to understand how it currently worked—that way we weren't reinventing the wheel. Here, I mapped things out as best as I understood them, then met with engineers to confirm and make corrections where needed. This helped me get an deeper understanding of the the different paths a user could take.

Looking at the landscape—a comparative analysis

Next, I captured industry benchmark examples of 2FA flows, which would allow me to ideate, test and build onto seemingly proven experiences, as well as look for inspiration and themes.

Noted themes:

Ultimately, what seemed to be the deciding factor for reviewed interations boiled down to how much security vs. ease they wanted to provide users. For example, on financial related services where privacy and security was of the utmost importance, 2FA methods were often more robust, sometimes not even allowing users to remember a device. Other services were more lax, like with shopping or travel experiences where there would a less of a need for privacy and security, and more of a priority on convenience and ease.

Another interesting theme discovered was that some services (usually the largest companies) allowed users to authenticate with their own internal company apps, allowing users to bypass weaker 2FA methods like SMS text.

So, what do users want?

I put together a concise user story, to keep the goal plain and focused.

User story: As a T-Mobile customer, I need a way to easily and securely verify who I am, so that I can access my account.

'Ease' speaks to the fact that logging is a burdensom task that ultimately interrupts the user's original task (e.g. logging in to do something else, like paying their phone bill), and 'security' speaks to the needs from both the business and user, for their account to be accessible to authorized users only.

'Remember this device' — radio buttons or checkbox?

The current experience, which utilized radio buttons, forced users to make a choice on whether they wanted to "remember this device." Instead, we explored an alternative using a checkbox, which would aim to reduce cognitive load, friction, and allow users to complete their primary task: signing in. All the while still giving them the same ability to rememeber their device.

“Radio buttons indicate making a choice between options, as checkbox seems to imply you could take no action with it and still proceed.”

What was interesting was that in the small usubility study conducted (n=15), 60% of participants said they preferred radio buttons, while 40% preferred a checkbox. However, at this small sample size and proportion of responses, both options were still considered acceptable. Ultimately, we felt that the checkbox would serve a subset of users that radio buttons would not (those who wanted to log in, but didn't want to make the additional decision of remembering their device. Radio buttons forced all users to complete the additional step, potentially increasing friction or decision fatigue, espcially when they could be trying to accomplish an important task like paying their bill or purchasing a product.

Contextual messaging explaining why users would want to remember their device — on-page or modal?

When testing whether participants preferred an on-page contextual message versus having a button with the message contained inside the modal, 73% preferred the on-page version, and only 27% preferred the modal.

“I don’t want to click a link unnecessarily. I feel it is not trustable. I might end up deleting the app as it is very fish.”

“Trust this device and then the words ‘What’s this?’ Is not an acceptable option. I feel annoyed to see that question.”

Ultimately, while the modal would offer a cleaner experience with much fewer words on the screen, it would likely mean most users would not ever click through to read the message. Looking back, I would've also liked to see how a checkbox vs. no message at all would've performed.

Copy: 'Remember' or 'Trust' this device?

I also wanted to test different copy seen industry benchmarks. My hypothesis was that "Remember" would be more preferred because it was more specific about the function of feature, whereas "Trust" could hold meaning beyond its specific intent, that could turn users away from selecting it. With data breaches being so commonplace, do people really trust their digital services? The results of the user study confirmed more participants preferred "Remember this device" (73%) to "Trust this device" (27%). And though the study sample size was not large enough to say this with certainly, we felt confident enough in this decision.

“'Remember this device' is a low security compromise which makes access to my account smoother and faster.”

Ordering of options: participant preferences

I based the ordering of options on both users' preference and level of security. Text message was by far the most preferred (but not necessarily the most secure) so we placed it first. Biometric login (fingerprint of face scan) is one of the more secure methods, so it was placed second.

Usability study results

• 58% or greater chose text message
• 21% or greater chose fingerprint or face
• 8% or greater chose security questions
• 8% chose email
• 0% chose Google Authenticator

Security vs. ease

Taking a look at T-Mobile's available authentication methods, I evaluated each in terms of security and ease taking into account feedback from the digital security team, participant responses and heuristic evaluation.

Contextual error states, helping guide users

Additionally, error states had to be re-examined and rewritten as many were overly technical and contained jargon that typical users would be unfamiliar with. In total there were 12 error messages for 4 device sizes (iOS, Android, mobile, desktop), which all had slightly varied copy depending on the component that was to be used.

Flows

The handoff included flows mapped out for web (desktop & mobile) and app (iOS & Android), as well as the high-fidelity design files.

Final Designs

Interactive prototypes for usability testing

I created 4 prototypes for usability testing which included 1 control and 3 proposed design changes. 3 were needed in order to isolate an accurately collect and observe the specific changes we wanted to test.

Key Design Updates

What next?

Ultimately, removing the need for 2FA altogether would greatly improve the user experience. Logging in, while necessary for digital security, interrupts the user from accomplishing their original task—whether that's paying their phone bill, managing their account, adding a line or buying a new device.

Some ideas include:

• A passwordless login, like a one-time pin/button confirming their identity.
• In-app authenticator, where users don't need to download a separate authenticator.
• Inceasing single-factor biometric authentication, which usually has a high enough security level to not require 2FA.