Case Study 02 · Wayfair · Design Systems

Table v2
Enterprise
Design System

Rebuilding Wayfair's most complained-about component into a 99-piece modular library that moved user satisfaction from 2.8 to 4.5 out of 5.

Role
Lead Designer / Design Manager
Company
Wayfair, Enterprise Design
Timeline
10 weeks · 5 design sprints
Team
Lead designer + 2 designers I mentored through the project
Table v2, Row Selection
2.8→4.5
Satisfaction
out of 5
200K
Users across
internal tools
99
Components
delivered
#1
Top Slack complaint
→ resolved

The component that everyone
hated, rebuilt from first principles.

Tables are everywhere at Wayfair. Every supplier portal, admin tool, inventory system, and internal dashboard relies on them to present dense operational data. With 200,000 suppliers, agents, and internal users interacting with these tools daily, the quality of the table component had outsized impact on productivity across the entire organization.

Table v1 had become the #1 complaint in Wayfair's design help channel on Slack. That's not a minor UX annoyance, that's a systemic failure that was slowing down designers, frustrating engineers, and creating inconsistency across every internal product.

I was tasked with leading the v2 redesign: managing a team of 3 designers, running the research, architecting the component system, and delivering something that would work for every use case Wayfair teams actually needed, not just the ones we'd anticipated.

Three failures that made
Table v1 unusable.

Table v1, State of affairs
2.8/5
Average satisfaction across all users. Below the threshold where most teams would even bother filing feedback, they'd just started working around it.
Why it mattered
200K
Users across Wayfair's internal product suite. Every tool, portal, and admin dashboard touched by this component.
Rigidity, no flexibility
Component props were fixed. Any customization required breaking symbols, a destructive workflow that created inconsistency across products and made every implementation a one-off.
Poor documentation
No guidelines explaining what components could or couldn't do. Designers regularly built table layouts that engineers couldn't implement, causing rework on both sides.
Insufficient variants
The component library didn't cover the range of table use cases teams actually needed: expanded rows, bulk actions, editing states, complex filtering, scrolling.
The Slack signal
Being the #1 complaint in the design help channel meant teams were actively reaching out, which meant they were blocked. That's a different kind of failure than silent workarounds.

Before Table V1, the original simple table experience prior to the redesign. This early version lacked the flexibility, scalability, and component architecture teams needed across enterprise applications.

Competitive analysis first.
Then the real insight.

Before running user interviews, I conducted a competitive analysis of Material UI/React Table and IBM Carbon Design System, two industry references for best-in-class table implementations. The common thread between both: great design systems provide modular, composable components, not monolithic ones. You get lego bricks, not a pre-built house.

That reframe, from "one table component" to "a system of constituent parts", became the philosophical foundation for everything that followed.

I then conducted 10 contextual interviews over 5 days with designers and developers who used Table v1 regularly. Three themes emerged consistently:

What users needed
Clear guidelines on what each component can and can't do · The ability to customize individual table components independently · A way to build complex tables in Sketch without breaking symbols

That third point was particularly telling. The fact that the main workaround was "break the symbol and rebuild it manually" meant the component library wasn't actually being used, it was being referenced and then abandoned. That's not a documentation problem; it's a fundamental architecture problem.

User testing was conducted with 20 participants across five design sprints. Affinity mapping helped quickly synthesize feedback, identify recurring themes, prioritize opportunities, and align the team on the highest-impact improvements.

Not a component.
A system of parts.

This reframe changed how we structured every deliverable. Instead of designing "a table," we designed cells, headers, row states, filter panels, action bars, sort indicators, column resize handles, individually, with clear documentation, and then demonstrated how they combined into compound patterns for the most common use cases.

The result: designers could assemble what they needed. Engineers could implement it prop by prop. And the system stayed consistent because the atomic pieces were the common language.

The Core Reframe
"Table v2 is not a single component, it's a system of constituent parts that teams can assemble like lego blocks. This gives designers and developers the flexibility to tailor layout and functionality to their specific application, without ever needing to break a symbol."

Five sprints.
Every pattern tested.

I organized 5 design sprints over 10 weeks, each targeting a specific table interaction pattern. Each sprint ended with user testing, synthesized in Miro via affinity mapping. Designs iterated between sprints based on direct feedback, with 20 participants total across the sprint series.

SprintFocus AreaKey Output
01Simple Tables & Basic StructureBase atomic architecture, column sorting, cell states
02Editing & AlertsInline editing patterns, alert and validation states
03Filtering & Bulk ActionsFilter panel component, multi-select with bulk action bar
04Customizable Columns, Quick View, Expandable TablesColumn config modal, expandable row pattern, side panel
05Scrolling & OverflowSticky headers, horizontal scroll, frozen columns

99 components.
One cohesive system.

Each pattern below was tested with internal Wayfair designers across 5 sprints before being built into the component library.

01
Atomic Component Library
These were some of the early iterations used to gather rapid feedback from users across five design sprints. By testing concepts early and often, we were able to refine the architecture before investing in high-fidelity designs and engineering implementation. 85 atomic building blocks, cells, headers, sort indicators, filter triggers, status chips and more. Designed to combine independently so teams could solve problems we hadn't anticipated.

Atomic Lego Pieces, foundational table building blocks including headers, cells, actions, alerts, pagination, and interaction patterns.

Low-Fidelity Prototype: Simple Table, early exploration focused on hierarchy, readability, and scalability.

Low-Fidelity Prototype: Table with Caption, testing supporting metadata, context, and content relationships.

Low-Fidelity Prototype: Selectable Rows, validating bulk actions and row-selection workflows.

02
Before & After: Table v1 vs Table v2
Pre-assembled patterns for Wayfair's 6 most common table use cases, Simple, Editing, Expandable, Row Selection, Filtering, and Scrolling. Each one is 100% prop-driven, with no symbol-breaking required.
Simple Table
Before
Simple Table before
Table v1's original simple table, a rigid flat layout with no customization.
After
Simple Table after
Table v2 with alternating rows, full prop control, and a consistent atomic structure.
Expandable Rows
Before
Expandable Rows before
Table v1's expandable rows, symbol-breaking required for any customization.
After
Expandable Rows after
Table v2's expandable rows, independently configurable and fully prop-driven.
Row Selection
Before
Row Selection before
Table v1 row selection, no guidance on patterns, no contextual actions.
After
Row Selection after
Table v2 row selection with checkbox highlighting and a contextual action bar.
Editable Rows
Before
Editable Rows before
Table v1 editable rows, hard to distinguish edited from unedited fields.
After
Editable Rows after
Table v2 editable rows with clear highlight states and full use-case documentation.
03
14 Compound Table Pattern Examples
Compound table patterns are example templates teams can use straight out of the box, dissect for parts, or treat as inspiration, a way to show what's possible when you assemble the atomic building blocks into your own pattern for your specific use case. Below are two of the compound patterns I built for teams.
Compound pattern, Bulk Actions table
Compound pattern, a Bulk Actions table assembled from atomic components, with multi-select and a contextual action bar.
Compound pattern, hero table
A compound table pattern, a table that combines bulk actions, selectable rows, and a running summary of how items were selected.

Clear Component Guidelines for designers and developers.

Beyond designing the system itself, I helped create crystal-clear documentation explaining how to use Table V2, its atomic components, the six core table patterns, and compound examples demonstrating how teams could extend the system to meet unique user needs. The documentation included implementation guidance, interaction behaviors, accessibility considerations, DOs and DON'Ts, and examples for both designers and engineers.

Based on research feedback, teams needed confidence that they were using components correctly. We introduced reusable templates, plugins, and workflow accelerators that helped designers rapidly assemble tables while maintaining consistency across Wayfair's enterprise ecosystem.

Homebase EPD V2 Toolkit and supporting documentation used to scale adoption across product teams.

Download Usage Guidelines

The #1 complaint
resolved.

ComponentBeforeAfter
Editing Table2.0/54.0/5
Expandable Table2.3/54.5/5
Row Selection3.0/54.0/5
Overall Average2.8/54.5/5
Users impacted200,000+
Components delivered99 (85 atomic + 14 compound)
"The new table components helped me increase my productivity building custom tables drastically! Also, the updated guidelines make it much easier to understand the limitations and what is possible."
Product Designer, Wayfair Merchandising

The hardest design problems
are architecture problems.

Takeaway
"The insight that changed everything wasn't a new component design, it was reframing what a 'component' should be. By thinking in atomic building blocks rather than pre-built solutions, we gave teams the flexibility to solve problems we hadn't anticipated. Great design systems don't prescribe answers; they give teams better building materials."

This project also shaped how I think about design leadership. With two direct reports on the project, I had to split my time between doing the work and making sure the team was doing their best work. The most valuable skill wasn't the design itself, it was teaching junior designers how to think in systems, run research, and defend decisions with evidence.

← Previous My Cases, USCIS/DHS Next Case Study → BNPL International Launch