CASE STUDY 002 · S&P DESIGN SYSTEM
Six products, no shared parts.
GoGuardian ships six K-12 products, and each one had been designed on its own and had its own distinct look and feel. I made the case for a shared design system, built it, and got four product teams onto it without slowing down the roadmap.
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.
When I joined GoGuardian, each product had been built in its own silo for years. Customers and internal stakeholders all complained about how each product felt like it was built by a different company. Moreover, each design team was rebuilding the same button three different ways, engineering teams were shipping conflicting patterns, and QA was catching inconsistencies that should never have existed.
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. No one was asking for a design system yet—the teams were too deep in their own work to see how much they were duplicating.
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.
Before I could make the case for a system, I needed to understand the full scope of the problem. I ran cross-functional audit sessions across each product, cataloguing UI patterns, mapping both consistencies and inconsistencies. I brought IC engineers from each team into the room from day one—not to convince them later, but because they needed to see the technical debt alongside the design fragmentation. A lot of them were comparing products side by side for the first time.
The themes clustered together faster than I expected: governance and a single source of truth, brand cohesion, tech debt, and the resource constraints everyone was worried about. The resource constraint was the one that shaped my entire proposal. It told me that engineering leadership would never fund a big-bang rewrite, and that adoption had to cost teams almost nothing.
THE DECISIONS
My synthesis led me to follow a slow and steady approach
My synthesis led me to follow a slow and steady approach. While it was tempting to start from a clean-slate, I argued against it because shipping a brand new finished library and asking six teams to swap everything at once would have majorly disrupted active roadmaps and slowed releases down. The IC engineers who’d been in the audit with me already saw the problem—the challenge was getting engineering leadership on board.
Instead I set four guiding principles: consistency so teams shared one source of truth, scalability so a seventh product could adopt the system, adoptability so that the built system didn’t diverge radically from the current visual language, and low-friction integration so that adopting the system didn’t feel like a tax on a team’s velocity. The last one was the constraint that actually mattered. With roadmaps that couldn’t pause, anything teams couldn’t adopt between sprints wasn’t going to get adopted at all.
EXECUTION
Build incrementally, slotted into an existing roadmap.
I sequenced the work so teams could adopt one layer at a time: primitives (color, spacing, type), components (buttons, inputs, modals, etc.), and patterns (side navigation, top navigation, etc.).
I partnered with each product’s tech leads on what to build first, ran working sessions to align on designs and test them in context, and provided design QA to ensure the Figma-to-code gap didn’t reintroduce inconsistency.
“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 comes from post-rollout retros. Front End Engineering teams reported building new features in roughly half the time.
Four legacy products—Admin, Teacher, Beacon, and Org Management—adopted shared primitives in the first phase, which ended the parallel component maintenance that had been running across teams. Two new products—Hall Pass and Discover—were built on the system from day one, proving the system worked at scale without forcing an adoption curve. The library became the reference for design QA, moving inconsistency-catching from after ship to before 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
Partner with a passionate senior level engineer as soon as possible
I started this process alone which made it feel like this was my project to own. I had to convince others to join me on this path. If instead, I had found a senior engineer to partner on this from the get go, it would have been easier to influence the technical arm of the org and come up with a technical approach that would work with our current tech stack.
WHAT I'D KEEP
Adoptability as the constraint, not a nice-to-have.
Making low-friction adoption the priority is the call that got our Eng teams on board. What I'd add next time is measuring usage and time-to-implementation for new patterns from day one. I tracked adoption informally, but the hard metrics would have made the case for continued investment effortless.
NEXT CASE STUDY — 003
A retirement dashboard that worked against its users.