Design System Transformation
ConstructConnect | Design System | Components | AI-Assisted Quality Assurance | Developer Collaboration
Figma | Claude Code | Claude AI | Storybook | GitHub
Blueprint is the foundation other products and platforms build on; its first phase cut design-to-development effort by 64%. It's since grown into a working partnership with engineering. Each team's designer brings me a requested component, I finalize its tokens and variables in Figma, then use Claude Code to bring it into a local Storybook and confirm it looks and behaves as intended. I write implementation tickets in a format built with the developers, and audit components against the spec so gaps are caught before development. AI speeds up nearly every step, but a person reviews every token, spec, and ticket — a mistake in the foundation doesn't stay in one place.
What We Built:
Set up a token extraction workflow using Figma plugins to export design variables, then validated the flow against our Tech Lead's implementation template using Claude AI. When the first batch revealed missing focus and motion tokens, I investigated the architectural gap: Figma's variable system doesn't support motion/animation assignment at the component level, and the MCP integration wasn't successfully pulling motion specifications.
I solved this by creating a dedicated motion variables file that VS Code can pull from when assembling the complete token set for developers—working around Figma's architectural limitation. I formalized this workflow as our process, built an automated state validation system preventing incomplete handoffs, and structured the tokens 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 handoff and documented in the Jira tickets to help prevent incomplete specifications from reaching development.
- 20+ components audited against the spec, with accessibility, structural, and token alignment gaps turned into tracked fixes for the development team.
Motion Token Extraction: Solving an Architectural Constraint
When our Tech Lead reviewed our component specifications, she asked if the motion tokens that were 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. Additionally, the MCP integration wasn't successfully pulling motion specifications from component definitions.
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: I still create the motion variables in the file, and use a plugin to extract those defined variables separately. While I cannot attach the motion tokens to the interaction of a component, they are now recorded in both Figma and the extracted tokens.
- Designed a workaround: Instead of relying on plugin-mediated extraction (which stops at the variable boundary), route extraction through using the similar plugin, but I create a motion tokens file that VS Code using CoPilot with Claude Sonnet agents merge together with the final tokens file. This has been the most reliable way to get the tokens correct.
- Integrated with existing workflow:
1. Share Figma link, extract the motion variables
2. VS Code/CoPilot with Claude Sonnet Agent merge the extracted tokens with the motion ones.
3. Match against our developer's template
4. Format for implementation
- Mostly 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
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 our development team 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 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 and not discover it during implementation.
The difference between a smooth tool integration and a painful translation project is preparation.
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
- 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."
