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.
Counts on this page were measured in the design system repo at commit fda9e18 on 10 September 2026. Each one is produced by a command rather than recorded by hand, so any of them can be rechecked.
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
A new visual direction was coming to more than 24 communities. Shipping it one handoff at a time was never going to make the deadline.
Nobody asked for it, and nothing like it existed. Doing it the old way was going to land unevenly as well as late, community by community, with the differences showing. So I built the environment first, and then used it to do the work.
My approach
Align tokens, then flip the switch
The numbers had to match production exactly.
A component library on its own would not have closed the gap, and neither would a written process.
I worked with engineering during the Figma phase to line the tokens up 1:1 with the values already in the code: 236 of them, across color, spacing, typography, radius and shadow. Same numbers in Figma, same numbers in the browser. 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 matched to those values already.
The environment carries three of these value sets at once, switchable while it runs: what production uses today, the new direction, and the older member onboarding. They are applied to an element rather than to the page, so two communities can render side by side in their own brands, and a creator’s own colours can be dropped into a single card the same way.
It is not free of exceptions. Six components carry a theme’s own stylesheet, and seven still hold a literal value that no swap reaches. That is the honest version of the claim: a swap plus a handful of parts, not a rebuild of the 67, and a short list of things to go and fix.
Grow components by feature
67 components and 29 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.
- 69 YAML component specs
- Usage rules
- Escalation paths
- data-ds-component and data-ds-variant
- On 54 of 67 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.
Let an agent watch, never write
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
- Which sources it could not reach
- When a search had no date filter
- What it could not check exhaustively
- 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.
- Lint
- 181 source-level tests
- 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.
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, so those screens became the archetypes: every exploration redraws the same set, which is what makes five directions comparable. The first round was fast, and I drew it with Claude, five takes on the brand team’s principles. Bold & Energetic came out of it, and the second round is where the craft went in, on the same 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 toward a set the product could use. That work is still exploration too, like the rounds it sits beside.
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.
So what is below is the two rounds behind that third one, not the finished thing.
The language
| Color | Value | Role | |
|---|---|---|---|
| Periwinkle | #6B64FF | Primary. Buttons, links, the active state | |
| Navy | #182459 | Display type, and the dark ground | |
| Coral | #FF674B | The loud surface, one per screen | |
| Lime | #D2FF66 | Highlight and reaction | |
| Cream | #F1F0CC | The ground everything else sits on | |
| Olive | #B2CE59 | The quieter green, pattern work | |
| Forest | #468E4F | Depth, and community surfaces | |
| Round | Display | Body |
|---|---|---|
| First pass | Ultra | Plus Jakarta Sans |
| Second pass | Fraunces Black | Plus Jakarta Sans |
| Third round | Plus Jakarta Sans | Plus Jakarta Sans |
Both passes paired a display face with Plus Jakarta Sans. The third round sets everything in Jakarta and drops the second family. Neither display face ships, which is why they are here: the craft round is where a direction gets tried at full size and then argued with.
Accessibility
Fifteen of the 67 components had a visible focus style. One rule, in two files, took it to all 67.
| Measure | Before | Now |
|---|---|---|
| Visible focus style | 15 of 67 | 67 of 67 |
| Form primitives that label themselves | 6 of 8 | 8 of 8 |
| Click targets that are not a real control | 1 | 0 |
| Automated checks in CI | None | 8 fixtures, 0 findings |
Keyboard models and ARIA are complete on the components that need them, four of four and 29 of 29, with the other 34 relying on native semantics. The check itself runs without a browser, so contrast and whether a focus ring actually renders are the next stages.
The impact
| Metric | Result |
|---|---|
| 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 | 69 component contracts · 181 source-level tests · CI on every PR and push to main |
The new visual direction is in its 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.