Michael Doss
UX Designer

F&BV Digital Profile

T-Mobile

Image alt tag

Project Summary

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. You do not need an MSISDN for a T-Mobile ID, users can use their email to sign up for one as well.

This project did not have funding for research for MVP. For the next phase of the project, we'll be partnering with the UX research team to do testing on the MVP designs and will use the results for phase 2. We used existing research for this project but it was mainly a UI project. At first, the team didn't think it would require much time and effort but as we dug into it, we realized that this is a complex, technically limited project and that we had to be very careful not to break the experience across all of T-Mobile which includes retail, care, and digital. Our decisions will influence how T-Mobile handles this experience across the board.

My Role

I was the lead designer for this project. I worked with numerous stakeholders from all parts of T-Mobile to ensure this feature was successfully launched across T-Mobile Digital, T-Mobile Customer Care, and T-Mobile Retail.

The existing experience

Line permissions exist under a blade called Line settings which is under the Profile settings section. Existing research had mixed results with the current experience. While some research showed that the experience was easy to use it also showed that users were slow doing so at times and that it wasn't easy to find for some users. Tree tests and card sorts were done to try to figure out the best organization for Profile.

There's also a feature within this page called no access. This feature gives the Primary account holder the ability to block someone's access to their account on T-Mobile's website and app. The biggest use case for this feature is fraud protection.

Line permissions changed to User roles

After many conversations, we settled on using User roles as the new title of the page. Past research showed that Line permissions wasn't the preferred term for the experience. 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.

The four roles

Primary Account Holder

  • 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.

Authorized User

  • 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.

Standard User

  • For this project, this user can see their own role.

Restricted User

  • For this project, this user cannot see their role.

F&BV Digital Profile

The three sections on the User roles page

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. A T-Mobile ID can have multiple lines connected to it while a line can only be connected to one T-Mobile ID.

A T-Mobile ID can also be incomplete which we call an incomplete profile. This happens when a user has not logged in yet after retail has created their T-Mobile ID for them or if they haven't connected an MSISDN to their T-Mobile ID. Users can create a T-Mobile ID with an email but will have restricted access until an MSISDN is connected. If the incomplete profile has an MSISDN attached to it, they can log in to complete their profile. If the Primary Account Holder changes their user role, that will also complete their profile. In the case where a T-Mobile ID is incomplete with just an email, the Primary Account Holder will have to call care or go to a retail store to edit that user's role since the role is technically tied to the MSISDN still (will explain further in the next section).

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. If a Primary Account Holder changes someone from an Authorized User to a Standard or Restricted User and they're listed here, they'll still have their Authorized User permissions. The Primary account holder will have to call care or go to a retail store to get this user removed to fully remove them as an authorized user. There is nothing we can do to stop this until this system is gone. This section of the page is raw text imported in by an API.

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. Discussions were had about moving this feature to another page but for now, it must remain on this page.

The facade

Since the user roles are still connected to a user's MSISDN we had to create an experience that acted like they were really connected to T-Mobile IDs. Since a T-Mobile ID can have multiple MSISDNS attached to it, that led us to a dilemma. We either had to list all of the combinations of that T-Mobile ID with each phone number separately or combine them. Due to the existing code, if a T-Mobile ID had 4 MSISDNS attached to it, all of them would get the highest user role that was attached to one of the four MSISDNs when they log in.

If we listed all the different phone numbers with a T-Mobile ID separately, it would have to update the rest to the highest role whenever a change happens or have it appear as they're different even though on the back end, they'll all have the same user role even if it shows they have a different one.

That is why we decided to combine them and list all the different MSISDNs connected to each T-Mobile ID and update them all to the same 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.

User roles page that has a T-Mobile ID with three MSISDNs connected to it

User roles page that has a T-Mobile ID with three MSISDNs connected to it

Flows

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

What's next?

Q1 of 2023, we'll be starting phase 2 of this project. We'll start by testing these new designs and use that information to make any necessary updates to the designs and we'll be introducing new features to this flow.