Transforming ChartHop’s design system into product infrastructure driving $750K+ ARR
Role: Senior Product Designer - Design Systems
Company: ChartHop
Year: 2022 - 2023
Figma File: ChartHop Design System
This work was done before AI-assisted development for designers. Today, I design, build, and test components end-to-end using Claude Code.
This case study reflects how I think about systems, scale, and organizational impact.
TLDR: Impact
Transformed ChartHop’s design system into a shared product infrastructure by tying system work to high-impact features, engineering workflows, and scalable governance.
NPS increased from 21 to 31 (all-time high)
$750K+ ARR from features built on system components
4 designers supported 9 product verticals through system leverage
Same-day UI updates (previously week-long cycles)
3+ product teams shipped independently using established patterns
Teams-Based Org Chart (flagship feature) launched in 3 months, enabling ChartHop's largest deal in company history
The Problem
ChartHop looked visually consistent, but underneath was chaos.
Years of technical debt created layers of unusable, repetitive code where multiple versions of the same components existed. The Figma library was disconnected from production, and engineering had no buy-in—they couldn't easily find or use components, so they built custom solutions instead.
The result:
Customers experienced inconsistent interactions that showed up in NPS scores and lost deals.
Engineering velocity suffered because every feature required reinventing solved patterns.
When our VP of Design departed in early 2022, the growing customer satisfaction impact created an opening: leadership was ready to invest in solving this properly.
My Role
I led this transformation end-to-end:
Rebuilt the complete system: 403 components in Figma with corresponding React components in Storybook
Created governance frameworks: Working agreements, contribution guidelines, and review processes that enabled sustainable collaboration
Drove cross-functional adoption: Partnership models with engineering and onboarding processes that scaled without me
Connected to business outcomes: Framed investment in terms leadership cared about—velocity, consistency, and customer satisfaction
Built in the system while building the system: Designed features using the components I was creating, identifying gaps through practice
The Approach
Design systems fail when they're treated as isolated tooling projects. Success requires simultaneous work across three dimensions: strategic positioning, cross-functional execution, and sustainable scale. Here's how I approached each.
Strategic Positioning
Starting with Impact
There's a common misconception in design systems: start with simple components first.
Simple components live everywhere. Updating them means touching hundreds of screens with low perceived impact. Instead, I identified a high-stakes product need: a redesigned table component for a key feature that would directly impact adoption and retention.
This was strategic: by solving a hard problem tied to real product goals, the design system proved its value immediately rather than asking stakeholders to trust that foundational work would eventually pay off.
We started with tables because they are the most used component across our platform.
This is an example of a table before…
And this is an example of a table after.
You can view the extensive audit and mapping of all of the tables here in Figma.
Navigating Hard Tradeoffs
When critical infrastructure decisions arose — I grounded the conversation in evidence rather than opinion.
For complex components such as the table component and our rich text editor, I created a detailed audit mapping every option against:
Current product functionality we couldn't lose
Required new capabilities
Gap analysis and cost implications
By making tradeoffs visible and concrete, we could have productive conversations about what mattered most.
We chose AG Grid for tables and TinyMCE for our rich text editor — decisions the team could stand behind because the evaluation process was transparent, thorough, and made together.
The example below shows the previous text editors and their functionality across the app align with what we aimed to transition to in a phased rollout.
Cross-Functional Execution
Building Partnerships with Engineering
The system would only succeed if engineering felt ownership, not obligation.
I partnered closely with an engineer who was excited about collaboration early on. Rather than handing off specs, I established:
Regular syncs where I asked about technical constraints before finalizing designs
Feedback sessions with the broader engineering org so people felt heard
Conversations around shared tools like Chromatic and Storybook where we could build together
Engineers who feel heard become advocates and early adopters. When my engineering partner understood why a component was designed a certain way (and his technical perspective had shaped it) he could champion it with his peers.
“For the first time, the design system felt like something I was building with design and not something just handed to me to build.”
— Jason Shapiro, Principal Engineering @ ChartHop
Creating Governance That Scales
A design system without governance becomes chaos. However, heavy-handed rules kill adoption. We needed balance.
Together, I worked with my team to draft A Working Agreement Policy — clear expectations that enabled autonomy while maintaining quality. We agreed that:
All Chromatic stories triggering UI diffs must be reviewed by a designer
All components must be logic-free (maintaining separation between domain and display)
Stories should only include reusable shared components, not pages
Components must be reviewed by an engineer outside your team
When timelines allow, the expectation is to use and contribute to Garden (Our Design System) as part of your project/feature
These simple guidelines helped us work towards our shared goal without being too restrictive. Additionally, I established a Slack channel for questions and support, reinforcing the idea of building a design system as a community.
Below are some examples of governance documentation I have created.
Scaling Impact Through Others
Mentoring Others on Systems Thinking
I ran ChartHop's design mentorship program, but mentorship wasn't separate from the design system — it was part of how the system scaled.
I involved other designers, product managers, and some engineers in building through paired sessions and critiques structured around system principles, and documentation contributions.
One junior designer went from struggling to scope variants to independently designing and documenting a complex form pattern that shipped across multiple product areas. That progression (from consumer to contributor) was the real measure of success.
Enabling Teams I Never Directly Worked With
The ultimate test: does it enable quality work from people you've never met?
By the time I left, the system was actively used across product teams I hadn't directly collaborated with: Approval Workflow Builder, Form/Survey Builder, Employee Profiles, and Teams-Based Org Chart. Teams could reference patterns, understand rationale, and extend appropriately, without even consulting me.
Validation
Proving the System: Teams-Based Org Chart
The design system's value became concrete when we launched the Teams-Based Org Chart — a major capability visualizing cross-functional teams alongside traditional reporting structures.
This was complex with a tight timeline (3 months to MVP) and significant business pressure: a large enterprise customer was co-creating it, and it needed to work for our existing base too.
The design system made this possible:
New card components I'd built scaled directly into the visualization
The slideout panel pattern enabled in-context editing without frustrating dialogs
Engineering velocity increased because developers weren't recreating patterns
The feature launched on time in March 2023 and directly enabled $750K+ ARR from new enterprise customers, including ChartHop's largest deal in company history, plus expansion into new market segments.
Why this matters
Design systems fail when they’re treated as tooling.
They succeed when they’re treated as infrastructure.
I earned trust through impact and built governance that outlived my involvement.
If it depends on one designer, it isn’t a system.
That’s why ChartHop was able to ship new features for 18 months without a designer after my departure in 2023.
You can view the entire design system on Figma here.