CASE STUDY 002 · S&P DESIGN SYSTEM
Six products, no shared parts.
GoGuardian ships six K–12 products, and every one had been designed on its own. A shared design system wasn't on anyone's roadmap. I made the case for it, built it, and got four product teams onto it without asking a single one of them to pause a release. The hard part was never the components — it was the org.
OUTCOME — engineers report ~50% faster feature builds
- Lead Product Designer
- Me · 1 PM · 4 tech leads
- Fall 2024
- 6 products, 1 system
- Audit · system · rollout
THE PROBLEM
It wasn't an aesthetic problem. It was an org one.
By the time I joined as Lead Product Designer, the six products had been built in their own corners for years. The thing people noticed first was that they didn’t match. The thing that actually cost money was underneath: designers were rebuilding the same button three different ways, engineers were shipping conflicting patterns, and QA was catching inconsistencies that should never have made it that far.
The products looking different was a symptom. The real problem was that six teams had no shared foundation to build on, and nothing to catch divergence before it compounded. A system wasn’t on the roadmap when I got there — I put it there, then had to prove it was worth the room it took up.
WHAT FRAGMENTATION WAS QUIETLY COSTING
- 01
Designers rebuilding near-identical components, unaware of each other's work.
- 02
Buttons, fields, modals, and nav with 3–5 competing implementations each.
- 03
No shared color or spacing tokens — values hardcoded, inconsistent everywhere.
WHERE I STARTED
I audited all six products before proposing anything.
I didn’t want to walk into leadership with a hunch, so I ran cross-functional audit sessions across every product — cataloging UI patterns, mapping where they overlapped, and marking every point they’d drifted apart. Designers and engineers were in the room together, a lot of them comparing their work side by side for the first time.
The themes clustered faster than I expected: governance and a single source of truth, brand cohesion, tech debt, and the resource constraints everyone was quietly worried about. That last cluster is the one I kept. It told me a big-bang rewrite would get killed on contact, and that adoption had to cost teams almost nothing.
THE DECISIONS
I rejected the rewrite before anyone could ask for one.
The tempting move was a clean-slate system and a coordinated migration. I argued against it. Shipping a finished library and asking four teams to swap everything at once would have stalled active roadmaps and turned the system into the thing that slowed releases down — the fastest way to get it cancelled.
Instead I set three goals to settle every later argument: consistency so teams shared one source of truth, scalability so a seventh product wouldn’t mean a rebuild, and adoptability as the one that actually constrained the design. With engineering bandwidth tight and roadmaps that couldn’t pause, anything teams couldn’t adopt between sprints wasn’t going to get adopted at all.
EXECUTION
Built in layers, slotted into a roadmap that never stopped.
I sequenced the work so teams could adopt one layer at a time: primitives first — color, spacing, type — then the highest-duplication components like buttons, inputs, and modals, then the composition patterns that needed those pieces working together, then documentation and engineering handoff. Foundations landed in Q1; components folded into feature work already slated for the back-to-school release and beyond.
I partnered with the four tech leads on what to build first, ran working sessions to pressure-test component APIs against real product needs, and stayed in the handoff so the Figma-to-code gap didn’t quietly reintroduce the inconsistency we’d just spent months removing.
Threading the work into live roadmaps instead of running it alongside them is the decision I’d defend hardest. It meant the system never showed up as a tax on a team’s velocity — it showed up inside features they were already shipping. That’s most of why four teams said yes.
Multiply that by six products and you have the maintenance bill the system was built to retire.
“Jules defines complex problems with clarity and strong boundaries. His research rigor consistently leads to elegant solutions that materially improve the products he works on.”
WHAT HAPPENED
Four teams adopted it without pausing a release.
The 50% number came out of post-rollout retros, not a model — engineers across teams reported building new features in roughly half the time once they were pulling from shared primitives instead of rebuilding them. That’s the kind of claim I’d normally hedge; here it came straight from the people doing the work.
Admin, Teacher, Beacon, and Hall Pass all adopted shared primitives in the first phase, which ended the parallel component maintenance that had been running across teams that never talked. Discover and Org Management launched on the system instead of starting from zero — the first GoGuardian products to do so. And the library became the reference for design QA, which moved inconsistency-catching from after ship to before it. I led the system; the adoption was four teams choosing to trust it.
~50%
faster feature builds reported by engineering teams in post-rollout retros.
4
active product teams on shared primitives in the first rollout phase, with zero paused releases.
6
products now drawing from one source of truth — two of them launched on it from day one.
THE SUITE, AFTER /
WHAT I'D KEEP, WHAT I'D CHANGE
Two things this one taught me.
WHAT I'D CHANGE
Bring engineering in during the audit, not after.
I started the cross-functional alignment once the primitive layer was already defined. Looping engineering in during the audit would have surfaced implementation constraints earlier — specifically around token naming and component API structure — and saved a round of revision. I treat the audit as a shared room now, not a designer's homework I bring back to the team.
WHAT I'D KEEP
Adoptability as the constraint, not a nice-to-have.
Making low-friction adoption the goal that overrode the others is the call that got four teams on board. What I'd add next time is measuring it on purpose — component usage by team, time-to-implementation for new patterns — from day one. I tracked adoption informally and it worked, but hard numbers would have made the case for continued investment without me in the room to make it.
NEXT CASE STUDY — 003
A retirement dashboard that worked against its users.