Design System 0→1
Built from scratch, then rebuilt with AI. A token-based, WCAG 2.2 AA-compliant design system for a healthcare cloud monitoring platform.
(AI-Assisted · Token-based · WCAG 2.2 AA)
Client: Cloudticity
Role: Sole Product Designer (Contract)
Tools: Figma, Claude AI, Figma MCP, Stark, Able, Figma Variables, Notion
context
I originally built Cloudticity's design system as their sole product designer, creating it from scratch to support three product silos: Oxygen, Nitrogen, and Oxygen AI. After ending my contract with the company, I returned to it independently with fresh eyes and a clear goal: rebuild it properly, applying everything I'd learned about scalable token architecture, accessibility, and AI-assisted design workflows.
This project wasn't about fixing failure — the original system shipped and delivered value. It was about growth. I wanted to take something I'd built under the constraints of a fast-moving startup and evolve it into the kind of rigorous, scalable system I'd want to hand off to a dev team or inherit as a new designer.
My role
I wore two hats on this project: the designer who built the original system from scratch, and the systems thinker who came back to evolve it.
When I worked with Cloudticity, I built the entire design system from zero — creating components, establishing visual language, and supporting three product silos through a fast-moving development cycle. Later on, returning to it independently, I could see what it needed to become. What made this rebuild different from a typical design system project was how I used AI as a design engineering collaborator.
I worked with Claude throughout — not to make design decisions, but to execute at scale. The collaboration worked like this: I'd identify a problem, decide on the solution, and Claude would execute it programmatically across the entire library in seconds. Things that would have taken weeks of manual clicking were done in hours.
Every design decision was mine. The token architecture, the semantic layer structure, the accessibility triage, the naming conventions — all of that required design judgment that AI can't replicate. But Claude handled the mechanical execution: scanning all 87 component sets for hardcoded color values, batch-renaming 200+ variant properties, running a full color audit, wiring 81 variables to semantic tokens across every component, and building the documentation pages automatically from live token data.
This was a new way of working and it changed how I think about what's possible as a solo designer on a systems project of this scale.
Knowing when AI is wrong is just as valuable as knowing how to use it. Design judgment isn't going anywhere.
The problem
The original system was built in motion, a common reality in fast-moving startups. Components were created as features were needed, naming conventions evolved organically, and dark mode was handled through duplicate component variants rather than variable modes. Color styles and variables coexisted without a clear hierarchy, making the architecture harder to maintain and extend as the platform grew.
The rebuild scope
• A proper two-layer token architecture (palette → semantic)
• Consistent naming conventions enforced across all 107 component sets
• Dark mode via variable modes — not duplicate variants
• A full accessibility audit against WCAG 2.2 AA
• Complete component documentation
Approach
I structured the rebuild into six phases: audit and naming, token architecture, accessibility, component consolidation, token wiring, and documentation.
AI collaboration
• Scanned all 87 component sets for hardcoded color values programmatically
• Batch-renamed 200+ variant properties across the entire library in one operation
• Ran a full color audit to identify off-palette values, duplicates, and mis-linked tokens
• Wired 81 variables to semantic tokens across every component
• Created the Overview and Foundations docs pages automatically from the live token data
Tool stack
• Claude — programmatic operations via Figma Console MCP
• Stark Pro — WCAG 2.2 AA accessibility audit
• Able — day-to-day contrast checking
• Figma Variables — two-layer token architecture (palette → semantic)
• Notion — documentation and progress tracking
token architecture
The most significant structural change was introducing a proper two-layer token system:
Layer 1: Core palette
24 raw color values, organized by family: teal, neutral, gold, cyan, red, green, charcoal
24 raw color values, organized by family: teal, neutral, gold, cyan, red, green, charcoal
Layer 2: Semantic tokens
32 tokens describing meaning, not color: color/brand/primary, color/surface/hover, color/feedback/danger, color/text/static-white
32 tokens describing meaning, not color: color/brand/primary, color/surface/hover, color/feedback/danger, color/text/static-white
This separation means a button's background isn't #2D546B — it's color/brand/primary. When the brand colour changes, or when the component renders in dark mode, everything updates automatically. No manual overrides. No duplicate components.
Dark mode now works via Figma's variable mode switching — a single component set automatically resolves to the correct palette values based on the frame it sits in. The 200+ separate dark mode variants that existed before were eliminated entirely.
Accesibility
I ran a full WCAG 2.2 AA audit using Stark Pro across all Atom components, triaging 121 violations and 95 potential issues.
The most impactful fixes
• Corrected a rogue green (#049F26) that failed contrast requirements — replaced with #088924 across the library
• Fixed disabled text tokens pointing to border colors rather than text colors
• Established clear token intent for the accessibility edge cases: color/text/disabled for inactive states, color/text/static-white for text on colored surfaces (following Google Material's naming convention)
Component consolidation
Through the audit I identified significant redundancy — component sets that were logically the same component split across multiple files due to how the library had grown. I consolidated from 107 to 90 component sets, establishing consistent naming conventions throughout:
State= for interactive states (hover, selected, disabled, default)
Status = reserved exclusively for data/domain values (compliant, suppressed, in progress)
Mode = removed from all components — handled by variable modes instead
Naming hierarchy standardized: Component / context / variant
Final results
Before
• 107 component sets
• Color styles and variables mixed
• Hardcoded hex values throughout
• Separate light + dark variants
• No accessibility audit
• Incomplete component descriptions
• naming conventions
After
• 90 component sets
• 81 variables across 4 collections
• 100% token coverage
• Single variants, mode-switched via tokens
• WCAG 2.2 AA reviewed
• All 90 sets documented
• Standardized naming across all components
Reflections & Growth
This project reinforced something I believe strongly: the best design systems are built with both design judgment and engineering rigor. Knowing when a change is a design decision (which token does this fill represent?) versus an execution task (apply this token to 200 variants) is a skill — and AI tools are increasingly blurring that line in useful ways.
The AI-assisted workflow also changed how I think about scale. I can now audit and restructure a library of this size in a fraction of the time it would have taken manually. That's not about replacing the thinking — it's about removing the friction between thinking and doing.
