Parent DS architecture · base library · 3 of 4 child libraries shipped solo · onboarding + governance walk-through for the rest of the team.
Principal Designer + product leads on call-based governance (no RFC). Consumed by 5 designers across 4 products.
A thin, undocumented now.gg system met a second product with a different feel; it couldn't serve both without compromising the brand or forking.
A thin, undocumented design system existed for the now.gg website. As nowStudio came online in parallel — light theme, B2B-dev-aimed, totally different feel — the existing DS couldn't serve both without one of them compromising the brand or forking the system entirely.
Lock down color, typography, spacing, radius, elevation and the icon set in one shared library. Everything downstream inherits from this.
Three atoms only — button, input field, input box — with extensive variants. Resist promoting organisms into the parent until a second product needs them.
Each product gets a child DS that inherits the parent and overlays its own organisms, patterns, and typography mood without forking.
In-Figma anatomy docs, internal workshops, and lead-designer feedback rounds — so other designers can spin up child DSes themselves.
One parent library owns the brand layer; four children inherit it and overlay their own personality, with governance settled on a call, not in a doc.
Float doesn't try to be everything. It owns the brand layer — the bits that must be consistent across products. The children own their personality — the bits that should change because the audience changes.
There was no governance document. A component got pushed into base when the principal designer and the lead designers on the other now.gg products agreed it should live there — a short call, an agreement, a merge. That was the whole process.
It worked because the group was small: five designers who already talked daily. Trust + proximity did the work an RFC template would have done in a bigger org — and it would not scale much beyond that. I'm not pitching this as a method; I'm describing what actually held the system together.
Tokens before native Variables, an icon library drawn on demand, and anatomy docs living inside Figma — the three things the bet needed.
Three things had to be true for the parent/child bet to work: one source of truth for design + dev, an icon library that scaled across products, and documentation that lived where designers already were.
Tokens did exactly what tokens are meant to do — kill raw hex / px values, give engineering one named contract to read against. The interesting part is how they got there in two phases, before and after the platform caught up.
Months before Figma shipped native Variables, I built color, type, spacing, radius, and elevation tokens through a community plugin. Components were bound to plugin-managed token names — not raw values. The discipline was in place before the platform supported it.
When native Variables shipped, the team moved every plugin token onto the new system. The migration itself was an order of magnitude smaller than it would have been from raw values — every component already pointed at a named token, so the swap was largely a re-binding job, not a re-design one.
Icons were drawn project-by-project as features needed them — not a 500-icon dump. The result was a shared library every child DS pulled from, sized and stroke-matched to the brand, without a third-party set fighting the typography.
Every base atom got an anatomy frame next to the component itself: numbered callouts, token references, light + dark variants side by side. One artifact served both designers (how to use it) and engineering (what tokens to bind to). No external doc site to keep in sync, no second source to rot.
Studio is the one real outlier; Website, Player and Gameroom share the gaming line, and Gameroom swaps whole themes by token alone.
01 / 04A gamer browsing now.gg and a game dev in nowStudio shouldn't see the same product. The architecture's job was to let those two brand expressions live without one of them compromising — and without forking the system to do it.
Studio is the genuine outlier — different audience, different typeface, different mood. Website, Player, and Gameroom share the gaming-brand flavor (dark, fun typeface) and inherit it from the same parent. Gameroom adds the strongest technical proof: multiple themes via tokens — same components, swap the palette.
Split parent from child with one product live, tokenise before the platform made it easy, and govern by call while the team stayed small.
Three calls held the architecture up — one structural, one disciplinary, one social. None of them had a clean killed alternative actively on the table at the time; they read like trade-offs in retrospect, but the day-of, they were just the choices that felt right. I'm flagging that upfront so the framing stays honest.
The why. The temptation with one product is to build a monolithic DS and split it later when the second product comes online. The split never goes well later — by then, the first product's components have absorbed assumptions that don't generalise.
Cementing the parent layer first — color, type, spacing, atoms — and treating Studio as the first child meant Website, Player, and Gameroom dropped in without a refactor. Gameroom went from 0 → designable in ~2 days on the inherited foundation.
The why. Discipline is a design decision, not a tool decision. Waiting for native Variables would have meant 6+ months of components bound to raw values — every one of which would need to be re-bound by hand later.
The plugin tokens carried that discipline forward: by the time Variables shipped, every component already pointed at a named token. The migration was a re-binding job, not a re-design one — an order of magnitude smaller than starting cold.
The why. The Float team is small: ~5 designers, each individually leading design on a different now.gg product. We talk daily — and that daily contact is the substrate the governance runs on. A component got pushed into base when the principal designer and the leads on the other products agreed on a call. That was the whole process.
An RFC template would have added friction without buying any quality the call wasn't already delivering. Trust + proximity did the work formal governance does in bigger orgs.
Honest caveat. This works for us at our size. Past ~15 designers — or the day individual product leads stop talking weekly — the call falls over and a written process becomes the only option. I'd make this same call tomorrow at our scale; I wouldn't prescribe it to a bigger team.
Consumed by 5 designers across 4 products; 3 of 4 children shipped solo, the fourth built by a teammate; Gameroom designed in two days.
Pseudo-titled “Design System Officer” by my Principal Designer in recognition of the Float work.
A new product surface that would normally take weeks to scaffold visually now lands in days — Gameroom proved this with a 2-day foundation phase. New designers onboard against a single library instead of a stack of inconsistent files.
The best design system is the one the team actually uses.
— pinned in the Float file
Three workshops existed to remove me from future decisions; the inheritance model outlived the file, carrying into BluePrint and Apparatus.
Designing a system isn't shipping it — adoption is. Three formal workshops + lead-designer feedback rounds gating every child DS launch. The proof it worked: one of the four children — Player — was built by another designer using the walkthrough, not by me.
On the title: my Principal Designer / Design Manager pseudo-titled me “Design System Officer” in recognition of the work. Not an HR title change — an internal acknowledgement. I'm calling it what it was.
Tokens so the team could add a new one without breaking anything. Documentation so every new component shipped with its anatomy frame. Child-DS creation so other designers could build the next product's system without me in the room. That's the leadership move — not running the workshops, but designing them to be unnecessary later.
What tokens are, why they matter.
Pre-Variables, tokens were a foreign concept to most of the team. Hands-on session covering primitives, semantic aliases, and plugin tooling — everyone left able to add a token without breaking the system.
The anatomy frame as standard.
Walked the team through the in-Figma anatomy doc pattern: numbered callouts, token references, dual variants. From then on, every new component shipped with its anatomy frame as part of the definition of done.
So others could build the next ones.
The walkthrough that mattered most. After this session, another designer built Float Player following the model — with lead-designer feedback rounds gating each launch. The architect-to-evangelist arc earned the pseudo-DSO title.
The same parent/child inheritance idea carried into systems that came after — each rebuilt against what the tools, the team, and the industry could express by then. A few stand out for what they proved the model could do.
Native Figma Variables from day one. Two themes — Windows + macOS — handled through the same token tree. Same inheritance idea, now branching on platform instead of brand.
The AI-native one. Tokens, components, and anatomy structured so an LLM can read the system — not just designers and engineers. The audience expanded again: agents joined the team.
In 2023 the bet was that brand pluralism didn't need forking — that one parent/child model could host genuinely different products on shared primitives. Float made the bet work. BluePrint and Apparatus made the model portable — across orgs, across surfaces, and across a tooling shift I didn't see coming. The DS file has a shelf life. The inheritance model doesn't.