DDS V3 Table Component
Project Context
As part of the broader Dell Design System V3 initiative, this project focused on redesigning the DDS table component — one of the most complex and heavily used components in the entire system.
The table component serves Dell's internal community of product designers working within the Dell Design System, who rely on it to build data-heavy interfaces across Dell's product ecosystem. The business objective was straightforward but high-stakes: make the table component significantly easier for designers to use, without sacrificing the flexibility real product work demands.
I led this project as Product Designer and Project Lead, working within the same core team driving the broader V3 effort, with direct ownership over the table component's redesign end to end — from audit to final solution.
The Problem
The V2 table component was rigid by design, and that rigidity showed up as sprawling complexity. Because the component tried to pre-build every possible configuration as a fixed variant, its variant count had ballooned out of control:
Sub-component | V2 Variants |
Header Cell | 108 |
Body Cell | 312 |
Search | 6 |
Toolbar | 6 |
Header Action Menu | 6 |
Column | 108 |
Table | 18 |
Total | 560+ |
Beyond the sheer count, the component wasn't built in an optimized way — any use case that didn't match an existing variant meant either a workaround or a request for a new one, compounding the complexity further with every release.
User pain: the table component wasn't flexible enough for real day-to-day use. To get the table they actually needed, designers routinely had to detach the component from the library — breaking it out of the design system entirely just to modify it freely.
Metrics: two signals stood out. First, a high volume of detaches specifically on the table component. Second, it was consistently the component generating the most user complaints — both from designers working with it in Figma and from engineers dealing with its complexity in production.
Research
Research combined quantitative usage data with direct conversations with users. Looking at Figma component-usage metrics and talking to designers who worked with tables regularly, a clear pattern emerged: people weren't using the table component the way it had been built.
Instead, designers were pulling body cells and header cells out on their own, in their raw atomic form, and assembling tables outside the official DDS table component altogether — either inside a plain frame or by building a local, unofficial table component from scratch.
That behavior was the project's turning point: users had already found their own workaround for the system's rigidity, and it pointed directly at what the real solution needed to look like.
Main Insight
Talking to designers surfaced one key insight: users weren't using the Table the way it was structured in Figma. More often than not, they'd detach the component entirely and work only with its atomic parts — Header and Body cells.
Figma's grids and auto layout made it possible to design for that behavior instead of against it. We could give users what they were already doing: just the atoms, with the freedom to build their own table outside the boundaries of a rigid component. Once assembled, that table could be dropped straight into a slot component — no detaching required at any point in the process.
This didn't just keep the system intact. It opened up far more possibilities for our users than the old, rigid structure ever could.
Synthesis
The core insight was that the table needed a fundamentally more flexible structure — one that could cover a far wider range of real use cases than a fixed variant matrix ever could.
Since V3 was already introducing Figma Slots and an atomic design approach system-wide, the table component was the perfect candidate to bring that same workflow into practice. Combined with Figma's new Grids feature — which functions almost like a table on its own — this pointed toward a solution that would give users significantly more flexibility while making the component itself simpler and leaner to build and maintain.
Ideation
Solutions were generated through hands-on testing rather than workshops or brainstorms: the team ran a series of experiments with Figma Slots and stress-tested how Figma Grids behaved under real table-building scenarios. Testing covered different ways of constructing the underlying atoms — evaluating what should ship as native, predefined variants versus what should be left entirely open through slots.
Solution
The solution reframed the table not as one large, pre-built component, but as atoms plus a flow: body cell and header cell atoms, combined with a Figma Grids workflow to assemble them into a table.
Critically, adopting Figma Grids wasn't mandatory. Designers could still build a local table component if they preferred — because, in effect, this solution simply made official what users were already doing unofficially through detach. Instead of fighting that behavior, the redesign embraced it as the intended workflow.
What changed from the previous version: significantly greater flexibility, easier editing, and a much leaner component build. The table component family went from 560+ variants to roughly 30 — a reduction of well over 90%, while covering more real-world use cases than the original ever did.
Testing
Validation was one of the most important parts of this project. In line with DDS's philosophy of co-creating with its users and fostering participation from Dell's internal design community, the team essentially co-created the solution with designers rather than testing it on them after the fact.
To validate whether the new workflow would genuinely improve users' day-to-day process, the team ran informal working sessions — internally called "feedback" sessions — with heavy table users. Each session introduced the problem and the proposed direction (table atoms plus Figma Grids and slots), then asked the designer to build a real use case using that workflow live, on the spot.
The results were strongly positive: designers reported the new workflow was faster, more practical, and gave them significantly more freedom to create and modify tables than the V2 component ever allowed.
Learnings
co-creation is a powerful way to generate insight. Depending on the type of project and how urgent the need is, quickly testing a hypothesis with real users often delivers more value than investing heavily in a fully formal user-testing process. Testing the table redesign this way — fast, informal, direct — made it possible to validate the idea quickly, while also giving users a sense of ownership in a change that ultimately made their day-to-day work better.