Home

About

Work

Home

About

Work

Contact

Building Design Systems

Creating a comprehensive design system to standardize visual identity and design components across ACM websites.

Name

Roles:
Product Designer

Timeline:

10 weeks

Team:

4 Desingers

Skills / Tools:

Figma; UI design, UX research, prototyping

Roles:
Product Designer


Roles:
Product Designer

Timeline:

10 weeks


Timeline:

10 weeks

Team:

4 Desingers


Team:

4 Desingers

Skills / Tools:

Figma; UI design, Design Tokens, Responsive Design

Scope: Tokens, components, and documentation · Web & Mobile · Light & Dark Mode

Overview

ACM is UCSD's largest programming student organization, with over 500 members. The ACM Design System is a token-based design language built to unify the visual experience across all ACM club websites. It covers color primitives, semantic design tokens, a modular type scale, elevation layers, and fully documented interaction states. I primarily worked on creating reusable components, or "molecules" that followed our guidelines for designers to use.

Before this system existed, every club project started from scratch. Designers rebuilt the same buttons, color palettes, and type styles from memory. Developers hand-coded every UI element independently. Every website looked and felt different, and an enormous amount of time was wasted on work that had already been done before.

The Problem

Name

No shared foundation

ACM has many sub-groups, each with their own website. Without a shared design language or component library, every new project was its own island. There was no agreed-upon color, no standard type scale, and no documented component behavior.

Designers were rebuilding from zero on every project

Every new club site required making the same decisions from scratch: How much spacing should we use? What does a button look like on hover? What should the menu component look like and what should it look like on desktop vs mobile? This kind of maintenance consumed hours on every project with no carryover to the next.

There was no standardized practices for typical, granular design decisions and no standardized reusable components. Styles were copied and pasted at best, recreated from memory at worst. Minor differences accumulated across files until projects looked like they came from a different team.

Developers were manually coding every component

Without a component library, developers built UI elements from scratch for each club site. The same button, the same card, the same navigation pattern, coded independently by different people. CSS was duplicated, markup was inconsistent, and there was no documentation to reference when a new developer joined. The result was slow builds, inconsistent behavior, and a codebase that was expensive to maintain.

Being Visually Overwhelming

Aha! surfaces hundreds of indistinguishable grey fields, most unpopulated, making it nearly impossible to compare ideas at a glance.



A Broken
Collaborative Process

One PM described evaluating 50–60 ideas across three people, each using their own Excel sheet, their own categories, their own ratings — and spending 4 hours just to merge them. Then 2–3 more days to find agreement.

Design Goals

  1. Single Source of Truth

One file. One token set. One library that all clubs inherit from. No forks, no local overrides.

"How do I rate and reflect on this idea on my own terms?"

  1. Building Tokens First

Every color, spacing unit, and typographic choice lives as a named semantic token, never a hardcoded value. This is what makes theming, dark mode, and future changes possible.

  1. Accessible by default

Color pairings meet WCAG 2.1 AA across both light and dark modes. Accessibility is baked into the primitives.

"How do I rate and reflect on this idea on my own terms?"

  1. Documenting states

Every interactive component is documented across all five states: Default, Hover, Focused, Active, and Disabled. No ambiguity in the handoff.

  1. Responsiveness

Typography, spacing, and components adapt across Desktop and Mobile breakpoints. Nothing is one-size-fits-all.

"How do I rate and reflect on this idea on my own terms?"

  1. Color symmetry

Light mode and dark mode share the same palette infrastructure, mirrored at the midpoint. Selecting a shade in one mode has a deliberate, predictable equivalent in the other.

Design Goals

  1. Single Source of Truth

"How do I rate and reflect on this idea on my own terms?"

  1. Building Tokens First

Every color, spacing unit, and typographic choice lives as a named semantic token, never a hardcoded value. This is what makes theming, dark mode, and future changes possible.

  1. Accessible by default

"How do I rate and reflect on this idea on my own terms?"

  1. Documenting states

Every interactive component is documented across all five states: Default, Hover, Focused, Active, and Disabled. No ambiguity in the handoff.

  1. Responsiveness

"How do I rate and reflect on this idea on my own terms?"

  1. Color symmetry

Light mode and dark mode share the same palette infrastructure, mirrored at the midpoint. Selecting a shade in one mode has a deliberate, predictable equivalent in the other.

Inspiration & Research - Learning from the Best

Material Design 3

Material Design's token system was the primary architectural inspiration. We were inspired by how the semantic roles inform the names within the system, which is how we named and structured our color tokens. We also used Material's approach to layered surfaces for our elevation guide.

Rather than inventing new patterns, this system studied industry renown design systems to understand what works and why. Two systems shaped the approach most directly.

Material Design 3

Material Design's token system was the primary architectural inspiration. We were inspired by how the semantic roles inform the names within the system, which is how we named and structured our color tokens. We also used Material's approach to layered surfaces for our elevation guide.


Material Design's token system was the primary architectural inspiration. We were inspired by how the semantic roles inform the names within the system, which is how we named and structured our color tokens. We also used Material's approach to layered surfaces for our elevation guide.

Carbon Design System

The Carbon design system hosts a large number of functional design components, which I drew inspiration from. The systematic documentation of component states, usage guidelines, variants, behaviors and anatomy labels influenced decisions I made in our design system.

The Carbon design system hosts a large number of functional design components, which I drew inspiration from. The systematic documentation of component states, usage guidelines, variants, behaviors and anatomy labels influenced decisions I made in our design system.

Token Architecture

The system is built on Figma Variables with two layers. No component layer holds a hardcoded hex value.

Primitives

Raw values on a numbered scale (ACM-Blue-500, Neutral-300). They are never applied directly to components.

"How do I rate and reflect on this idea on my own terms?"

Semantic Variables

Named by role in system, not it's color value. Each semantic variable points to a different primitive depending on the mode.

"How do I rate and reflect on this idea on my own terms?"

Color System

Name

Typography

Surface and Elevation

Name

Components

I mainly worked on the components within the design system. Every component in the library was built from scratch. Each one references semantic tokens throughout, meaning no component contains a hardcoded color, spacing, or type value. All interactive components are documented across the same five states: Default, Hover, Focused, Active, and Disabled.

Buttons

Name
Name
Name
Name

Pagination

Name
Name

Tables

Name
Name

Accordians

Name
Name

Next Steps

Storybook integration

Components are being migrated into Storybook so developers have a dedicated reference for every component in the library. Each entry shows the component and provides code snippets developers can copy directly into their codebase.

"How do I rate and reflect on this idea on my own terms?"

New Designer Onboarding

The next step is structured onboarding for designers, including walkthroughs of how the token system works, do's and don'ts for each component, and guidelines for how to extend the system when a new use case is not covered. The goal is that a designer joining ACM can be productive with the system without needing to ask someone how it works.

Pre-build Pages

With the component library established, the next layer is full page layouts. Templates for common patterns built entirely from system components. These give designers a starting point that is already token-connected and responsive, and demonstrate to developers what correct system usage looks like at page scale.

"How do I rate and reflect on this idea on my own terms?"

Create a free website with Framer, the website builder loved by startups, designers and agencies.