Design System Evolution

ConstructConnect | Design System | Components | AI-Assisted Quality Assurance | Developer Collaboration
Figma | Claude AI
‍
Where It Is Now
Building a design system doesn't end when components are organized and tokens are semantic. The real work emerges when you listen to where the process breaks down. This page documents three operational innovations that emerged from ongoing collaboration with Vivian (our Tech Lead Developer) and weekly refinement cycles. Together, we've transformed a foundation system into a production-ready workflow that reduced effort by 64% while actually improving quality through systematic automation and developer-first architecture.
The work is active, iterative, and constantly improving based on what we learn from each component we extract.
What We Built:
Established token extraction workflow using Figma plugins to export design variables, then validated against our Tech Lead's implementation template using Claude. When the first batch revealed missing focus and motion tokens, I investigated the gap: Figma's variable system doesn't support motion/animation assignment at the component level. Recognizing Claude's success reading Figma Dev Mode specifications through MCP integration, I tested that approach—it captured both the missing focus tokens and motion specifications invisible to plugin-based extraction. Formalized this Dev Mode workflow as our standard process, built automated state validation system preventing incomplete handoffs, and architected token structure preparing for Storybook integration.
‍
The Impact:
  • 64% effort reduction Traditional approach: 233-321 combined hours over several months. Our approach 83-121 hours over 6-8 weeks.
  • 200+ design tokens Organized and validated, including motion specifications that were previously missed.
  • Production-ready handoffs Validation reports are now part of the output and prevent incomplete specifications from reaching development
Motion Token Extraction: Solving an Architectural Constraint
When Vivian reviewed our component specifications, she asked if the motion tokens she'd hand-coded aligned with what we had defined in Figma. I expected yes. The answer revealed a deeper problem: our extraction pipeline was systematically missing an entire category of tokens.
Figma's variable system works beautifully for design tokens—colors, typography, spacing. But motion tokens live in a completely different system: prototype interactions. Interactions have no variable linkage capability, which means they're invisible to plugins that only read the variable layer.

It wasn't that we were doing extraction wrong.
The architecture itself had a blind spot.
My Approach
  • Diagnosed the root cause: Figma's architectural design treats variables and interactions as separate systems that don't communicate
  • Identified an alternative data source: Figma Dev Mode renders components with their compiled CSS output, which includes animation specifications
  • Designed a workaround: Instead of relying on plugin-mediated extraction (which stops at the variable boundary), route extraction through Dev Mode CSS directly
  • Integrated with existing workflow:
    1. Share Figma link, Claude reads Dev Mode
    2. Extract animation specs
    3. Match against Vivian's template
    4. Format for implementation
  • Automated the process: Made this the standard extraction path so motion tokens are included by default, not discovered later
The Impact
  • Motion tokens now included in the initial handoffs. Previously discovered missing during code review
  • Automated process handles complete token set with motion specs
  • Systematic quality through AI-assisted review
  • Developer confidence increased. Our Tech Lead receives complete specifications before implementation starts
Image showing transition from figma to tokens with a report
The challenge
Building automated state validation into our extraction workflow during the foundational phase prevents future technical debt. Working with atoms and molecules—before adding complex components—we established quality assurance as standard process. The validation caught two outliers missing required focus states (WCAG 2.4.7 compliance). By implementing validation while building the foundation, we prevent compounding gaps as the system scales. The validation report makes incompleteness impossible to overlook before handoff.

Quality control was happening in code review.
It needed to happen in design.
Our approach (this was a team effort)
  • Identified the required state matrix for every component type: Default, Hover, Active, Focus, Disabled (+ context-specific states like Error for forms, Loading for async)
  • Formalized this requirement into Claude Project instructions so every extraction automatically validates against the matrix
  • Integrated into the handoff process: Token export + validation report delivered together, so Vivian sees completeness status upfront
  • Made it repeatable: Every component now goes through the same validation before leaving design
The Impact
  • Incomplete components caught in design, not code review
  • WCAG 2.4.7 compliance built in. Focus states are non-negotiable in the validation matrix
  • Validation report becomes shared artifact. Developers see proof of completeness, designers maintain accountability
Storybook Readiness: Building the Integration Path Now
We're building toward Storybook as the single source of truth for component implementation. But Storybook requires clean, predictable mapping between design tokens and code.
That alignment doesn't exist naturally. As a team we realized we needed to architect it intentionally *before* Storybook integration begins andnot discover it during implementation.

The difference between a smooth tool integration and a painful translation project is preparation.

System Metrics
  • 200+ design tokens organized and validated
  • 22 components systematically reviewed
  • W3C standards alignment from day one
  • WCAG 2.2 compliance built into validation
Business Value
  • Small team accomplishing enterprise-scale work
  • Higher quality through systematic validation
  • Scalable foundation that doesn't require proportional headcount increase
The Solution
  • Consistent component structure: All button variants follow the same token structure (`--button-[variant]-[property]-[state]`) so implementation patterns are predictable
  • Motion tokens included upfront: Animation specifications are part of the initial export, ready for Storybook documentation slots (solving the earlier motion token gap)
  • Validation happens before handoff: Incomplete components are caught in design before development builds Storybook stories
  • Constant collaboration: We communicate continuously about what the dev team will need, so token decisions are made with implementation in mind
Impact
  • When Storybook integration begins the token structure is already implementation-ready
  • Design decisions already account for dev needs
  • Developer-ready handoffs. The team gets tokens that read like code, not artifacts that need translation

Reflection
A design system's maturity isn't measured by how many components you have. It's measured by how systematically you prevent the problems that slow development later. Motion tokens falling through the cracks? Prevent it by routing around the architectural constraint. States disappearing? Prevent it by validating completeness before handoff. Future tooling causing rework? Prevent it by building the integration path now.

Each of these innovations started as "where will this break?" and became "here's how we prevent it."
Design System
Scalable component library with Atomic Design
Payment Portal
Legacy payment platform redesign
Field Center
Mobile construction plan viewer
Powered by Webflow
FacebookTwitterInstagram