Helping suppliers restock Wayfair through one unified order tool

Overview

Context & Problem

Four separate teams built four redundant tools for inventory replenishment. Suppliers struggled with inconsistent UI rules, missing regional features, and fragmented order tracking, while Wayfair burned engineering resources maintaining four codebases for one workflow.

Goals & Safety Guardrails

Replace all four legacy tools with a single unified platform and retire their codebases, maintaining business continuity with a target of less than 15% reversion rate and less than 5% order volume dip during rollout.

The Core Tension

Designing one tool for two opposite user types: high volume power users who demand spreadsheet speed tables, and small self service suppliers who need step by step guidance.

The Solution

A dual-path architecture—dense data tables for power users and a guided wizard for beginners—built from a single, shared validation spec.

Discovery and insights

Built at different times by different teams, the four tools ignored each other while serving ~3,400 suppliers. A side-by-side audit, journey mapping and a supplier survey showed where it hurt.

Pain points: suppliers

• Inconsistent and unreliable. Different terms, design and flows for the same task, and inputs that sometimes didn't save.
• No overview. Suppliers using more than one tool had no single view of their in-progress orders.

Pain points: Wayfair

• No feature parity. Four codebases, each with different capabilities.
• Nobody owned the journey. Each team owned a tool, and order data was split across four systems.

Discovery

Mapping how each segment restocked CastleGate showed what really differed, and what didn't.

• Different routes: each segment went through different Wayfair teams, tools and handoffs.
• Self-imposed differences: most came from the tools each team built, not from the suppliers.
• Same destination: every route ended in an inbound order.
• Same inputs: a survey showed suppliers of every size decide by forecast, past sales and inventory.

The goal for Wayfair: receive every order the same way, whatever its type, location or size.

Same destination, different suppliers

• Tail: many small, less technical businesses that need guidance.
• Head: a few large, professional teams with most of the volume, who want speed and every function.
• Integrated: large partners ordering from their own systems. Out of scope.

The price of one tool

Merging meant some suppliers would lose features they relied on. One flow for everyone would be too slow for head suppliers and too heavy for tail suppliers, so we built two flows in one tool.

Development

Before designing screens, I fixed what made the old tools inconsistent.

• The problem: every engineer wrote their own error states, so five people made five reasonable decisions that didn't match.
• The fix: one spec with every field, error state and edge case, covering five message types across three placements (inline, modal, toast).
• Beyond the spec: there was no shared table component in Homebase either, so I partnered with a senior engineer to build one.
• The result: both flows were built from the same source, and other teams adopted the components and the method.

Development

• Tables for power users: dense, spreadsheet-like views with inline editing, bulk actions, search and filters.
• A wizard for everyone else: step-by-step choices that say what they do.

Both paths run on one codebase.

In the wizard, every option explains itself. Not just "Truckload" but "Move products from your warehouses to Wayfair's facilities." Guiding users means explaining their non-selections too.

Validation

I ran 3 research waves, contacting 123 suppliers and interviewing 11 across the EU and North America.

• It worked: 100% completed the task unassisted, in about 4 minutes on average.
• One blind spot: almost every participant first tried the table search, expecting a catalog search. In the 12 timed sessions, finding "Manage Products" took 35% to 70% of the session, close to half on average.

The Decision Framework

• Option A (Quick Local Patch): Move or redesign the button specifically for this tool to solve the immediate research finding.
• Option B (Design System Consistency): Keep the design as-is and rely on the upcoming enterprise-wide design system rollout to establish global consistency.

The Strategic Rationale: We chose Option B. Patching the UI locally would create immediate inconsistency across Partner Home. Maintaining design system integrity was worth the short-term learning curve.

Delivery

We released in 5 phases across the US, Canada and Europe, one supplier segment at a time. Each phase was monitored so order volume held steady and reversion stayed low.

Outcomes

• Product management: daily alignment with one PM across a 6-hour gap, for ~2 years and 5 releases.
• Engineering: ~6 engineers in Boston built both flows from my validation blocks, across a 6-hour time gap.
• Design system team: escalated the "Manage Products" finding and explored alternative placements together.
• Suppliers: 11 interviews over 3 research waves shaped and validated the flows.

Results

• Every supplier segment moved to the new tool.
• 4 legacy tools and codebases retired.