Design Orchestrator — a shared pipeline for turning Figma into working prototypes
Org-level AI tooling — Procore design system, composed once
- The problem
- Every designer was re-explaining Procore's component library and brief format to their agent, from scratch, in their own prompt
- My role
- Author and maintainer — the orchestrating pipeline plus the design-system knowledge it composes
- Status
- Trial — in active use on real prototypes across the design org
- Built for
- Any designer, PM, or engineer pointing an AI agent at a Figma file
Background
Overview
Once AI coding tools got good enough to turn a Figma file into a rough prototype, everyone on the design team started trying it — and everyone hit the same wall. The agent had no idea what Procore's component library actually looked like, so it invented its own buttons, its own spacing, its own version of a data table. The output looked like a prototype but wasn't built from anything we could ship or review against.
The fix wasn't a better prompt. It was building a shared pipeline that encodes what "Procore's design system" actually means — components, tokens, patterns, guidelines — once, and composes it automatically whenever someone needs a prototype, instead of leaving every designer to reconstruct that context from memory.
How it works
Four personas, one pipeline
Design Analyst
Reads the input — a Figma file, a screenshot, a sketch, or plain text — and maps every element to a real component, flagging anything that has no match.
Prototype Engineer
Generates the actual HTML or React output using the mapped components, with a manifest documenting which component and library each element came from.
Design Reviewer
Checks the generated prototype against the design system — right component, right props, no hardcoded tokens, no deprecated patterns — before anyone sees it.
Accessibility Auditor
Runs a WCAG 2.1 AA pass — contrast, keyboard navigation, semantic structure — so accessibility isn't a separate step someone has to remember to run.
What it composes
Built on Procore's existing systems, not around them
- 01
The core-react component catalog
A full inventory of Procore's design-system components, their props, and their intended usage — so the pipeline reaches for a real component instead of improvising one.
- 02
Data-table and formulator patterns
Composition patterns for the more complex, data-heavy surfaces that a generic component catalog alone doesn't explain well.
- 03
Design guideline references
A cached copy of Procore's design principles and usage guidance, so the review step has something concrete to check against.
- 04
Four pipeline variants
Reference, Sketch, Blueprint, and Ideate — matched to how complex the request is, from a single component lookup to a multi-screen prototype built jointly with a PM.
What's actually in it
At a glance
Design Analyst, Prototype Engineer, Design Reviewer, and Accessibility Auditor — each with a defined handoff to the next.
Reference, Sketch, Blueprint, and Ideate, selected based on how complex the prototype request is.
The composed core-react catalog the pipeline maps every design element against before generating anything.
Non-negotiables — like "always use design tokens" and "never skip the accessibility audit" — built into the pipeline itself, not left to the person running it.
Why this is infrastructure, not a personal script
The point was never to make myself faster at prototyping — plenty of individual tools already do that. The point was building something another designer could point at their own Figma file on day one, without first learning what I already know about our component library. That's the difference between a personal speed-up and something a whole org can actually adopt.
