Case Study 04 / 06 · Jellysmack · 3 months
Sonar —
Design System
A design system built to unify Jellysmack's creator-facing and internal products, from token architecture through adoption across multiple product surfaces. The goal: make shared infrastructure so valuable that teams choose to use it over building their own.
My Role
Design Systems Lead: architecture, component design, documentation, adoption strategy
Team
Design, Engineering, Product
Timeline
3 months
Scope
Full design system: tokens, components, patterns, documentation; adopted across JellyX, JellyStudio, and internal tools
Fragmentation that users could feel, even if they couldn't articulate why.
Jellysmack builds products for creators: tools for licensing music, distributing video, claiming content, and growing audiences across platforms. When the design team started scaling, we had the classic problem: every surface was built in isolation. Designers were reinventing components. Engineers were maintaining redundant implementations. And the product felt fragmented in ways users could feel even if they couldn't articulate why.
The answer was Sonar, a design system built to unify Jellysmack's creator-facing and internal products. My job was to lead it.
A portfolio of products that shared a brand but not a design language.
Jellysmack had grown rapidly through acquisition and product expansion. The result was a collection of surfaces, each built by different teams, at different times, with different tools, that shared a brand but not a design language.
For designers, this meant constant reinvention. For engineers, it meant maintaining multiple implementations of the same pattern. For users (creators managing their catalog, their analytics, their deals), it meant subtle inconsistencies in interaction behavior that eroded trust in the product.
The business cost was real: slower shipping, higher design-to-engineering translation friction, and a product that couldn't scale visually as new surfaces were added.
Shared infrastructure, not a side project.
I led Sonar from architecture through adoption. My approach treated the design system not as a side project or a design-team artifact, but as shared infrastructure: something that had to be valuable enough that teams would choose to use it over building their own.
That meant making decisions at every level: token architecture to build a flexible foundation; component design for real product complexity (not just ideal states); documentation that answered the actual questions designers and engineers had; and an adoption strategy that let product teams migrate incrementally rather than requiring a big-bang rebuild.
From token architecture to product adoption.
Component Foundations
The system's foundation was a semantic token layer that separated decisions about values from decisions about meaning, letting components adapt to dark and light contexts without manual overrides at the component level. Key components included dropdown menus, input fields, data tables, modals, and navigation patterns, all designed for the data-dense interfaces that Jellysmack's creator tools required.
Core input components: dropdown and text input: designed with full state coverage across default, focus, error, and disabled.
Component Variations & Theming
Every component in Sonar was designed with its full state space: empty, loading, error, disabled, responsive breakpoints. Modal components were a particular focus — creator tools frequently required complex confirmation and decision dialogs, and getting those right across both light and dark themes was critical.
Modal component in light and dark themes: the same semantic token layer adapting to both contexts without per-component overrides.
Storybook Documentation
The component documentation was designed to answer the questions designers and engineers actually asked. Every component had Storybook stories covering all variant combinations, ensuring that every state was testable in isolation and that engineering implementations could be verified against design intent.
Storybook: every component documented with interactive stories: designers and engineers working from the same source of truth.
Presentations & Team Alignment
Adoption was as much a communication problem as a design problem. Regular system reviews with product teams, clear before/after comparisons, and deliberate stakeholder presentations were key to getting buy-in and maintaining momentum across a large, distributed organization.
Team presentations: showing progress, aligning on adoption priorities, and building shared ownership across design and engineering.
Infrastructure that compounds over time.
Key Results
3+
Product surfaces adopted Sonar across Jellysmack
↓
Meaningful reduction in design-to-engineering handoff friction
↑
Faster iteration velocity on creator-facing products after system adoption
1
Shared design language established across design and engineering
Beyond the immediate metrics: other teams at Jellysmack adopted system patterns as an organizational standard, and the adoption approach became a model for how cross-functional infrastructure projects should be structured. The system outlasted the initiative that created it.
System adoption is a relationship problem as much as a quality problem.
I'd invest even more time upfront in co-creating the system with engineering leads — not just presenting it to them — so that implementation concerns could shape component architecture decisions before they became costly to change.
Design systems succeed when engineers feel ownership over them, not just obligation to use them. The teams that adopted Sonar fastest were the ones whose engineers had been in the room when key architecture decisions were made. That wasn't an accident, and I'd bake it into the process from day one next time.