0
Annotation hours
Manual spec annotation eliminated. The platform is the handoff — no PDFs to export, no Sketch links to maintain.
01 · AI + Design Systems
AI-Assisted Design
Documentation Platform
The gap between design intent and shipped product cost weeks of back-and-forth on every component. I built a living documentation platform to close it — replacing PDFs and Sketch links with a single URL.
01
The Problem
No shared source of truth
Every component handoff followed the same script: send a PDF export, a link to a Sketch library, and a Radar ticket written for an engineer who hadn’t sat in the design review. Nobody could run the spec. Nobody could resize it to test mobile. And by the time engineering asked the first follow-up question, the Sketch file had already changed.
The result was a fragmented documentation landscape. Each artifact lived in a different place, maintained by a different person, at a different level of freshness. Web developers discovered edge cases the PDF never addressed. Engineers had to interpret static annotations instead of inspecting working code. Designers spent time answering questions that a running prototype would have answered automatically.
“Specs felt like a wishlist.”
The fix wasn’t better annotations or more detailed tickets. It was a different format entirely — one that could run in a browser, adapt to dark mode, and answer follow-up questions before anyone had to ask them.
PDFs, Sketch links, and tickets — three artifacts, three owners, three versions
02
The Approach
A platform architecture, not a document template
The platform had to serve three audiences simultaneously: designers who needed high-level specs, engineers who needed complete handoff details, and web developers who needed something they could open in devtools and replicate directly into the CMS. A single static format couldn’t serve all three. The platform had to adapt.
How prototypes are generated
Sketch
File
File
Claude
API
API
HTML / CSS
/ JS Output
/ JS Output
GitHub
PR Review
PR Review
Published
Article
Article
Structured for 40+ components at scale
The platform organized everything into five top-level categories: Design Tokens, Components, UX Specifications, Accessibility, and Resources. Each category had its own section in a persistent collapsible sidebar — navigating between components never required a trip back to the homepage.
Within each article, a floating table of contents gave engineers and developers quick access to specific sections — Overview, Interactive Prototype, Anatomy, Variants, Breakpoints — without scrolling through content that wasn’t relevant to their task.
Prototypes that run inside the documentation
Every component article embeds a working HTML/CSS/JS prototype. Not a screenshot. Not an animation. A real interactive element that responds to clicks, keyboard input, and screen resizes — built from the same code that goes into production.
The pipeline generates each prototype from a structured prompt: component name, intended states, token references, and responsive requirements fed into the Claude API. The output goes through GitHub PR review before being embedded into the article. Key insight: explicit output constraints outperform descriptions. “Produce a component using CSS custom properties for all color values, with focus and hover states, keyboard accessible” outperforms “make a nice button.”
One article, two audiences
A single component article serves two different readers. Essentials mode shows the high-level summary: version, date, designer, Sketch file link, and PDF references. Engineers and web developers who need the full picture switch to Full Spec for complete anatomy, all interaction states, responsive breakpoints, and implementation notes.
The toggle means the same source of truth serves designers in a standup and developers in a sprint. No separate document to maintain. No version to keep in sync. The audience changes; the platform adapts. If a component generated questions during review, the feedback folded back into the article — one update, visible to everyone.
03
The Solution
A URL, not a PDF
The output of every pipeline run was a page — not a file to email, not a Sketch artboard to share, but a real URL that anyone on the team could open in any browser. Designers could walk management through a component without needing Sketch installed. Engineers could open the prototype in devtools and inspect the actual CSS. Web developers could replicate the HTML structure directly into the CMS.
Dark mode was designed into the platform at the data level, not just the surface level. The color reference tables don’t just invert — they display the actual dark mode token values, because the hex codes themselves change between themes. Every engineer looking at those tables gets the right value for the mode they’re implementing.
Three fragments (PDF + Sketch + Radar ticket) become two: one Radar ticket + one shared URL
Color token values change between themes — the table reflects the correct hex for each mode
04
The Impact
The spec bottleneck, eliminated
A living documentation platform. Interactive prototypes embedded in every component article. Shared across design, engineering, web development, and management. No translation layer.
3×
Faster review
Engineering sprint review time dropped significantly — inspecting a running prototype is unambiguous.
40+
Components documented
Across design tokens, components, and UX specifications — keyboard-accessible, token-driven, and responsive.
1
Source of truth
A single URL that designers, engineers, web developers, and management all referenced — no version confusion, no stale PDFs.
What changed for each audience
Designers stopped fielding clarifying questions — the prototype answered them. Engineers stopped interpreting static specs — they inspected real code. Web developers stopped replicating guesswork — they replicated working HTML. Management stopped asking to see Sketch files — they opened a URL.
The deeper shift: when documentation runs in a browser, the question changes from “did the designer spec this right?” to “does this behave the way we intended?” That’s a much more useful conversation — and one that AI-assisted documentation makes possible without adding overhead to the design process.
Case study 02
HR Platform IA & Navigation System →