Reducing Guest
Return Friction

Background

Zappos guests who checked out without an account had exactly one way back into their order to start a return: the confirmation email. Shopbop, on the same design system I own, already had three. Leadership commissioned a UX audit of the guest return experience after Voice of Customer data surfaced a clear pattern: guests creating accounts specifically to return an order, then finding the account couldn't see the order they'd just placed.

I led the audit and the redesign solo: research, information architecture, copy, interaction design, spec, and handoff.

Impact

The redesign touches 8 surfaces: the confirmation email, the shipping email, site search, the return flow itself, FAQ, Contact Us, and the shipping and returns policy page. It also closes a Sev-2 security gap along the way. It's approved as P0 and currently in development. Outcome metrics aren't in yet, so the numbers below describe scope and diagnosis, not results.

Research

I analyzed 18 unsolicited customer service contacts about returns using open coding, with no hypothesis going in.

Key finding: a third of the sample created an account anyway

Every contact in the sample had already reached customer service, so this shows how the failure happens rather than how often. A third of the customers didn't just fail to find the return path. They inferred that an account was the way to get it, created one, and hit a second wall, because guest orders don't retroactively appear in a new account's history.

"I saw sign up for an account as the way to do that today. So I created an account with my email. Zappos doesn't have my email account connected to my order. Can you help me initiate a return?"

Why the failure didn't show up in account-creation metrics

I had no account-creation metric for this; this is a reasoning point about how the failure hides, not a number I measured. Tracked only by account creation, this behavior reads as conversion. It isn't.

The confirmation email was the only door. Miss it, and there was no other way in, and the account a guest created next did not surface the order. Both halves had to be fixed.

Diagnosis

The site wasn't silent about returns — it was actively pointing guests toward an account.

The app doesn't allow guest checkout, so app-only customers can't hit this problem, which scoped the fix to web.

Competitive precedent: Shopbop

Before designing anything I checked Shopbop, same parent company and a brand I also own the design system for. It already has a "Find Guest Order" link under Help, a page that takes email plus order number, and a third entry point from the return policy: three ways in, one destination. Zappos had the destination and none of the ways in. That precedent scoped the Zappos fix to parity with Shopbop: guests only, one destination page.

Design solutions

Layout: equal-weight entry points

I tested four layout options for the lookup page. Three gave the guest path a button and the account path an inline text link, giving the account path more visual weight, the same imbalance this project existed to fix.

The final layout is the only one where both paths get a button — two doors, equal weight.

• 2 options, side by side: each with its own action button, evenly spaced. The layout carries the parity.
• Links moved to the bottom: so they stop competing with the two primary paths.
• 2 return methods outlined: visuals and short lines, because customers compare methods at a glance.
• Wording made actionable: the only copy change on this list.
• Guest inputs side by side: email and order number in one row, saving vertical space.
• Submit button shortened: a full-width button reads as the page's only option.

Shipped to dev: both paths get their own heading, copy, and button

Failure state

Email plus order number lands on the same order page the email link reaches: status, tracking, cancel, return. Most of the design work is in the failure case, since that's what the verbatims describe.

"I started an account but it doesn't recognize the number as belonging to me."

The failed-lookup state names the reason and offers Contact Us instead of a dead end

No new page was built; an existing one was made reachable. Still open: a guest with no order number at all, which the requirements doc raises and doesn't yet have an answer for.

Information architecture: renaming for task, not content

The requirements doc named 6 surfaces; the design covers 8, and renames 3 of them. Each page had been named for what it contained; each is now named for what the customer is trying to do.

Security

The redesign surfaced a Sev-2: the old email return link signed a guest in behind the scenes from an email and an order number alone. What's handed to dev: a one-time code sent to the email on file, checked before the order opens.

A one-time code gates the order, replacing the old auto-login link

The open tradeoff: every additional check reduces risk and adds a step for a customer who's already frustrated enough to have contacted support. Security and legal own that call; my job is keeping the friction cost visible when they make it.

Stakeholder alignment

Three proposals I made were corrected during review, and all three corrections are reflected in the final design.

Collaborators

Current status

Validation