Case Study 04 · T-Mobile · Consumer UX · 12-Month Redesign
T-Mobile Magenta Drive.
I joined mid-project as the sole designer — no UX research process, no design history to inherit. Over 12 months I rebuilt the Magenta Drive connected car portal from the ground up, using Jobs To Be Done and Constraint Mapping to ensure every design decision was grounded in what drivers actually needed to accomplish.
↑
Conversion Rate Increased
Primary metric met on schedule — self-service became genuinely self-sufficient, support call volume fell
12mo
Full Redesign Lifecycle
Research through launch as sole designer — zero context lost between phases
1st
UX Research Practice Built
First UX researcher at the company — templates and process outlasted the project
Executive Summary
I led the end-to-end redesign of T-Mobile's Magenta Drive connected car portal over 12 months as the sole designer. The project started with a familiar set of symptoms — rising support calls, checkout abandonment, low conversion. Six weeks in, I realized I had been solving the wrong problem.
Analytics showed where users left. Moderated research sessions revealed why: internal terminology meant nothing to real customers. That single insight redirected the entire project and is the clearest demonstration of why JTBD — asking what the user is actually trying to accomplish, not just where they click — was the right framework here.
My Role
Sole designer, first UX researcher at the company. Every phase owned — brand definition, research practice, information architecture, wireframes, visual design, and handoff.
I built the UX research practice from nothing
I ran brand definition and audience persona work
I applied JTBD to reframe every design problem
I mapped constraints before designing solutions
I ran moderated usability testing throughout
I delivered handoff documentation and KPI monitoring plan
Sole designer. 12 months. Research culture that outlasted the project.
Research Framework
JTBD + Constraint Mapping. Why these frameworks here.
Most UX frameworks start with the user. JTBD starts with the job — the outcome the user is trying to achieve, independent of any specific product or interface. For a connected car portal, this distinction is critical: the user isn't trying to "navigate the dashboard." They're trying to manage their car's connectivity plan with as little friction as possible, often while under time pressure. That reframe changes every design decision.
Constraint Mapping complements JTBD by forcing an explicit inventory of everything that limits what's possible. In automotive-adjacent UX, constraints aren't edge cases — they're the primary design material. Physical context, cognitive load, legal requirements, and technical limitations all shape what a solution can look like before a single screen is designed.
Framework 1
Jobs To Be Done — What is the user actually trying to accomplish?
JTBD reframes design problems around outcomes, not features. Instead of asking "how do users navigate this page?", it asks "what job is the user hiring this product to do?" — and what functional, emotional, and social dimensions does that job have. For Magenta Drive, the primary job was: manage connected car plans without needing to call support.
Framework 2
Constraint Mapping — What limits what's possible before design begins?
Constraint Mapping identifies physical, cognitive, regulatory, and technical constraints that shape the solution space before ideation. On a self-service portal used by customers managing car plans under time pressure, constraints aren't edge cases — they're the design brief. Mapping them first prevented building solutions that looked right but couldn't be used.
The brief described a navigation problem, a brand problem, and a conversion problem. JTBD reframed all three. Users weren't failing to navigate — they were failing to accomplish jobs. And the jobs they were actually trying to do were different from the tasks the platform was designed around.
Six weeks into the project I was making design changes based on drop-off analytics. Metrics barely moved. I ran the first moderated session — sat with real users, watched them attempt real tasks. What I heard changed everything: "I don't understand what this means." Internal T-Mobile terminology had been copied directly into customer-facing UI. Users weren't confused by the layout. They were confused by the language.
"I had analytics showing where users left. I made layout changes. Metrics barely moved. It took sitting with a real customer — watching them hesitate, hearing them say I don't know what this means — to find the actual problem. That's what JTBD does. It forces you past the symptom."
— Mahesh · Mid-project reflection · T-Mobile Magenta Drive
J1
Primary job: Manage my car's connectivity plan without calling support
This is the functional job — the outcome customers hired Magenta Drive to achieve. Every piece of internal terminology, every navigation layer, every modal that required explanation was failing this job. Design response: rewrote all customer-facing copy in plain language. Eliminated every instance of internal product nomenclature from the UI.
J2
Emotional job: Feel confident I've done this correctly without expert help
Customers managing connectivity plans for cars aren't technical users. The emotional job is confidence — finishing a task and knowing it worked. Ambiguous states, unclear confirmation, and jargon-heavy error messages all undermined this job. Design response: explicit confirmation states, plain-language error messages, progress indicators for every multi-step flow.
J3
Social job: Look capable managing household technology
For many users, managing connected car plans is visible within their household — they're the person who handles the tech. A confusing experience doesn't just frustrate them; it erodes their sense of competence. Design response: brand cohesion work that made Magenta Drive feel as premium and trustworthy as T-Mobile's core product experience.
Brand Definition & Strategy · Aligned to JTBD emotional and social jobs
User Persona · Jobs mapped to user type
Before opening Figma, I mapped every constraint that would limit what the redesign could look like. Constraint Mapping is not about finding reasons not to design something — it's about preventing investment in solutions that look right but can't work. In 12 months as a sole designer, every cycle of rework is a week lost. Mapping constraints first eliminates the most expensive category of rework.
Cognitive load
Users managing car plans are often time-pressured — between meetings, in a parking lot, on mobile. Complex UI requiring sustained attention fails immediately in this context.
→ Maximum 3 decisions per screen. Progressive disclosure for advanced options. No dead ends in any flow.
Language gap
Internal T-Mobile product terminology (plan codes, feature names, billing nomenclature) was directly copied into customer-facing UI. Customers had no context for it.
→ Complete copy audit. Every label, tooltip, error message, and CTA rewritten in customer language before visual design began.
Trust gap
Customers had just left the T-Mobile flagship experience. Magenta Drive felt like a different company — eroding trust before the first interaction.
→ Brand alignment work as a prerequisite to UX work. Visual consistency with T-Mobile's core design language established before IA was restructured.
Checkout complexity
Four distinct failure modes: gifting flows, multi-location shipping, address validation, and international purchasing. Each had different edge cases and different user expectations.
→ Each checkout variant designed as a separate flow, not a single flow with exceptions. Shared components, distinct paths.
Warehouse & CS ops
Every design change had potential downstream impact on warehouse operations and customer service workflows — teams not represented in design reviews.
→ Added warehouse ops and CS impact to the design review checklist. Every screen signed off by operations lead before moving to development.
Solo designer timeline
12 months, sole designer. Every rework cycle costs a week. Constraints not surfaced before design begin multiply into timeline risk.
→ Skeleton wireframes shared with engineering before investment in high-fidelity work. Three major flow changes caught at wireframe stage — none reached development.
Design Process
12 months. Four clear phases built on the framework.
With jobs defined and constraints mapped, the design process had a clear foundation. Each phase had a specific output that fed the next — no phase was speculative.
01
Months 1–2 · Context before design
Reviewed every existing document. Sat with every team member. Mapped the current experience end to end. Built brand attributes and target personas by consolidating existing customer data rather than running redundant research sessions. Key call: build on existing research first. This built cross-team trust and saved 3 weeks.
02
Months 3–4 · Research practice built and first JTBD sessions run
First UX researcher at the company. Made the case for moderated research, documented it, ran sessions with team observers. The language problem — internal terminology blocking real customers — was found in month 4's moderated sessions. Analytics showed where users left. Moderated research showed why. Both were necessary. Neither was sufficient alone.
03
Months 5–10 · Iterative design with constraint-aware review
Eight months of: design against the job, check against constraints, test with users, iterate. A six-point design review checklist applied to every screen before moving forward: aligned with research, follows usability guidelines, impacts ops or CS, fits project goals, buildable for MVP, uses customer language. The customer language item was added mid-process — the direct output of the month 4 moderated sessions.
04
Months 11–12 · Ship well and build what outlasts you
Final usability testing. Complete site map for engineering. Post-launch KPI monitoring plan. Handoff documentation treated with the same rigor as the design. The research and design workflow documented and handed off as a company template. The real deliverable: not just a launched product — a repeatable process the team could run without me.
User Story Mapping · Jobs mapped to flows
Trip Planning Flow · Primary job translated to UX
Wireframes · Constraint-checked before high-fidelity
High-Fidelity Screens · Language rewritten, brand aligned
Checkout Flow · Separate paths per variant, shared components
Final Implementation · Shipped ✓
Before & After
What JTBD and Constraint Mapping actually changed.
The old reality
Internal terminology used as customer-facing copy. No brand cohesion with T-Mobile core. Four distinct checkout failure modes with no clear paths. Rising support call volume as direct UX failure signal. No moderated research — decisions made on analytics alone. No documented UX process.
What changed
All customer-facing copy in plain language. Brand cohesion with T-Mobile flagship experience. Separate checkout flows per variant — no edge-case handling. Conversion rate up, support call volume down. Moderated research practice established and documented. Research and design templates handed off as company standard.
Impact
Goals met. Process established.
↑
Conversion Rate Increased
Primary metric met on schedule. JTBD-grounded copy rewrite and constraint-aware checkout flows drove the improvement — not visual changes.
12mo
Full Redesign Lifecycle
Research through launch as sole designer. Brand definition, persona work, IA, wireframes, visual design, handoff — zero context lost between phases.
1st
UX Research Culture Built
First researcher at the company. Research and design workflow documented as the company standard — a systemic impact that outlasted the project itself.
Reflection
What JTBD proved. What Constraint Mapping prevented.
JTBD proved its value in month 4. Six weeks of analytics-driven design barely moved the metrics. One moderated session found the actual problem — internal terminology used as customer-facing copy. That's what JTBD does: it forces you past the symptom. The job the user is trying to accomplish doesn't care about your navigation structure. It cares about whether the language makes sense.
Constraint Mapping prevented the most expensive category of rework. Three major flow changes were caught at the wireframe stage — before any investment in high-fidelity design. The checkout variant problem was caught before a unified flow was designed and had to be unraveled. On a 12-month solo engagement, preventing one full iteration cycle saves weeks. That's a framework ROI that's easy to quantify.
What I'd do differently: I would run the first moderated JTBD session in week 2, not month 4. The language problem was discoverable from day one. Starting with analytics gave me a false sense of understanding the problem. The framework should front-load the discovery — not validate assumptions after they've already shaped early decisions.
Joining mid-flight with no UX process, as the only designer, on a 12-month timeline — that is where you learn what frameworks are actually for. JTBD found the real problem. Constraint Mapping prevented solving it wrong. The product shipped. The process stuck. That's the win.
— Mahesh Guntivenkata · T-Mobile Magenta Drive