Heather S. Neff

Most design systems die the same way: the design says one thing, the code says another, and a few months in nobody knows which one is right. On a project I’m building for a fintech company, the design system lives inside the site itself, as a private route rendered from the exact components that ship to production. Their design team is very skilled at keeping their design system in Figma clean and up to date, and now the codebase keeps up with it. They’ve been loving it so far. There’s no drift between design and code, because each component only exists once, and they can see what went into the site and how it was built. It’s quickly become their bible. Right now it covers 54 components, 48 page builder sections, 86 tokens and 59 icons, each with its own page. → Colour, type, motion curves and icons are read straight from the source files, so a new token shows up without anyone touching the docs → Every section renders alone in a frame with a real viewport, where breakpoints and scroll-driven motion behave exactly like on the live page → One toolbar switches light and dark, reduced motion, and widths from 375 to 1440 → The thumbnails editors pick from in the CMS are snapshots of these same pages, so they always match the real section It also can’t fall behind. Every story is type-checked against its component’s props, and the test suite fails when a component ships without one, so a UI change and its design system page always land in the same commit. Agents get a lot out of it too. When one builds or changes something, it gets pointed to the design system and sees how everything looks in one place, instead of scanning the entire codebase every time. They shine when they have a solid system to work from, and this keeps their drift to a minimum as well. Now it’s part of every site I build, and I’m thinking about packaging the whole setup as an agent skill so an agent can scaffold it on any project. Would you use it? 👀 The shots are kept generic on purpose for now, more coming soon.