Improving Designer Workflow with Design System
3 Team Members
May - October 2025
Design System Guy
Overview
I worked on the foundation of AMD Software first design system and the redesign of its next-generation software experience.
Over the summer and fall, I joined AMD’s User Experience team as a UI Design Intern. Our team focused on improving GPU and CPU performance tools, and with AMD expanding into markets beyond gaming, we began a large-scale software redesign. I supported this effort by designing prototypes and helping build the design system that guided the new direction.
Context
When I first joined, the team didn’t have a proper design system in place. Everyone had their own way of organizing files, assets were scattered, and the products often felt like they were stitched together without a common thread. Around the same time, the team was making the big shift from Adobe XD to Figma, and I saw that moment as an opportunity, not just to ease the transition, but to help build something lasting.
Context 1.1 - problem overview
Initial Trial – Learning the Product
I initiated and led a trial migration of key design assets, including UI components, the icon library, and shared styles into Figma. This tested the transition process, improved consistency, and helped identify the components needed for the new AMD Software concepts.
Trial run 1.1 - UI components example
Trial run 1.2 - icon library
Taking It to the Next Level 🚀
From that trial, I began shaping a supporting design system to guide the new version of the software through its early ideation stages. My goal was to create a single source of truth, a foundation of guidelines that future UI components could consistently build upon, ensuring clarity, scalability, and cohesion as the product evolved.
Laying the Groundwork
Designer's Cheatsheet (Color Tokens)
To keep our design system flexible, I used primitive tokens as the base colors and semantic tokens that reference them for components. This way, components rely on intent-driven tokens like button/primary/fill instead of raw colors.
Cheatsheet 1.1 - primitive color tokens
Once the primitive tokens were defined, I linked them to semantic tokens and named them based on component roles or states. This ensured components always referenced intent-driven tokens, making updates and adding the light-mode themes easier.
Cheatsheet 1.2 - semantic color tokens
Designer's Cheatsheet (Numeric Tokens)
In addition to color tokens, numeric tokens used for spacing and radius are defined to enforce a consistent 4-point base scale and make layout tweaks safe and predictable across the system
Cheatsheet 1.3 - spacing & radius-border tokens
Building the Components
Dissecting UI Components
After the designs were approved by stakeholders, I began breaking the UI into smaller, reusable components to set the foundation for future maintainability. It wasn’t always the most efficient path, especially with so many ongoing iterations. But I learned that building too many components too early could add unnecessary complexity.
Building 1.1 - the anatomy
Proper Color Structure
With the help of pre-defined color tokens, I could easily assign colors to components according to their semantic role. This not only sped up the design process but also ensured consistency across the system and made future theme updates effortless.
Building 1.2 - using tokens to define color structure
Applying the Foundational Design Tokens
With predefined foundational tokens, all design assets can be categorized by token type, allowing designers to simply apply the appropriate tokens based on the asset type.
Building 1.3 - slots to support variants
Supporting Multiple Variants
Instead of creating endless variants that would complicate the system, I chose to use the slot method. By treating slots as flexible placeholders, I gave the components room to adapt their content while still maintaining a consistent and polished appearance.
Building 1.4 - slots to support variants
Reducing Communication Gaps Between Designers and Developers
A big challenge between design and development is interpretation. What looks clear in Figma can become unclear in development, leading to misalignment in implementation and back-and-forth. To solve this, I’m creating guidelines that outline each component’s behavior and variants so designers and developers know exactly how things should work without the guesswork. Designers may also benefit from getting a proper understanding of how to use the design system and the components.
Guideline 1.1 - UI components behavior guideline
Guideline 1.2 - usage guideline
Significant Impact
I can’t share the concept designs themselves, but the difference the design system made was obvious. Once we started using system assets, things just felt more consistent. For example, colors were unified and the number of random hex codes floating around dropped way down. It also made our mockups so much easier to maintain, since updates could be applied quickly and carried across all designs without extra work.
Impact 1.1 - consistent color usage
Additionally, with pre-defined values, designers no longer had to guess spacing and radius value. It is as easy as picking from a set menu! This not only sped up decision-making but also gave every screen a cohesive rhythm and flow.
Impact 1.2 - consistent radius & spacing
Proposing Documentation in Supernova
The next step is to create the documentation in Supernova, as it transforms the design system from static Figma files into a living, developer-ready source of truth. Unlike Figma’s internal notes, Supernova automatically syncs design tokens, components, and guidelines while generating platform-specific code and versioned documentation. It also includes an AI assistant that allows internal team members to ask questions about components or usage, making it easier to discover, and understand the design system.
Impact 1.2 - consistent radius & spacing