TEAM
1 Product Designer (me)
TIMELINE
2 months
METHODS
Token architecture · Component design · Accessibility (WCAG AA contrast) · Documentation
TYPE
Design System / Concept project
BACKGROUND
Pulse was built as the final project of a design systems course — and treated as if it were real.
CHALLENGE
How might we build a design system flexible enough to support multiple brand identities — without requiring a designer to manually update every component every time?
Reusable components built and documented in Figma
All driven by a single token change
1
2
3
4
5
DEFINE
Scope + token structure
FOUNDATIONS
Color, type, spacing, grid
COMPONENTS
20+ modular pieces
THEMES
4 brand variants
DOCUMENT
4 brand variants
The brief was open: build a scalable, token-based system from scratch. Every structural decision — how to name tokens, how many components to scope, how to handle accessibility, how to document for developers — was mine to make. I used existing systems like Material Design as reference, then deliberately chose a simpler naming convention I could defend and explain to any developer in a handoff.
1.
2.
3.
4.
I reviewed several naming conventions including Material Design's semantic approach (e.g. "on-primary", "surface-variant"). While semantic names communicate intent, they create confusion when building out color styles — you need to memorize what each name maps to. I chose a numeric scale (primary-100 to primary-1000) because any designer or developer can immediately understand the relationship between values without a reference guide. Lower number = lighter. Higher number = darker. No lookup needed.
Tradeoff: less intent-signaling, more immediately readable
A design system can always have more components. The risk is building components nobody uses, or building them before the patterns that justify them exist. I scoped Pulse to 20+ components that cover the most common UI patterns — navigation, forms, feedback, data display — rather than trying to be comprehensive. Every component in the library has a documented use case. None exist just to pad the count.
Tradeoff: smaller library, higher quality and documentation per component
Every visual decision in Pulse traces back to a defined token. Change the token, change the entire system — no manual updates, no inconsistencies.
Light, Dark, Blue, and Rose themes aren't separate systems — they're the same system with different token values. Swap the palette, the entire product follows.
Every component is composed from smaller primitives. Nothing ships without a usage guideline — what it's for, when to use it, and what to avoid.
Pulse lives on a dedicated documentation site — browsable by designers and developers without opening Figma. Built via vibe coding; designed entirely by me.
Add semantic alias tokens on top of the primitive scale — names like "color-button-primary" that reference "primary-500" would make the system more developer-friendly in a real handoff context.
Test the documentation site with a developer — I designed for clarity, but I never validated whether a developer could actually find what they needed without help.
