Verizon: Designing Early Upgrade from Zero
Designing one tracking experience that eliminates repeat support calls for Early Upgrade customers and reps
To honor my NDA, I’ve kept this case study free of confidential info. If you would like to know more, I'm happy to discuss more details! Just shoot me a message.
COMPANY & ROLE
Verizon, Senior Product Designer
TEAM
Digital Services - Support team
FOCUS
0 to 1, Product Design, Systems Thinking, Service Design, UX/UI
TIMELINE
Winter 2025 - Summer 2026 (Shipped in Summer 2026)
600K–1M
Early Upgrade transactions completed every year, the scale this tracking gap sat inside of
7.81%
of all customer service calls were tied to the return process, before this shipped
3
fulfillment paths designed from nothing
01. The Challenge
Verizon's Early Upgrade program lets a customer turn in their current phone to pay off the remaining device balance and move to a new one early. Verizon already had tracking for standard device returns and trade ins, but Early Upgrade is a fundamentally different transaction underneath.
We couldn't just extend an existing return tracker. Early Upgrade carries real loan payoff logic and strict backend cutoff windows, with a certain amount of timed warnings, chargebacks, & credit reversals. None of the existing patterns accounted for stakes like that, so customers getting vague status updates were ending up with unexpected $500+ chargebacks, then flooding support with disputes.
How might we build a resilient tracker for Early Upgrade devices that handles financial stakes and edge cases without breaking our existing architecture?
02. My Role
I was the Senior Product Designer on this from end to end, working alongside a Lead Product Designer who served as the primary Subject Matter Expert, with 7+ years of Verizon domain knowledge behind them.
Most of my actual effort went into conceptual exploration and unwinding backend logic: translating between product, legal, and supply chain, each working from a different definition of what this needed to do. The volume of back and forth was heavy enough that I built AI into my daily process. I used AI to synthesize dense documentation, ideate UX copy, untangle contradictory business rules, and iterate on decision trees, before designs went into Figma.
03. Solutions
Build a new tracker, or bend the one people already know?
Before any screens, I led the exploration that defined the system's foundation. We argued through foundational questions: does this need an entirely new return tracker? What actually counts as Device Assessed when a loan payoff is still pending?
I decided to build on Verizon's existing My Orders patterns instead of starting over, keeping the experience familiar while reworking the architecture underneath to handle Early Upgrade's constraints.
That decision had to hold up across three fulfillment paths a customer could choose from: return it to a store, ship it back with a prepaid label, or drop it off at a UPS Store using a QR code, no packaging or printing required. Customers could also switch paths mid flow, so the system had to treat the initial choice as changeable, not fixed.
Same milestones, same states underneath, just three entry points instead of one. That's what made loan payoff logic something engineers could build once instead of three times, and it's the happy path this whole section sits on top of, before the edge cases below.
Edge Cases
Four broken states outside the happy path, each one a separate design decision about how much recourse a customer gets when something goes wrong.
Empty box. Treated as recoverable by default. Tracker resets to Initiated, issues a new QR code with a deadline. Miss it and the balance gets charged, but the design still holds a 15 day window afterward to reverse that charge. The principle: a missing device isn't assumed to be the customer's fault until the window closes twice.
Lost or stolen in transit. Treated as a system failure, not a customer failure. Package stalls past its expected window, the payment plan closes out automatically. No chargeback, no action required. This is the only state where the default assumption favors the customer outright.
Mismatch return. Treated as an open loop, not a dead end. Wrong device arrives, the tracker halts and flags it, but the customer can still change their return method and retry. The system doesn't punish the mistake, it routes around it.
Damaged device. Treated as final. Balance charged back, device shipped back, no grace period, no path to contest it. This is the one state that breaks the pattern the other three establish, and it was still unresolved when the team reorganized in August 2026 and the work moved on without me.
06. What I would change
By Summer 2026, all three core fulfillment paths shipped to production. We also established an aligned, customer-centric framework across three major edge cases: Empty Box, Lost or Stolen, and Mismatch Return.
The major remaining gap is Damaged Device. Unlike the other edge cases, it currently triggers an immediate chargeback with no reversal window or avenue to contest. This is a clear departure from the rest of the experience. A team reorg shifted my focus before I could close this gap, but defining a consistent, fair resolution model for damaged devices remains the highest-leverage opportunity to complete the system.