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 and Digital, without a single backend change.
The work other teams were waiting on.
Cross-company unlock. This redesign of the F&BV Digital Profile established T-Mobile’s new identity model, defining how user roles are managed under T-Mobile IDs across all accounts (excl. Business). Multiple company-wide initiatives were blocked on it, and it extended T-Mobile ID adoption into Retail, not just Digital. That shared foundation didn’t exist before.
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.
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.
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.
The backend was the design problem.
The real obstacle was technical. T-Mobile was shifting its identity model from MSISDNs (phone numbers) to T-Mobile IDs, but the backend behind this experience couldn’t be migrated to match, with no time or budget to change it. Roles and permissions would keep running on phone numbers underneath, exactly as before. My job was to make the experience feel fully T-Mobile ID-driven to users, even though nothing beneath the surface had actually changed.
That made engineering my closest partner. I worked with the dev team and its manager daily, in meetings and over Slack, not handing over specs and waiting for feedback, but in genuine back-and-forth where technical constraints directly shaped design decisions, and design decisions surfaced constraints engineering hadn’t fully articulated yet.
Every hard call on this project traced back to that gap between the frozen backend and the experience we wanted. The sharpest one is broken down in the key decisions below.
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, plus the permission-change flows, which only the Primary Account Holder can perform, across web, mobile, and app.
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
The backend assigned roles per phone number, so one person with three lines could hold three different roles. The experience had to present a single, coherent role at the T-Mobile ID level, without making users manage each number, and without any backend change.
Highest-role was the only option that stayed honest to how permissions actually work while hiding complexity the user never needed to see, and it shipped without touching the backend.
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.
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.
Get in touch
Let’s build something good.
Always happy to talk design, collaboration, or an interesting problem. Email is the fastest way to reach me.