Goal

Empower, encourage and educate users to self-serve, and increase their security.

Why a security meter?

T-Mobile wanted to create a feature and destination where various existing security features could be aggregated and easily shown to users. Increasing security was of signifant importance to the company and having a destination where they could discover and enable features that were already available would be a relatively cost efficient way to increase user security.

What security features could users enable?

The features that users could turn on were provided to us by the engineering and security teams and were as follows:

• Always on 2FA (on/off)
• Google Authenticator (on/off)
• Verify email address (yes/no)
• Enable biometrics (on/off)
• Password age (>365 days/<365 days)

How to determine level of security?

From a backend perspective, each security method would have a score determined by the digital securities team. All methods would total up to a score of 100 (if any new features were added, scores would be re-rated and total to 100 again).

What do security dashboards look like?

Noted themes:

Visual meter

Security score

Step-by-step checker & CTA

Frequently asked questions section

Assurance company is protecting customer

Use of imagery and iconography

Brainstorming ideas in crazy 8's style:

How does it work? The backend flow

Backend flow blurred for confidentiality.

Starting with the essentials

Next, diving a little deeper

Visual inspiration and exploration

[show visual inspiration] then show [my visual designs]

Wayfinding

[Show where it lives in profile] Put it in a place that makes sense.

Identifying potential places to prompt security meter

[Show screenshots]

Digital security preference vs. customer preference

[Show DSO ranking vs Customer ranking graphics]

[Show security summary of findings]

Visual design

[Show card exploration]

[Show mockups]

[Show meter and number animating up]

***********************************

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:

Some utilized a checkbox.

Some utilized radio buttons.

Some didn't allow for remembering the device.

Some went beyond basic 2FA.

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?

Next, I wrote a user story to keep the user's point of view in mind, and to be able to refer to it if I ever lost sight of the goal

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.

'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 we 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?

We also wanted to test different copy we were seeing in industry benchmarks. Our 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

We 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 we placed it 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, we 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

Update style to current design system.

Show partial preview of text/phone number.

Add checkbox to remember devices.

Contextual messaging to explain why users would want to remember their device.

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:

• Maybe a passwordless login, like a one-time pin or 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.