AI-Assisted Design Pipeline: Governed design-to-code workflow for enterprise healthcare modernization
UX Research & Design Strategy Lead
Reducing design handoff time with a governed AI-assisted delivery pipeline.
Leadership set a direction: move to an AI-assisted delivery model. I took on the challenge of figuring out how to make that model work in practice, without losing design quality, human review, or enterprise control.
I built the design kit and component library from scratch, then connected research synthesis, Figma Make prototyping, Figma Code Connect, GitHub Copilot, Storybook validation, and release review into one governed workflow. The VP funded the pilot. It is now in active use on the Lynx platform with Engineering, reducing design-to-handoff time from 12 weeks to 6–8 weeks.
Designed, validated, and shipped in half the time.
By connecting research, design system components, code validation, Storybook review, QA, and engineering handoff into one governed workflow, the delivery model created a faster path to implementation without removing human review from the process.
Per 12-week design lead cycle. Reduced buffer between research and engineering handoff.
Senior Director and VP allocated dedicated engineering capacity outside regular roadmap commitments.
Adopted into the team's active delivery practice, not a one-time prototype.
Active pilot on the Lynx platform. Working directly with Engineering to adapt and refine as the workflow scales.
Without a design system, there is nothing to enforce consistency at the code level. The workflow only worked because the design kit, component library, and delivery model were connected.
The bottleneck was translation between teams and tools.
The existing delivery model required design decisions to be translated across research, mockups, handoff notes, implementation, QA, and release — a 12-week buffer between design and engineering. At the same time, the team needed a design system: a shared component library, enforced naming conventions, and a single source of truth between Figma and code.
I treated the delivery model as an operating system, not a tool experiment. Before scaling anything, I tested the workflow in a sandbox, documented what worked and what failed, and identified where human review had to stay in the process. The key decision was to build the design system and the delivery workflow together so every faster step still had a quality gate.
Both problems had the same fix. I built a Figma design kit and component library from scratch — foundational elements first, additional components added as the work required them. That design kit became the backbone of the workflow: the same kit feeds Figma Make for AI-assisted prototyping, Code Connect for component-to-code mapping, Copilot for implementation validation, and Storybook as the source of truth for the component library.
I worked directly with our Figma account manager and one of their engineers to validate that the approach was technically sound before bringing it to the team. I walked my manager through it; she brought it to the VP. The VP said it addressed exactly what the business had asked for and allocated dedicated engineering capacity outside the regular roadmap to run the pilot.
A governed AI-assisted delivery model requires a design system to enforce consistency at every stage. Building both in parallel, incrementally, meant neither blocked the other.
Built from scratch, incrementally, as the backbone of the workflow.
Before the pilot could work, the design system had to exist. I built the Figma component library from foundational elements up: typography, color tokens, spacing, and core UI components first. Additional components are added as the work requires them, so the system grows alongside delivery rather than ahead of it.
The same design kit connects every stage: Figma Make pulls it in per file to generate prototypes using real components, Code Connect maps those components to their code counterparts, and Copilot validates against Storybook via MCP during implementation. The design system is not a separate workstream — it is what makes the implementation accurate.
Design system foundation
The Lynx AI Design System in Storybook. Each component was validated before broader reuse, including visual states, accessibility checks, and interaction behavior.
Before and after delivery model
The before model had 11 steps and 4 feedback loops, with design decisions re-translated at each stage. The AI-assisted delivery model reduced handoff by connecting research synthesis, Figma, Storybook, VS Code, and QA into one validation path.
Every stage kept a human decision point.
The workflow was designed so AI handled generation and structure. Every direction, validation, and approval decision stayed with the designer or a named stakeholder.
Human-led decisions
Problem definition, direction-setting, concept evaluation, and final approval stayed with me. AI accelerated execution: it generated options, structured code, and flagged inconsistencies. Decisions remained human.
Enterprise constraints maintained
Every tool in the delivery model (Figma, GitHub Copilot, Storybook) was already approved for enterprise use at McKesson. The workflow operated inside existing security and compliance guardrails from day one.
Design-system validation
GitHub Copilot integrates with Storybook via MCP inside VS Code, validating component names, rendering live UI previews, and running tests during implementation. Design system consistency is enforced at the code level, not checked after the fact.
Validated before build
Live prototypes were reviewed by stakeholders and Customer Success before engineering commitment, moving feedback earlier in the cycle rather than after build began.
The tools were the easy part. The mental model was the work.
The hard part was not connecting the tools. It was helping teams understand how design intent, component decisions, validation, and governance carried through the workflow. Each tool has its own logic — Figma Make connects to the design kit per file, Code Connect maps component names not visual properties, Copilot validates against Storybook through MCP — and getting designers and engineers to understand how those stages connect took more time than building any individual stage.
The incremental design system build was the right strategic call. If I had tried to complete the design system before starting the delivery workflow, neither would have shipped. Building both together, with components added as the work required them, meant the team had something usable from day one and could see the system grow alongside real delivery work.
If I were starting this again, I would document the component decision log earlier: which components were built first, why, and what was deferred. That record became valuable as Engineering and I adapted the workflow, but it was informal for too long. On the next modernization surface, that documentation starts on day one.
Engineering leads needed to understand how AI-generated code would be validated in a regulated environment. "Governed and faster" was the argument that moved them. "Faster" alone was not enough.
From a 12-week relay to a connected delivery workflow.
| Before | What Changed | After |
|---|---|---|
| Design ran a full release cycle ahead | Connected workflow | Design-to-handoff reduced to 6–8 weeks |
| Handoff relied on documentation and reinterpretation | Design system as source of truth | Components validated through Storybook |
| QA caught design-development mismatch late | Earlier validation | Design-development gaps surfaced before build |
| AI output was fast but inconsistent | Human-led governance | AI supported production, not decisions |
| Patterns recreated manually per surface | Reusable component foundation | More consistent delivery across workflows |
What This Changed
The team has a single source of truth from Figma through to production for the first time. Design decisions made in the kit carry forward through prototyping, implementation, and validation without being re-translated at each stage. The delivery model reduced the design lead buffer by 6–8 weeks per cycle.
A complete design system built upfront would have taken months and delayed everything. Building incrementally put something usable in the team's hands on day one, and the system has grown with every delivery cycle since. That approach scales to the next modernization surface without starting over.
This pipeline was built alongside the Treatment Readiness modernization effort, where hidden operational work made the delivery model necessary. Treatment Readiness →