Role
Senior Product Designer → Staff Product Designer & Design System Lead
Timeline
2023 — Present
Collaborators
Engineering Director, Staff Frontend Engineer, Content, Product, Technical Project Manager
Overview
An evolving leadership story — from building the system, to operationalizing it, to leading it at the vertical level.
This isn't a single project. It's a progression.
When I joined a newly formed product team tasked with scaling a large content operation, I started where most design system work starts — auditing what existed, identifying the gaps, and building the foundation. What followed over the next two years was something I couldn't have fully planned for: each layer of work created the conditions for the next one, and what began as a component library eventually became vertical-level design system leadership.
Bricks was the foundation. The CMS integration was the scale test. DesignOps was the operating model that held it together. And the Core Design System is where that trajectory has led — a vertical-wide system now in active adoption across multiple teams.
The first problem to solve was fragmentation. Multiple product teams were operating under different visual identities with no shared component architecture, no token system, and no path to consistency. Every team was building the same things differently.
I led the creation of Bricks — a multi-brand design system built in Figma using a primitive-to-semantic token structure, atomic component architecture, and a dedicated Storybook instance for engineering. The governance model included a Slack-based request channel, an automated Jira workflow for tracking, and weekly triage meetings with cross-functional leads.
Early results showed a 50% improvement in engineering efficiency. More importantly, it created a shared language that design and engineering hadn't had before — the cultural foundation that made everything that came after it possible.
Phase 2 — The Scale Test
CMS Integration
With a design system in place, the next challenge was scale. The team needed to build and maintain landing pages across 70+ brand identities and hundreds of programs — a number that would grow into thousands of pages when factoring in iterative testing and personalization. Doing that manually wasn't viable. Two engineers could produce two landing pages per sprint. We needed a different model entirely.
After evaluating options, we landed on Contentful — a headless CMS that gave us the flexibility to define our own content models and pair them with the component system we'd already built.
My Approach
I deconstructed our existing landing pages into modular, reusable components and used those patterns to inform the content model architecture in Contentful. I built a CMS-specific token library that limited each brand to four curated colors paired with a shared neutral palette and a choice of two font families — enough flexibility for brand expression, while staying constrained enough to prevent design sprawl at scale.
Working closely with engineering, I established naming conventions and tagging structures that ensured long-term maintainability and alignment between design and code. I then led three rounds of cross-functional QA — each team member simulating the page-build experience in Contentful's visual editor, documenting friction points, and iterating until the system was ready for handoff to content teams.
Even after QA, building a new page through the visual editor could still take nearly a full day. I partnered with engineering to build a custom Contentful plugin that allowed editors to clone existing templates directly within the CMS — reducing page creation from a full day to under an hour.
Outcome
We went from two landing pages per sprint to scaling toward thousands. Content teams could now build, theme, and publish pages without engineering support. The system gave us speed, autonomy, and consistency across all three teams at once.
The business result was significant: a major partnership deal was signed that leadership stated directly would not have been possible without the CMS and design system integration. That deal, and the systems thinking behind it, directly contributed to my promotion to Staff Product Designer.
Phase 3 — The Operating Model
DesignOps
Scaling the system created a new problem: the team had grown, the work had grown, and the informal processes that had worked at smaller scale were starting to break down.
I built the operational layer from scratch — without the title, without a formal mandate, and without a precedent to follow on this particular team.
That meant embedding across both design and engineering ceremonies — standups, sprint planning, kickoffs — acting as the connective tissue between disciplines and keeping product thinking central to both. It meant building a formal contribution workflow: an Asana intake form feeding a prioritized backlog, biweekly intake reviews, scoping sessions, kickoffs, structured deployment. And it meant advocating at the organizational level — not through presentations, but through consistent delivery that made the value of operational discipline impossible to ignore.
At a certain point, teammates started noting that I was operating more like a product manager than a designer. I took that as a signal the work was landing — not that I was out of my lane, but that the lane itself needed someone thinking that way.
The processes we built on this team became reference points for others across the organization. Replication, in this context, is the most honest measure of whether an operating model actually worked.
Phase 4 — The Current Chapter
Core Design System
The work now has a different scope. Having established the foundation, scaled the content operation, and built the DesignOps model, I'm currently leading the Core Design System for our vertical — a system designed to serve multiple product teams rather than a single one.
The system has launched and is in active adoption. The architecture draws directly from what we learned building Bricks — the token strategy, the governance model, the contribution workflow — but at a larger organizational scope. The cross-functional rituals and operational model built during the DesignOps phase are the infrastructure that makes multi-team adoption possible.
This phase is less about building from scratch and more about leading a living system — maintaining coherence as more teams adopt it, evolving governance as contribution patterns emerge, and advocating for design system investment at the vertical level.
Impact
Engineering efficiency improved 50% on the foundational system.
Page creation scaled from 2 per sprint to hundreds, trending toward thousands.
A major business partnership was secured that leadership attributed directly to the systems work.
DesignOps processes built on this team are being replicated across the organization.
The Core Design System has launched and is in active adoption across the vertical.
Promotion to Staff Product Designer — a recognition of the cumulative strategic impact, not any single project.
Reflection
The through-line across all of this is that systems work compounds. Each layer created leverage for the next. Bricks made the CMS integration possible. The CMS integration proved the value of the system at scale. The DesignOps model made a growing team sustainable. And all of it created the organizational trust needed to lead at the vertical level.
The thing I'd emphasize to anyone doing similar work: your design system is never done, and that's not a failure state — it's the point. A living system that evolves with the business is exactly what you're building toward. The goal isn't completion. It's durability.
