Introducing T-Mobile IDs.
A misscoped UI refresh I turned into an end-to-end experience redesign, shipping the foundation that unblocked T-Mobile ID adoption across Retail, Business, and Digital, without a single backend change.
The work other teams were waiting on.
Multiple company-wide initiatives were blocked until the F&BV Digital Profile reflected T-Mobile’s new identity model. This redesign covered all T-Mobile accounts (excl. Business) and established the interaction model for how user roles would be managed under T-Mobile IDs going forward.
Cross-company unlock. Directly enabled T-Mobile ID adoption across Retail and Business, not just Digital. That shared foundation didn’t exist before this work.
Identity built on phone numbers, in a world moving past them.
T-Mobile’s F&BV Digital Profile experience was built around MSISDNs, phone numbers. Every user role, every permission, every touchpoint tied back to a phone number. As T-Mobile pushed toward a unified identity model built on T-Mobile IDs, that experience no longer reflected how the business needed identity to work.
The constraint: the backend could not be updated. No time, no budget. User roles were still tied to phone numbers and would stay that way. The experience had to feel fully T-Mobile ID-driven while the underlying system stayed exactly as it was.
End-to-end ownership, including ownership of figuring out what the project was.
I owned this project end-to-end: identifying the real scope, convincing stakeholders to act on it, defining the experience direction, collaborating with engineering daily, and seeing it through delivery under significant pressure.
This was not a handed-down brief with a clear path. The first and most important design decision was figuring out what the project actually needed to be.
The brief said UI refresh. The work said experience redesign.
When I joined, the project was scoped as a UI refresh. Another designer was slated for it but was swamped, so I stepped in. At kickoff it became clear the requested changes were not cosmetic, they touched how roles displayed, how permissions worked, and how the experience would behave for four distinct user types.
I brought it to stakeholders directly. I walked them through what the requested changes would break if treated as surface-level, and what we would need to do differently to actually solve the problem. The conversation shifted the project from a quick visual pass to a full experience redesign.
Shipping a refreshed UI on a broken foundation would have been faster and would have solved nothing.
That was not a small ask, more time, more scope, more coordination. Stakeholders agreed because the case was clear. Getting that alignment early was what made everything else possible.
The backend was the design problem.
I worked with the development team and its manager daily, in meetings and over Slack. Not handing over specs and waiting for feedback. Genuine back-and-forth where technical constraints directly shaped design decisions, and design decisions surfaced constraints engineering hadn’t fully articulated yet.
The hardest case: multiple lines, one ID
The backend assigns roles at the phone-number level. A user with three lines could have three different roles. We needed to present this at the ID level without forcing users to manage each number individually.
Showing each number separately created duplicate entries and confusion. Averaging roles made no sense from a permissions standpoint. The solution we landed on:
Surface the highest role held across any line attached to a T-Mobile ID. Simple for the user, achievable within the existing system, and defensible from a permissions standpoint.
One identity model. Four very different experiences.
The four user roles existed before this project. My job was to design a distinct experience for each and the flows for the two roles with the ability to change permissions, six flows total across web and mobile.
Primary Account Holder
Full account ownership; the only role that can change other users’ roles digitally. I designed the complete role management flow: selecting a user, choosing a new role, confirming the change, handling failed states, and recovering from errors.
Authorized User
Can view all user roles on the account but can’t make changes. A read-only experience that gave full visibility without surfacing controls they couldn’t use.
Standard User
Sees only their own role. A focused, simplified view that surfaced their information clearly without exposing the broader account structure.
Restricted User
Can’t view their role at all. Designed for that access level while handling the edge states gracefully, never letting the limitation read as a system error.
The choices that defined the experience.
Resolving multiple roles under one ID
Display the highest role across attached lines. Clean, consistent, buildable. Per-number display and role averaging were explored and ruled out.
Full management for Primary Account Holders
Selection, change, confirmation, and failure handling, designed as one connected flow rather than discrete screens.
Handling legacy in-store accounts
Accounts created on a not-yet-retired in-store system can’t change roles digitally. I designed a clear, non-alarming experience that pointed users to support without reading as a system failure.
Disabling account access
A feature for Primary Account Holders to disable a user’s web and app access entirely, built for situations where a device is lost, stolen, or compromised.
Language and labeling
Prior research showed “line permissions” tested poorly. I replaced that language across the experience and rewrote role names to be understandable without prior knowledge of how T-Mobile’s permissions work.
Research from prior projects, used efficiently.
The timeline didn’t support new research. I grounded the work in existing studies from related areas of the account experience, surveys, unmoderated usability tests, tree sorting, card sorting.
The patterns were consistent: users had difficulty finding role settings, the existing language around permissions was confusing and disliked, and role changes took too long when users needed to make them. That gave me a foundation to design from without a research timeline that didn’t exist.
Three things I’ll carry into every project after this.
Knowing when to push back. Reframing the scope before any design started was the most valuable thing I did.
Designing in partnership with engineering, not around them. The backend constraints weren’t obstacles to work around, they were the design problem itself.
Leading with clarity in ambiguity. No fully defined brief, tight timeline, hard technical limits, scope that had to be renegotiated before work could start. Keeping a team aligned in that environment was as much the job as the design itself.
If I continued this work
- Full backend alignment with the T-Mobile ID model as that infrastructure matures.
- Further simplification of role-change flows.
- Extending the identity experience to additional T-Mobile touchpoints.
My contract ended after this project; post-launch metrics weren’t available to me. What I know is that this redesign directly enabled T-Mobile’s push to adopt T-Mobile IDs across the company.