Dell Design System V3
Project Context
The Dell Design System (DDS) is the design language that unifies Dell's digital experience — used by 100+ product teams company-wide, across design and engineering, to build web, application, and data-visualization experiences at enterprise scale.
This project began with the need to move DDS to its third major version, V3. The business goal went beyond a visual refresh — it was structural. Dell needed to modernize the design system's architecture through tokenization, enabling greater customization flexibility, tighter design-to-code parity by reducing friction between Figma and implementation, and positioning the system to be AI-ready — an increasingly critical requirement as both product teams and AI agents begin working directly with design systems.
I worked within a broader design organization, as part of the 4-person core team responsible for analyzing, researching, and rebuilding the system's components from the ground up. This core team worked side by side with engineers, PMs, and other disciplines involved in delivering DDS V3 — a genuinely cross-functional effort, since every token architecture or component decision directly impacted dozens of product squads across Dell.
The Problem
The previous version of the system (V2) was mature and widely adopted, but carried structural limitations that became more painful as the number of consuming teams grew:
Visual and behavioral inconsistencies across components, accumulated over time as the system grew organically.
Lack of tokenization: design values such as color, spacing, typography, and more, weren't structured as tokens, which made design-engineering conversations harder and created constant friction translating visual decisions into code.
Design-to-code parity gaps: what was documented and designed in Figma didn't always match what existed in implementation, a recurring source of rework and misalignment between squads.
This created a friction loop: the more teams adopted DDS, the more visible the inconsistencies became — and the more expensive it was to fix them manually instead of at the system's root.
Research
Rather than a traditional research process involving external users, research on this project meant a deep, systematic audit of the system itself. Working alongside design and engineering, we mapped the entire Dell Design System, reviewing it component by component to surface the inconsistencies and design/technical debt accumulated across V2.
In practice, this mapping functioned as a full structural audit: each component was evaluated not in isolation, but against the token and architecture principles the team was beginning to define for V3 — laying the groundwork for the reconstruction that followed.
Synthesis
The key insight emerged from a pattern that kept surfacing throughout the audit: V2's components were structurally too rigid for product teams' real-world use cases. When teams couldn't find the flexibility they needed within the system's guidelines, they resorted to detaching components in Figma — disconnecting the instance from the main library to customize it enough to meet their product's specific needs.
What initially looked like an isolated usage-discipline issue was actually a symptom of a deeper structural limitation: every detach removed that component from the design system's update pipeline, silently breaking the consistency DDS was meant to guarantee, and creating drift between what was documented and what actually shipped to production.
This insight redirected V3's architecture. Instead of trying to anticipate and lock down every possible variation of a component — the path V2 had been on — the team flipped the logic: give teams the freedom to build their own use cases within the system, not outside of it. That decision translated into an atomic design mindset paired with Figma Slots, letting every team compose variations from DDS's atoms like building blocks — without ever having to break the connection to the main library.
Ideation
Generating solutions: the process combined two moves — external benchmarking and internal reconstruction guided by atomicity. The team benchmarked other design systems in the market, looking at both component structure and token architecture, using those references not as a template to copy but as a starting point to validate or challenge our own decisions.
For the rebuild itself, the team structured the work around atomicity: starting with atoms — the system's most fundamental elements — and progressively moving up to molecules and, from there, to more complex structures. That sequence wasn't just a way of organizing the work; it was a strategic decision to make sure the system's foundation was solid before building anything on top of it, avoiding a repeat of the structural fragility identified in V2.
Alternatives considered: token hierarchy was one of the most debated topics in the process. The conversation around semantic tokens vs. component tokens ran through much of the ideation phase, since that decision directly shaped the balance between flexibility and predictability the system would offer to consuming teams.
The approach to slots also shifted significantly over the course of the project. Early on, since Figma hadn't yet shipped native slot functionality, the team built and relied on an internal slot solution inside DDS itself. Once Figma released native slots, the team remapped every component using the internal solution to adopt the native feature instead — a shift that added even more flexibility to the system and reinforced the modular architecture that became one of V3's core pillars.
Solution
The result of this work was the reconstruction of the Dell Design System as a token-first, atomic, and AI-compatible system — a structural repositioning, not just a visual one, of what DDS is and how it's meant to be used.
Core pillars of the solution:
Token-first architecture: clear contracts between tokens and components, creating a design-value layer that's programmatically traceable — the foundation V2 was missing to keep design and code in sync.
Atomic foundations: components rebuilt from reusable, fundamental parts, designed to be consumed by designers, engineers, and AI tools alike.
Slot-based modular architecture: lets product teams customize components without breaking the system's overall consistency — directly resolving the "flexibility for teams" vs. "brand consistency" tension that existed in V2.
Reduced handoff friction: with clearer contracts between tokens, slots, and components, the development cycle between design and engineering becomes more direct, with less manual interpretation translating Figma into code.
What changed from V2: V2 was a robust system, but it was built on fixed, non-tokenized values, which made global changes costly and manual. V3 flips that logic: change now happens at the token layer, propagating automatically to every component and product that consumes it — enabling system-wide updates at scale, without regressions or manual, component-by-component fixes.
Today, DDS V3 powers a library of 30+ reusable components, with complete Figma libraries and matching implementation across React, Angular, and Vanilla — serving as the single source of truth for 100+ product teams at Dell.
Testing
Validating the solution wasn't a single step at the end of the process — it was a continuous, collaborative practice built into the core team's weekly rhythm.
With engineering, that validation happened through weekly syncs dedicated to checking token architecture decisions against implementation reality — making sure the contracts we were designing between tokens and components actually reduced friction for developers day-to-day, not just on paper.
To validate the migration itself, pilot teams tested the transition from V2 to V3 before the general rollout — an essential step to surface real adoption friction before rolling the change out to the 100+ product teams that depend on the system.
Accessibility was treated as a structural part of validation, not a check performed after the fact: we stayed in direct contact with Dell's accessibility team, running dedicated sessions to review every design decision that changed from V2 to V3 through the lens of compliance and inclusion.
Internally, the core team validated each other's work constantly. Since we worked together almost daily, design critique happened organically, built into the day-to-day — no need for formal design-crit sessions for that cross-review to take place.
Taken together, the validation process reflected the nature of the project itself: deeply collaborative, both within the design core team and in constant partnership with engineering and accessibility — making sure V3 was stress-tested from multiple angles before reaching the teams who rely on it every day.
Learnings
What I learned: above all, this was a deep learning process in how a design system actually works under the hood — not in theory, but through the practice of rebuilding one from scratch. Understanding how tokens connect to design decisions, how to properly structure componentization inside Figma, and how to optimize the way a component is built — since a good portion of V2's components simply hadn't been built the best way possible — was a technical education that goes well beyond this one project, and now shapes how I approach any design system.
But the learning that stood out most wasn't technical — it was about process and collaboration. It became very clear, throughout the project, how much cross-team communication determines the success of work at this scale. Leaving guidelines and expectations clear and documented isn't a "nice to have" — it's what keeps everyone moving in the same direction. That became even more evident in an environment of 30+ people, across different areas and priorities, all working toward a single goal — without explicit alignment, diverging interpretations quietly pile up, which is exactly the kind of structural problem V3 itself was designed to solve.