Skip to the exhibit
Digital Workshop
01Arrival
Room 01: Arrival

DW-003

Zappos at Work

A coupon program had become too difficult to operate. Every exception, manual step, and support request reduced confidence in the system. The redesign wasn’t simply about modernizing the interface. It was about making the program easier to understand, easier to manage, and easier to trust.

B2B Commerce
Zappos
Platform
Web
Role
Lead Designer
FIG. 01The redesigned admin dashboardVouchers issued, funds remaining, redemption rate, budget usage — the program’s health, surfaced on login.
02Observation
Room 02: Observation

The existing program worked, but operating it required experience that lived outside the interface. Support requests, manual intervention, and undocumented processes had gradually become part of everyday operation.

FIG. 02The Legacy Coupon SystemThe original experience relied on manual processes and operational knowledge that existed outside the interface itself.

The challenge wasn’t generating coupons. The challenge was operating the entire program. Every manual exception reduced confidence because the system depended on knowledge that wasn’t visible inside the product.

  1. A large percentage of support requests came from situations the interface never explained.

  2. Failed uploads required manual support to resolve.

  3. Operational processes lived outside the application instead of inside it.

  4. Exceptions became normal work rather than rare events.

03Evidence
Room 03: Evidence

How might the product make the operational model visible so users could manage the program confidently without depending on tribal knowledge?

Before redesigning the interface, I mapped how the program actually operated. The diagrams, sketches, and workflows revealed that the real complexity existed behind the screens rather than inside them.

FIG. 03New system diagram — self-service experienceArchitecture diagrams exposed how operational responsibilities were distributed across the entire program rather than inside a single interface.
FIG. 04New system diagram — reportingEarly workflow mapping identified where operational decisions left the product and entered manual processes.
FIG. 05New system diagram — quick launchThe core buy-and-distribute flow: pre-selected assortment, promotion codes, redemption.
FIG. 06Sketch explorationsInitial sketches focused on exposing operational status instead of simply reorganizing interface components.
FIG. 08Sign inOperational reporting became part of the product instead of existing as a separate support activity.
FIG. 09Promotion detailsThe guided account-creation step, once an employee’s assortment and code are set.
FIG. 10CheckoutPayment and order summary — where a voucher order is completed.
04Design Decisions
Room 04: Design Decisions

The redesign treated operations as part of the product rather than something that happened behind it. Making the program easier to operate made it easier to trust. The redesign simplified more than the interface. It simplified how the program was managed. Operational decisions became easier to understand because the product finally reflected how the service actually worked.

  1. Surface program health metrics immediately on login.

    Employers wanted a dashboard, not a spreadsheet. The first thing an employer should see is whether their program is working, not a menu of places to go look for it.

  2. Provide redemption status at both individual and aggregate levels.

    The original system offered no clean way to see who had redeemed a voucher, who hadn’t, or how much budget remained. Both views were needed — the aggregate for a program’s overall health, the individual for following up on a specific employee.

  3. Keep the employer dashboard focused on actionable metrics.

    Clarity, not more data. A dashboard that tries to show everything ends up showing nothing clearly.

  4. Avoid overcomplicating the admin portal with unnecessary analytics.

    The same restraint, applied deliberately rather than left to scope creep.

  5. Reduce friction in voucher setup with guided steps.

    High-volume uploads were where the original system broke. Guided setup replaces a single high-stakes file with a sequence that can’t fail all at once.

  6. Keep employee shopping consistent with the Zappos experience.

    An employee redeeming a voucher shouldn’t feel like they’ve left the store they already trust.

  7. Maintain consistency with Zappos design patterns to reduce relearning.

    The same reasoning as the decision above, extended to the interface itself rather than just the shopping experience.

05Interactive Prototype
Room 05: Interactive Prototype

The reward. By this point, a visitor has seen why the original system failed and how the redesign was built — this is where they’d feel the result firsthand.

FIG. 07The employee shopping flowThe redesigned employee experience removed unnecessary operational complexity from the customer’s point of view.

The strongest candidate for a reconstruction is the employee self-service shopping flow — Sign In, Pre-selected Options, Promotion Details, Checkout — the only sequence in the evidence with no confidentiality question attached to any of its screens.

Not yet built. No prototype route exists for this exhibit.

06Reflection
Room 06: Reflection

Looking back, the redesign wasn’t really about coupons. It was about operational clarity. When people understand how a system behaves, confidence follows naturally. Trust isn’t created by visual polish. It’s created when the product consistently explains itself.

07Continue the Collection
Room 07: Continue the Collection

Every mature product eventually accumulates complexity. Zappos reminded me that the right response isn’t hiding that complexity behind another interface. It’s deciding which parts belong inside the product and which parts should disappear completely. Operational clarity builds trust because people can finally understand the system they’re depending on.

Back to the collection