The end of trading quality for speed
From the start of a project to the end, there are always little hiccups that prolong the process: a missed requirement in the tickets, an edge case surfaced mid-build, an interaction or layout a developer just can't nail down. Every one of these costs time and money to fix. The result: things ship without the polish they deserve.
Place your concept problem area into Claude
Examine existing codebase and site maps to find edge cases and paths for the build
Refine and expand upon project requirements and tickets
Design builds out the experience and components on a local branch
Design reviews and QAs the build
Design makes changes and polishes the UI
A fully working build or component is handed off to development
Engineering and QA polish and release the code!
Use the production-ready PR as a feedback loop on what to fix for next time
From single-page answers to shipping features
I connected Claude to our codebase to answer questions about a single page. Claude kept missing connected areas, so I had it build site maps of the client and stylist products, scraping our support docs for context. I used those maps to find edge cases, write PRDs, and create funnels in LogRocket to understand behavior. Designs improved, but builds still lagged. I started prototyping with real components which was good for showing intent, but useless as code.
I then took the workflow to our lead engineer and got set up to build on local branches against staging. The Figma MCP landed around then, and I adopted it immediately. First design PRs got about 60% of the way there; every round of engineer feedback fed back into skills until we hit ~90%.
As features shipped faster, QA became the bottleneck. I presented the process to engineering managers, then at our all hands. QA leadership scoped it and cleared visual-only changes to verify through Chromatic. Last step: handing the skills off to other designers, engineers, and PMs.
Saving engineering, product, and design time at every step of the process
Catching edge cases before design starts
Claude scrapes the codebase into site maps of the client and stylist products: page mappings, the content on each page, tracking events, and the file locations for every element plus the related areas it touches. The support docs go in the same way, which supplies our acronyms, feature names, pricing plans, and policies. Edge cases surface while the design is still cheap to change.
Writing ticket requirements with nothing left out
The map feeds the PRD: every state the design has to cover, every conditional driven by a stylist's settings, and the connected areas a change will ripple into. Engineers get the areas they need to investigate up front, making pointing easier.
Wireframing and brainstorming with real product insights
Concept directions and workflows get generated against how the product actually behaves, then built and refined in Figma. Funnels in LogRocket show how people move through the current experience, which got a lot faster once the LogRocket MCP shipped.
Coding and QAing designs with real components in staging
The build runs on a local branch with the backend pointed at staging, so the feature sits in context with the real app: real data, real navigation around it.
Small features and layout updates go straight to Claude with no design context, then get QAd in the running app.
Anything new or mid-sized starts from the Figma file through the Figma MCP, along with the PRD. Any new components the feature needs get built and QAd in isolation in Storybook first. Once those are right, they go into the real experience on the branch, then visual QA at every breakpoint until it is pixel perfect against the design.
Throughout, the engineer assigned to the ticket sees exactly what is intended and running, before it becomes a review request.
Handing off at about 90% complete as a PR
What used to be a Figma file and a hand-off is now a pull request: pixel perfect, roughly 90% done. That number started at 60%. The assigned engineer reviews it, fixes whatever is left, and takes it through to release. Nothing reaches production without an engineer's eyes on it.
Building and crafting skills with a feedback loop
The jump from 60 to 90 did not come from better prompting. Early on, Claude got small things wrong: syntax, the rules for building components and page layouts, logic rewritten that already existed. Those corrections went into StyleSeat development skills instead of being fixed by hand each time, with the engineers refining them from there. After every release, whatever they changed in the PR gets read and folded back into the skill. Every ship makes the next one start closer to done. That loop is the asset.
