Case Study / 01 — Systems & Research

Device Return
Journey

Six return programs, seven backend systems, one frontline agent trying to answer a customer's question. I owned UX for Device Protection and Warranty returns inside AT&T's Customer Connect platform — reframed the problem around a single question the interface had never actually answered, and initiated the research that proved the reframe was right.

The Problem

Frontline experts had no single, journey-aware view of a wireless return — and the interface answered a question customers weren't actually asking.

An expert helping a customer with a returned phone had to leave the Equipment tab, hunt across Order and Returns views, and sometimes swivel to other systems entirely just to piece together what had happened. Buyer's Remorse, Trade-In, Next Up, Device Protection, and Warranty returns each carry their own rules, statuses, and completion definitions — but the interface treated them identically. The same generic fields appeared whether or not they applied, and backend values like cash-carry or DF/INBOUND went untranslated, forcing experts to interpret engineering language mid-call.

My scope was Device Protection and Warranty — two of the highest-friction journeys, since a claim can be operationally settled before a generic tracker would ever say "Received."

The question underneath the problem

Every symptom I heard from experts — overwhelming screens, unexplained fields, confusion about revisions — traced back to one missing answer: does the customer still owe AT&T a device, or not? I reframed the redesign around three questions the interface needed to answer, in order, before showing anything else:

My Role & Approach

I owned the return experience for Device Protection and Warranty end to end, with day-to-day autonomy and light oversight from the platform's design lead. Two decisions shaped how I worked, and both are ones I'd defend to a hiring panel.

I refused to design from assumptions

An in-store handoff and a mailed exchange look identical to a customer, but they're structurally different orders with different obligations. Rather than guess what experts needed in the moment, I made the case to product and business stakeholders that we needed to validate the proposed design with the people who'd use it, before development locked it in.

I initiated the research, rather than waiting for it

Research wasn't a standing part of this workstream. I brought the UX research team in myself, scoped the study with researcher Angie DeFord, and used the findings to settle open design debates with data instead of opinion.

Research I Initiated

Device Protection & Warranty Order Research — with UX Researcher Angie DeFord

I scoped a focus-group study to pressure-test the proposed Order and Returns tabs across three realistic scenarios: an initial insurance claim, a first revision (device not received, new order created), and a second revision (a repeat non-receipt). Nine frontline experts participated, spanning Mobility Loyalty, Sales & Service, CX Labs, and the Centralized Support Desk.

What we heard

• Experts could identify an open insurance claim quickly once labels like "Insurance" and "Device Protection" were visible, and the CTN helped them confirm which line was affected.
• Once a second or third revision existed, experts could tell something had changed, but not why — several said they'd fall back to reading call notes to reconstruct the story, exactly the swivel behavior the redesign was meant to remove.
• The information-dense return screen was appreciated for completeness but called "overwhelming" by more than one participant — density without hierarchy was making the page harder to scan, not easier.
• Some fields had no clear owner in the expert's mental model. Nobody could explain where a "Refund Amount" figure came from, and "Claim ID" was recognized as an Asurion-side identifier irrelevant to their workflow.
• Certain details were genuinely load-bearing: the RMA number was named directly as one of the most useful fields on the page, particularly for lost-equipment cases.

That line reframed the direction: the fix wasn't more explanatory text, it was restructuring the page around the scenario the expert was actually in — grouping fields by claim stage instead of by data source, and cutting fields no one could explain.

The Design Decision That Mattered Most

Organize the interface around customer responsibility, not backend structure.

The source systems modeled an in-store handoff, a shipped exchange, an RMA, and internal reverse-logistics movement as different technical objects. My job was to collapse that into the one question an expert actually needed answered: is the customer still on the hook for this device?

A store might accept a device from a customer and later ship it internally to a warehouse. From the customer's side, their obligation ended the moment they handed it over — but a naive design would keep showing return-tracking detail for that internal movement, implying the customer still owed something they didn't. I deliberately separated customer return accountability from internal inventory movement, and made sure internal logistics events were labeled as internal — never surfaced in a way that could make an expert tell a customer they still owed a device they'd already returned.

The tradeoff I had to resolve

Device Protection and Warranty could be considered operationally complete the moment a carrier scanned pickup — but a generic tracker still implied "Received" was required to close the loop. Meanwhile, shipment events like Drop Off and Returned were genuinely valuable evidence when a customer later disputed sending a device back.

Where I chose to hold the line

Not every idea made it in. When the team considered surfacing raw Order Type and Order Action values directly in Order History, I pushed to pause it — the underlying values included ambiguous, unmapped strings like Modify.change… that wouldn't mean anything to an expert without translation first. More data isn't automatically more useful information; I'd rather ship less and have every field on the screen mean something than ship more and make experts guess.

The Solution

Translate the backend into plain language

Fulfillment values that meant nothing to an expert — cash-carry, CC, ship, DF — became two plain labels experts could act on immediately. I worked with content designer Laura Landgren to get this language right, since the words on the screen carried as much weight as the layout around them.

Fix the navigation, not just the page

I added return and exchange visibility directly to the Equipment tab so an expert could jump straight into the relevant Returns view instead of hunting for it — the most-cited pain point going into the study. Related order revisions were grouped together so an expert didn't have to manually reconstruct which orders belonged to the same claim.

Make validation part of the process, not an afterthought

Coming out of this project, I proposed making frontline validation a formal checkpoint rather than an optional step designers reach for when there's time:

Moving expert validation earlier means design changes get caught while they're still cheap — before engineering has built against an assumption that turns out to be wrong.

Grounded in Existing Research, Too

Alongside the study I initiated, I drew on an existing AT&T employee persona framework — built by the UX Research team from 75+ interviews, 60 survey responses, and dozens of hours of retail and call-center observation — to understand how experts operate across their broader day. That research consistently surfaced a pattern I designed directly against: employees work across too many disconnected systems, and every extra swivel erodes both efficiency and their confidence on a live call. I didn't conduct that research, but analyzing it against my own findings gave me a second, independent signal that consolidation and plain-language status were the right problems to solve.

Collaboration

This shipped through sustained coordination across the Customer Connect platform team, the OrderGraph backend team responsible for the underlying data model, and the research and content design partners above. Because the return logic touched real customer-facing consequences — refunds, non-return fees, RMA deadlines — I worked closely with business stakeholders to keep the interface honest about status, rather than optimizing for a cleaner-looking screen at the cost of accuracy.

Impact

• Experts described the new flow as easier to navigate and expected it to meaningfully cut click time, especially for new hires still building system fluency.
• Several asked to be included in the eventual pilot — a strong, if informal, vote of confidence from the people closest to the problem.
• Conditional field display removed the specific confusion the research surfaced: RMA information no longer appears on returns where no RMA exists, and unexplained fields like the mystery "Refund Amount" were cut.

Two internal dollar-benefit estimates existed for the broader returns initiative this work supported ($20M and $6M annually, tied to different scoping assumptions); as of my last review, neither had been finance-vetted, so I'm not quoting either as a personal result here.

Reflection

The instinct to bring in research wasn't process for its own sake — it was that I didn't trust my own assumptions about what "overwhelming" meant to someone who reads this screen fifty times a day. And the instinct to separate customer accountability from backend structure wasn't a stylistic choice — it was the one reframe that made every other decision on this project obvious once I'd made it. That's the kind of judgment I want a team to be able to hand me a messy, high-stakes system and trust me to find.