Raptive · Design Systems · 2026
Community Design Infrastructure
Building a development environment from scratch in 4 weeks, so design, engineering and product could stop waiting on each other
Zero to one · sole designer and system owner · the work is ongoing
At a glance
What the environment is, in four numbers. The last one is the point of the other three.
Reframing the problem
The design system lived in a Figma file. There was nowhere to see it running.
One designer, 12 to 15 engineers, 2 product managers. Any team that needed a prototype built its own, and everything moved in sequence. Each step lost a little: Figma drifts from what production does, a static file can’t show you what something feels like once you click it, and a new visual direction means rebuilding every screen by hand.
A better Figma file was never going to fix that. What was missing was somewhere the work could actually run.
Framing the opportunity
Nobody asked for this, and nothing like it existed.
What I could see coming was the platform’s next phase: a new visual direction across more than 24 communities. Shipping that one handoff at a time was going to be slower than the deadline allowed, and it was going to land unevenly. So I built the environment first, and then used it to do the work.
My approach
Align tokens, then flip the switch
A component library on its own would not have closed the gap, and neither would a written process. The numbers had to match production exactly.
I worked with engineering during the Figma phase to line the tokens up 1:1 with the values already in the code: 230 of them, across color, spacing, typography, radius and shadow. Same numbers in Figma, same numbers in the browser, and in production before this environment existed. On top of them sits a layer that names what each value is for, so a button asks for action.primary rather than a hex code.
A visual overhaul changes the bottom row, and very little above it. The new Raptive Community language is being built in the system now, matched value for value. It also brings a small set of components of its own, which is the honest version: a swap plus a handful of new parts, not a rebuild of the 63.
Grow components by feature
63 components and 33 patterns, built one feature at a time rather than all at once up front.
The first scope came off a tearsheet. We pulled every component out of the member registration and onboarding screens and built that set, then took the next project the same way, rather than trying to finish a whole library before anyone was allowed to start.
Organised from foundations up through atoms, molecules, organisms and finished prototypes, with governance built into it rather than written down beside it.
- 39 YAML component specs
- Usage rules
- Escalation paths
- data-ds-component and data-ds-variant
- On 49 of 63 components
- data-ds-instance correlates a flow
- Every new variant
- Looked at before it lands
- Publish enforces the standards
- So nobody has to remember them
The review step exists because growth was not tidy. PMs handed prototypes straight to developers so building could start right away, which kept things moving but meant visual decisions got made before I saw them, and a few prototypes used components that were not in the system yet. When those turned up I ported them in and ran a design pass. Governing by review, rather than building everything before anyone was allowed to start, was the trade, and keeping up with that gap was as much of the job as the architecture.
Some of the governance runs without me. I built an agent that watches the whole ecosystem the system lives in.
- GitHub PRs and commits
- Figma components and tokens
- Slack mentions
- Jira and Confluence
- A daily digest
- Risks, conflicts, follow-ups
- Token drift against Figma
- Syncs
- Deploys
- Writes anything unless I ask
Read-only on purpose. It is the same contract I would design for somebody else’s agent, so it seemed right to hold my own to it.
Prototype at fidelity, close the loop
Figma can show you what a screen looks like. It can’t show you what the screen feels like to use.
So the prototypes run on Motion.js and do what a static file cannot: move between routes, respond when pressed, reveal in stages, and fall back to something calmer for anyone who has asked their device to go easy on animation. Design, PM and engineering review the same live page, filled with invented data so it can go in front of the public without exposing anybody’s real information.
- Lint
- 120 tests, 8 files
- Contract check
- Secrets scan
- Build
- Token values
- Component specs
- Git SHA
- Jira ticket status
- GitHub history
- From scrubbed local caches
Engineering then released coding agents that translate a prototype straight into the production codebase. What used to be a relay became a loop.
- I design
- I hand over
- I wait
- I see what came back
The line ends. Whatever was lost on the way is found later, or not at all.
- I update the design
- Agents translate it into production
- Figma captures it for comments
- Comments become the next revision
The line closes. Refining and building happen at the same time instead of taking turns.
Production was a different technical world. Raptive Community runs on Discourse, built on Ember, a framework old enough that it was never meant to hold one central component library. That is why the tokens mattered: they were the one layer that could exist in both places at once. A staff engineer built the migration agents that carried the system into Ember production, and a software engineer used the same tokens for a React Native system on mobile. Before any of that, I rewrote the animation system down to plain CSS transitions, because Motion.js was going to cost more in Ember than Ember could pay.
Then the hardest process argument we had: which surface is the source of truth, Figma or the live environment? I argued against my own thing. Figma won, because it is where the whole team already works.
- Review
- Comments
- Sign-off
- The record of what was agreed
It won because it is where the whole team already works.
- Motion
- Micro-interactions
- Final polish
- Anything you have to click to judge
The things Figma has no way to express.
The polish could also keep moving after the handover. Animation and interaction are decided by watching the thing run, so in a relay they have to be finished before anything moves. Here they held nobody up: engineering kept re-importing as I landed final designs.
Pilot on real product
Member onboarding was the first real surface to go through all of it.
New interaction patterns, trust architecture, art direction and motion. Registration, auth and onboarding are what production runs today, and those screens became the archetypes: every exploration redraws the same set, which is the only thing that makes five directions comparable. The first round was fast, and I drew it with Claude: five takes on the brand team’s principles, energetic, genuine, inclusive, optimistic, vibrant and joyful, made to find which way to go rather than to be built. Bold & Energetic came out of it, and the second round is where the craft went in, on the same archetype screens again, as two versions. A third is being built in the system now and is the one that will ship. Nothing from any of the three is live yet.
The brand team had explorations of their own running alongside. I took those further, scaling the patterns and objects into a set the product could actually use.
It became the go-to-market pilot and carried the first structured usability testing the platform has run, in Useberry against the public prototype. Without a surface attached, this is an internal tool engineers like. With one, it is tied to pageviews and DAU.
A third round is being built in the system now and is the one that will ship, so what is below is the two rounds behind it, not the finished thing.
The impact
| Metric | Result |
|---|---|
| Time to build | First commit to a system governed in CI: 25 days, solo |
| Scale | 230 token values · 63 components · 33 patterns · 21 prototype records · 37,409 lines of source |
| Handoff | Sequential handoff to continuous loop |
| Design debt | Full rebuild reduced to a token swap and a handful of new components |
| Design to production | Agents translate prototypes into the production codebase |
| Quality gates | 39 component contracts · 120 tests · CI on every PR and push to main |
The new visual direction is being built in the system now, in a third and final round. It ships when design and engineering agree it is ready, and that will be a token swap and a few new components rather than a rebuild.
Engineers could measure effort and impact because they could watch it run. I could polish the motion for the same reason.