2022, Web, Mobile, App
Creating a seamless experience
F&BV Digital Profile
UX Designer
My Role
Figma, FigJam, Asana
Tools
Fall 2022
Timeline
1 UX Designer
1 Product Owner
1 Project Manager
1 Copywriter
1 Product Owner
1 Project Manager
1 Copywriter
Team
Project
An overivew
F&BV Digital Profile (Fraud & Blind Verification) goal was to update the existing line permissions page and experience.
T-Mobile wants to create a single ID for all its products and services. We wanted to change the experience from using MSISDNS (which is your phone number, also referred to as lines) to using T-Mobile IDs.
T-Mobile ID was first used for digital products but will be expanded to cover all of T-Mobile.
T-Mobile wants to create a single ID for all its products and services. We wanted to change the experience from using MSISDNS (which is your phone number, also referred to as lines) to using T-Mobile IDs.
T-Mobile ID was first used for digital products but will be expanded to cover all of T-Mobile.
The Problem
What we're solving
Update T-Mobile's experience from using MSISDNs to T-Mobile IDs for User Roles (formerly known as Line Permissions). These are the 4 different Roles that every T-Mobile customer has. The user roles are still connected to a user's MSISDN so we had to create an experience that acted like they were connected to T-Mobile IDs.
A T-Mobile ID can have multiple MSISDNS attached to it, which made designing the experience more complex. We decided to list all the different MSISDNs connected to each T-Mobile ID and update them all to the highest user role whenever a change is made. Therefore, it acts like the T-Mobile ID is what decides the user role even though technically the user roles are still connected to MSISDNs.
To help explain this visually. Let's say John Doe has a T-Mobile ID that has three MSISDNs connected to it.
John Doe's T-Mobile ID -
(555) 555 5555 - Authorized User
(521) 565 7896 - Standard User
(435) 132 6842 -Restricted User
In this scenario even though those three MSISDNs have 3 different user roles, they'll all have the highest user role attached to the T-Mobile ID, which is Authorized User in this scenario when they log in. It gives the facade that the user role is connected to the T-Mobile ID.
A T-Mobile ID can have multiple MSISDNS attached to it, which made designing the experience more complex. We decided to list all the different MSISDNs connected to each T-Mobile ID and update them all to the highest user role whenever a change is made. Therefore, it acts like the T-Mobile ID is what decides the user role even though technically the user roles are still connected to MSISDNs.
To help explain this visually. Let's say John Doe has a T-Mobile ID that has three MSISDNs connected to it.
John Doe's T-Mobile ID -
(555) 555 5555 - Authorized User
(521) 565 7896 - Standard User
(435) 132 6842 -Restricted User
In this scenario even though those three MSISDNs have 3 different user roles, they'll all have the highest user role attached to the T-Mobile ID, which is Authorized User in this scenario when they log in. It gives the facade that the user role is connected to the T-Mobile ID.
Target Audience
Our target
The Primary Account Holder (PAH) is the owner of the account and has access to everything.
Primary Account Holder
To either show them their User Role or everyone's User Role, depending on their Role. None of them can edit their User Role or someone else's User Role.
Non Primary Account Holder
Design Process
MVP Launch
10
QA Testing
9
UX Handoff
8
Check With Devs
7
Make Updates
6
Usability Feedback/Review
5
Check With Devs
4
UX Mockups
3
UX Research
2
Project Kickoff
1
Resarch
An overivew
We relied on existing research and data. Since it's confidential information, I cannot share the details but can provide a general overview of the experience.
The team used surveys, unmoderated user testing, tree sorts, and card sorts.
The team used surveys, unmoderated user testing, tree sorts, and card sorts.
Hard to find for some users.
Users did not like "Line Permissions".
Paint point
User slow at changing their line permission.
Paint point
Paint point
User Roles
Changing the name
After many conversations, we settled on using User Roles as the new title of the page. This was not only updated on this page but across all of T-Mobile. As I said above, it's now its own blade under Profile, outside of Line Settings.
We went with Roles and not Permissions because each role has its own unique permissions associated with it. Permissions can also change over time while the roles will stay the same.
We went with Roles and not Permissions because each role has its own unique permissions associated with it. Permissions can also change over time while the roles will stay the same.
The Four Roles
Explanation
Restricted User
This user cannot see their role.
Standard User
Authorized User
This user can see their own role.
Primary Account Holder
Has a lot of the same permissions as the primary account holder. For this project, they can view every user's role but cannot change any.
This is the owner of the account and cannot be given to someone else without the help of care or retail. This is the only person who can change a user's role digitally.
On The Page
What's included
Each user role will have a different experience on this page.
T-Mobile ID User Roles
This is the T-Mobile ID section that is editable by the Primary Account holder. Retail is now creating a T-Mobile ID for new users but users can also sign up for a T-Mobile ID online.
Legacy authorized users
This is the section for the legacy system used by retail. This system gives users the Authorized User role that I listed above but is not a part of the digital system. The Primary account holder will have to call care or go to a retail store to get this user removed from this section.
Disable a user's access to web and app
This is the no access feature that I described above. If a user is given no access, they'll retain their user role but will not be able to login into T-Mobile's website or app.
Flows
The experience
I created four flows from the Primary Account Holder view since they are the only person allowed to make any changes on this page.
1st flow - Primary Account Holder changing a user from Authorized User to Standard User
2nd flow - Primary Account Holder changing a user from Standard User to Authorized User
3rd flow - Primary Account Holder cannot change this user's role due to it being email only
4th flow - Primary Account Holder disabling a user's access to web and app
1st flow - Primary Account Holder changing a user from Authorized User to Standard User
2nd flow - Primary Account Holder changing a user from Standard User to Authorized User
3rd flow - Primary Account Holder cannot change this user's role due to it being email only
4th flow - Primary Account Holder disabling a user's access to web and app
Final Designs
High fidelity mockups
Authorized - Profile Page
Standard User - User Role Page
Primary Account Holder - User Roles Page
Primary Account Holder - Profile Page
Authorized - Profile Page
Authorized User - User Role Page
Primary Account Holder - User Role Page
Standard User - User Role Page
Restricted User - User Role Page
Primary Account Holder - User Roles Page, Incomplete Profile
Make User Authorized User Confirmation Page
Primary Account Holder - User Roles Page, Disable User's Access
Primary Accoun Holder - User Roles Page, Change User's Role