At a Glance
When designs moved from Figma into engineering, speed and quality both slipped. I made the case for prototyping directly in GivingData's production codebase instead, proved it with a pilot, and built the tooling to make the practice repeatable for the team.
Challenges
- Design decisions were getting reinterpreted, and sometimes lost, once they hit code.
- Static prototypes made it hard to get realistic, interactive feedback from users while we could still act on it.
- Any fix couldn't depend on me personally being the bottleneck. It needed to work as a practice the team could run without me in every project.
Role
I chose this as the problem worth solving, ran the pilot, and built the Claude Skills that let the practice keep running without my direct involvement in every project.
Process
- Identify the leverage point: Translating design into code kept slowing us down in two places. Once a design left Figma, engineering spent time rebuilding and re-deciding work we'd already figured out. And the Figma prototypes we used for feedback were slow to build, limited in interactivity, and always a stand-in for the real product. Designing in production code skipped that translation step and addressed both.
- Pilot it: I ran a pilot prototyping directly in production code with Claude Code, coming in 51% under estimate (22 story points against an estimated 44.5, excluding QA).
- Build for scale: I wrote custom Claude Skills that capture GivingData's product patterns and assemble screens from existing design system components. The Skills also handle spinning up prototypes and exporting shareable HTML for stakeholders, so the practice didn't depend on me running it by hand.
- Extend the practice: I applied the same approach to design system QA, including an automated check that runs after Claude finishes a change and compares the work against our design audit rules, like using semantic tokens instead of raw hex or Tailwind values.
Impact
- Delivered a pilot 51% under estimate, giving the team concrete evidence the approach worked before asking anyone to adopt it.
- Nine features have now been prototyped this way. For screen-level work that composes existing components, it's become our default path to an interactive prototype, while exploratory and net-new design still happens upstream.
- Features built this way move through fewer design-engineering feedback cycles, with design intent intact by the time engineering picks up the work.
- Design system QA now runs through the same automation, with strong team adoption and audit rules enforced without anyone needing to remember to trigger them.