Crafting GEARS:
A Scalable Design System for STEAM
Embedded Files
Project Overview
Designing a foundational system to bring consistency, scalability, and structure to Steam’s interface
My Role: Design System Lead / UX Designer
Focus: The Store Page and The Library Page
Duration: 8 Weeks
Tools: Figma, Zeroheight, FigJam
Deliverables: Figma UI Kit · Design Token System · Zeroheight Documentation Site
Gears is a conceptual design system created to explore how Steam’s fragmented interface could be unified through a scalable, reusable system. The goal was not just to design UI components, but to build a system that supports consistency, efficiency, and long-term growth.
The Problem
The Problem
Steam's interface had no shared design language
When we began this project, we asked a simple question: What does Steam's visual system actually look like right now? We picked two pages: The Store page and The Library page; and audited every visual element on them.
We weren't looking for bugs. We were looking for patterns.
What we found instead was noise.
The Numbers
Across just two pages of Steam's platform, we catalogued:
51 button styles: Different border radii, padding values, font sizes, and color treatments, with no clear logic for which to use when
54 typography styles: Font sizes and weights applied arbitrarily, no defined hierarchy, no scale
33 unique color values: No naming system, no token structure, no documented palette
Why This Is a Workflow Problem, Not Just a Visual One
These numbers matter beyond aesthetics. Without a shared system, every designer working on Steam faces the same friction on every single task: Which button is the right one here? Which shade of blue is Steam's blue? How much spacing should go between these cards?
What Steam needed wasn't more components. It needed a foundation.
Vision
Vision
What Gears needed to be before we built anything
Before we opened Figma, we aligned on what success actually looked like. A design system can fail in many ways: too rigid to adopt, too shallow to be useful, too fragmented to maintain.
We defined five principles to anchor every decision we'd make over the next eight weeks.
The Five Principles
1. Clarity First
Every element must be immediately readable and scannable. No ambiguity in labeling, hierarchy, or interactive state.
2. Predictable Interactions
Users should always know what will happen before they click. Hover, focus, active, and disabled states must behave consistently across every component.
3. Functional Beauty
Utility drives every decision, but Steam's bold, gamer-centric aesthetic has to come through. Gears isn't just correct. It has to feel like Steam.
4. Scalable Structure
Gears must be able to grow. Components built today should still work when new surfaces, overlays, Big Picture mode, mobile, are added later.
5. Unified Experience
Whether a user is on the Store, the Library, or a community hub, every surface should feel unmistakably Steam.
Discovery Process
Discovery Process
Mapping the chaos before we could solve it
Step 1: The Interface Inventory
What we did
We took screenshots of the Steam Store page and Library page, then systematically catalogued every distinct visual element: every button, every text style, every color, every spacing value. We used FigJam to build an inventory board where each unique variant was tracked and labeled.
What we found
The numbers were stark: 51 button variants, 54 type styles, 33 colors. But beyond the numbers, the patterns were telling. Primary action buttons ranged from rounded to square. The same hover color appeared in both interactive and decorative contexts. Navigation items used three different font weights.
What it told us
The inconsistency wasn’t random, it was historical. Different teams had clearly made isolated decisions at different times, each reasonable in the moment but collectively creating visual noise. This wasn’t a taste problem. It was a systems problem.
Step 2: Accessibility Audit
What we checked
Alongside the visual audit, we checked Steam's existing UI against WCAG 2.1 AA standards, specifically color contrast ratios, focus state visibility, and text legibility across sizes.
What we found
Several button color combinations failed the 4.5:1 contrast ratio threshold for normal text. Focus states were either invisible or inconsistent. Some icon-only buttons had no accessible labels. These weren't edge cases, they appeared on the most frequently used surfaces.
What this meant for Gears
Accessibility couldn't be a post-hoc check. It had to be baked into every token and component from the start. Gears would need to make the accessible choice the default choice, so designers couldn't accidentally ship inaccessible components.
Step 3: Defining Scope: What Gets Built First?
With 8 weeks and a 4-person team, we couldn't fix everything. We prioritized components that appeared most frequently across our two audited pages and that carried the highest risk of inconsistency, buttons, navigation, typography, cards, and input fields. Patterns like empty states and error flows were secondary.
This scoping decision was important: a design system that tries to cover everything and covers nothing well is worse than one that covers core elements exceptionally. We decided to go deep on foundations.
Building the Foundations
Building the Foundations
Design Tokens: Behind every component
Before a single component was built, we established design tokens; named, reusable values that define the visual language of Gears. Tokens are the atomic layer: change a token value, and every component that references it updates automatically.
Color Tokens
Steam's 33 unique hex values were condensed into a structured semantic palette.
Typography Tokens
Steam's 54 type styles collapsed into a clear scale of 8 named levels:
Display: hero headers, game titles at full bleed
Heading 1–4: page titles down to section labels
Body: primary reading text
Caption: metadata, timestamps, supporting info
Label: button text, form labels, tags
Spacing & Border Radius Tokens
Gears uses an 8pt grid. All spacing values are multiples of 8: 8, 16, 24, 32, 48, 64, 96. This creates visual rhythm and eliminates the ambiguity and has it of 16px.
Building the Component Library
This was not just a UI kit, it became Steam’s interface grammar.
Using an atomic design approach, we built components in layers:
Atoms
Atoms
Buttons, switches, icons, text fields, now standardized with variants and states.
Molecules
Molecules
Search bars, card modules, dropdown clusters combining atoms into reusable blocks.
Organisms
Organisms
Navigation bars, library modules, purchase flows, content grids.
Patterns
Patterns
Empty states, error handling, success workflows, loading states.
Documentation
A design system without documentation is just a file of components
What the Documentation Covers
Every component in Gears has a dedicated documentation page covering:
When to use this component: And when to use something else instead
Variant guide: What each option is for, not just what it looks like
Interaction behavior: How every state (hover, focus, active, disabled) is supposed to behave
Do / Don't examples: Side-by-side visuals showing correct usage and common misuse
Accessibility notes: contrast ratios, keyboard navigability, screen reader behavior
Token references: which tokens this component uses, so developers know exactly what values to implement
The Pitch
Selling Gears to a room of skeptics
After eight weeks of building, we had one hour to convince a room full of hypothetical Steam designers, design managers, and stakeholders to adopt Gears. This was the moment where the system had to prove itself; not as a Figma file, but as a solution to a real pain.
The Feedback
The feedback we received was genuinely positive. The pitch also forced us to confront something we hadn't fully articulated before: Gears is not just a component library. It's a proposal for a different way of working. The pitch made that distinction clear and made the case study stronger for having to defend it out loud.
My Biggest Takeaway
I went into this project thinking the hard part would be building the components. The actually hard part was deciding what not to build.
Every time we audited a new pattern, there was a temptation to add it to the library "just in case." What I learned and what I'll bring into every systems project I work on is that a design system's value comes as much from what it excludes as from what it includes. An unmaintained, bloated system is worse than a small, rigorous one. Constraints are the product.
I also learned something about designing for other designers specifically. Designing for users means designing for people who may never think about the interface at all. Designing for designers means designing for people who think about interfaces constantly who will immediately notice when something in your system is inconsistent, when a naming convention breaks down, when a component doesn't quite cover their use case. The bar is different. The scrutiny is higher. And I think that made me a more precise designer.
What’s Next
For this project, we focused only on core Steam surfaces like the Store and Library, but there are many other areas to explore next.
Moving forward, I’d like to expand the audit to additional screens, refine more complex patterns, and deepen engineering alignment through coded components and motion guidelines. Accessibility and theming will also play a bigger role in future phases.
Above all, I’ve learned that a design system is never “done.” Its value comes from continuous care and contribution. As teams adopt and improve Gears, the system will grow, mature, and stay relevant long-term.
Page updated
Google Sites
Report abuse