From Components to Practice

Overview

This case study picks up after the work shown in Sparkline Design System. Once Sparkline had shipped and proven itself in production, the focus shifted from building the system to building the team and rhythm behind it: the structure, cadence, and governance needed to run it as a scalable practice rather than a single project. The Design System team had strong technical capability already; what it needed was the operational infrastructure to match it and carry that work across the rest of the organization. My work spanned agile transformation, roadmap authoring, workflow design, governance documentation, and platform restructuring.

Two halves of a system.

A great design system is really two systems: the components and tokens that ship in code, and the operating layer that lets the rest of the organization run on them. Building that second half was the next necessary step: the workflow, documentation, and governance that would make the system more accessible, more predictable, and more embedded in how the organization ships product.

A North Star for the practice.

My first move was to listen. Conversations with people on the Design System team and across the product organization surfaced a shared desire for more clarity: where the system was headed, how mature it needed to become, and how individual work connected to a bigger picture. I used those findings to author a 5-Stage Design System Ops Roadmap.

The framework gave the team a strategic foundation to operate from. Each stage builds on the last, progressing from structural alignment and operational visibility through cross-team collaboration and tooling evolution to full enterprise integration. It also gave leadership a clear lens for prioritization and a way to track maturity over time.

First, stabilize the operation.

Before any long-term strategy could land, the team needed a working foundation. Phase 1 was about triage: getting the most urgent structural needs in place so the team could operate predictably. That meant introducing a delivery framework, establishing core ceremonies, and standing up Jira as the team's system of record for planning and tracking.

I introduced an "Agile light" framework, structured enough to create consistency, flexible enough to let complex design system work carry across sprints when it genuinely needed to. From there, I defined five core ceremonies, each with a clear purpose, cadence, and set of outputs.

End-to-end workflow in Jira.

Alongside the ceremonies, I designed the team's complete start-to-finish workflow in Jira. The system tracks not just whether work is done, but what kind of work it is and where it sits in its own lifecycle. Work moves through three sequential tracks after a shared intake and refinement phase: Design, then Develop, then Documentation. Each track follows the same four statuses so anyone on the team or in the broader organization can see exactly where a feature stands at any point.

Building the rules of the road.

The largest barrier to enterprise adoption was the absence of documentation around how to work with the system. I collaborated closely with the Design System team to author governance across five foundational pillars, giving every role in the organization a clear understanding of how to engage with the system, what they own, and what falls outside their lane.

One place for governance to live.

Once the governance pillars were defined, they needed a home that the whole organization could actually find and trust. I chose Storybook as that home, since it already let people see every component and its documentation in one place. Extending it to house governance alongside components meant anyone, whether a designer, engineer, or partner team, could go to a single, familiar source to see the rules, the components, and any other resources we wanted to share.

I mapped the site into four top-level sections so each kind of content had an obvious place to live: Design System Governance for the governance pillars themselves, Foundations and Components for the existing token and component documentation, and Resources for the supporting assets, requests, and release notes teams needed along the way.

Structure that scales with the org.

The shift from an informal group to a structured agile unit changed the team's standing within the organization. Transitioning to a more agile-like approach gave the team a shared planning rhythm and gave leadership clear visibility into sprint capacity and delivery timelines. Introducing structured refinement and dedicated QA sessions drastically reduced breaking changes and inconsistent UX patterns reaching production.

Publishing clear governance on Storybook and streamlining intake through Jira eliminated the constant back-and-forth about how to engage with the system. And the three Teams channels (AMA, announcements, and resources) gave product teams visibility into releases, conversations that might affect their work, and easy access to shared resources, all without having to track the design system down.

This is where the roadmap stands today: structural alignment and operational visibility are in place, the first two stages of the 5-Stage Design System Ops Roadmap. Cross-team collaboration, platform and tooling evolution, and full enterprise integration are still ahead. This is ongoing work at my current organization, but the foundation is in place to take it there.