
Analytic Partners
I came in to design components. I ended up redesigning how the company thinks about design.
~90%
Faster design delivery
50+
Components, 1000+ variants
~70%
Design to dev followups
ROLE
Senior Product Designer
TIMELINE
Jun 2024 - Present
TEAM
Solo designer on project
TOOLS
Figma, Pendo, LogRocket, JIRA
CONTEXT
Analytic Partners builds enterprise software for marketing mix modeling - helping the world’s largest brands figure out where their marketing dollars are actually working.
The product (GPS-E) is dense, the stakes are high, and the users are analysts and executives making budget decisions in the millions. Getting the UX wrong here isn’t just a usability problem, it’s a credibility problem.
THE SITUATION
My first week at Analytic Partners, I opened GPS-E and found 3 different dropdown styles on the same page. By the end of week 2, I’d catalogued over a dozen variations of the same UI component across 4 product pillars - each one slightly different, none of them documented, all of them technically “the design system.”


The system started as a loose collection of MUI components. But without variants, documentation, or engineering integration, it hadn’t scaled. Every product team went their own way, building whatever made sense at the time.
Design also had no influence on the roadmap. Features got scoped, specs got handed over, and design stepped in at the end to make things look reasonable before shipping. Three problems all feeding each other:
01
No process for UX research to reach product decisions
02
No shared component language between design and engineering
03
No infrastructure for design to move at the pace needed
GOAL
Build something that lets design get ahead of the product instead of chasing it.
That meant we needed:
01
A real design system
02
Actual engineering adoption
03
A feedback loop that connected UX findings to roadmap decisions
UNDERSTANDING WHAT EXISTED
Before designing anything new, I needed to know exactly what I was dealing with. I owned the design system end-to-end: research, architecture, component design, documentation, and engineering adoption. The first step was making sure I understood the full scope of the problem before touching anything. I audited every UI pattern across all 4 product pillars - text styling, buttons, dropdowns, inputs, tables, modals…etc.

When I presented the audit to engineering leads and product managers, something shifted. Seeing a dozen variations of the same component laid out in a single slide made the problem legible. It stopped being a design opinion, but rather a business problem. That framing mattered for everything that came after.
BUILDING FOR ADOPTION
A design system nobody uses is a design system that doesn’t exist. That was the failure mode I was most trying to avoid. I built the system around 3 decisions that prioritized adoption over perfection:
Tokens before components
I started with the foundational layer (color, spacing, typography) before touching a single component so that changing anything later would be a token update, not a full rebuild.
Variants based on real use, not hypothetical
The old MUI components were generic. I audited every context each component appeared in, then built variants that covered those specific cases.
Documentation inside the component
Usage guidelines, do/don’t examples, accessibility notes - all built directly into each Figma component itself so it was impossible to miss.

GETTING A SEAT AT THE ROADMAP TABLE
The system solved the infrastructure problem, but design still wasn’t upstream of product decisions, and that’s where the real leverage was.
I started running monthly UX audits - Pendo for behavioral data, LogRocket for session replay, CSAT scores and direct user interviews. Each one product a prioritized list of friction points with data behind them, presented directly to product leadership.
Now, instead of design waiting for features to be scoped, UX findings started shaping what got scoped. Over time I identified and championed 6 product initiatives that hadn’t been on anyone’s radar - each validated by data and eventually prioritized on the roadmap.
I also launched a quarterly design newsletter for 80+ cross-functional stakeholders. The goal was simple: make design's work legible to people who weren't in design reviews. Turns out when people can see what design is doing and why, they want to collaborate earlier.
THE SYSTEM TODAY
The Analytic Partners design system now spans 50+ component sets and 1,000+ variants, adopted across three product pillars by 20+ engineers. It has reduced time spent building common UI patterns by ~25–40%, reflected in faster iteration cycles and fewer QA-related design fixes. And design has a voice in roadmap decisions across 5 product teams.

OTHER WORKS

