How I established a foundation for greater product craft, consistency & velocity.

BigDesign went from a “nice-to-have” into a trusted, actively maintained source of truth—and used it to ship improved, coherent experiences faster across at least two high-leverage bets: Developer Experience and Catalyst.

Results

We turned BigDesign, our design system, into a source of truth; for the first time we had a trusted, actively maintained system with clear ownership and governance.

~20%

Improvement in developer efficiency for common UI patterns

90%

Of projects implemented used new patterns, increasing platform consistency

2,500+

Guide & pattern downloads (BigCommerce Figma community)

Background

BigCommerce had long deprioritized investment in design systems; it was seen as a cost center with no clear revenue impact — and there were always other important, competing priorities, and no clear owners.

The business was evolving to address a more sophisticated enterprise audience and doubling down on its Open SaaS strategy. Developers were a critical user group to that strategy — their experience building on the platform influenced merchant adoption, ecosystem growth, and long-term viability.

Designers were frustrated because we kept compromising quality for fast launches.

My role was to figure out how to launch higher quality experiences faster despite limited resources and engineering support.

Customer perception

Customer feedback echoed internal frustration: the product felt clunky, inconsistent, and unpredictable.

  • Critical surfaces like the Dev Portal, Dev Center, and Control Panel were outdated and built by different teams

  • BigDesign operated as a federated, “side-project” model with no governance

  • UX issues weren’t visible, trackable, or prioritized

  • “Quality” meant bug counts, not whether users understood, trusted, or could navigate the product

We needed a foundation that unified the product—and we needed support to build it.

“.. every time…it downloads in a different manner, I can hear the the gears of my brain grinding, maintaining consistency across page to page to page.”

  • A BigCommerce customer, describing his experience with the product

The strategy

To start making change, we had to do so on the design team first. We focused on building both a single source of truth and a new operating model for quality. I proposed a UX strategy with two pillars:

  • Platform Design & DevX - Build a centralized, trusted design system for internal and external developers and designers, including storefront components.

  • UX Quality & Debt – Redefine “quality” to include usability and consistency to ensure teams release with quality. Give teams a way to find and fix issues that they otherwise might ignore.

These pillars gave BigCommerce a shared language for experience quality and the infrastructure to deliver it.

I assigned team leads and contributors to ensure consistent ownership and we established OKRs to achieve our goals.

Pillar 1: Platform Design & DevX

From a grassroots effort to a formal, strategic team

Design system work was previously volunteer-driven: no ownership, no roadmap, no reviews. We had to formalize ownership on the design team.

So we spun up a Platform Design team with a:

  • Product Design Manager

  • Lead Product Designer

  • Senior Product Designer

Together, we took control of BigDesign (React + Figma), pattern libraries, documentation, developer guidance, and contribution workflows. (I also assigned a Sr UX researcher to the team to help with the Developer Experience work, which I’ll explain in a bit.)

Platform Design OKRs

Rebuilding BigDesign

We embarked on a 6 month effort to:

  • Rebuild the BigDesign Figma library from the ground up (~50 components, ~30 reusable patterns)

  • Introduce clearer, more scalable patterns (e.g., standardized status lozenges, opt-in / opt-out)

  • Publish guidance on how to use and extend patterns for new product work

  • Publish UI kits on Figma Community, adopted by 2,500+ designers and developers

I used our team OKRs practice to get everyone on the same page so we could stay focused.

Some patterns & components we created

  • Components for navigation

  • Bulk actions in tables

  • Stateful tree

  • Colors

  • Catalyst Storefront - Icons

  • Empty states

  • Data visualizations

Getting leadership support

Once we had a good set of assets in place, it was a matter of getting the rest of the organization to see the work we had done and get engineering commitment behind it.

I spearheaded the creation of the Platform Design team, getting buy in from our CPO and Engineering VPs. I put together a proposal and an org map, defining who, what, when, why and how. I worked with the VP of Engineering Strategy and my Product Design Manager who was driving the BigDesign effort to define our commitments. We agreed to an intake process, a definition of done that included adherence to using BigDesign in all new releases along with design reviews, and the commitment from four Front End engineering stewards to help other teams build their features with BigDesign.

Platform Design team org structure and ownership

Making it work, for real

By creating frameworks, including regular meetings, documentation, a Jira ticketing board, reviews, and a slack channel, we built momentum and engagement across engineering and design.

We gained traction, but this work wasn’t without challenge. Engineering was often pulled in other directions, and design systems work competed with feature work for priority. Our steward model proved unreliable, so I went back and escalated a request for dedicated engineering support (from a new CPO). I succeeded in getting the commitment from our new CPO to give us the necessary engineering support to maintain the proposal I had made a few months’ prior.

Designers were empowered to advocate for BigDesign.

Engineers knew where to go for help and documentation.

Product managers began to understand the cost of inconsistency.

Paving the way for improved change

Once we had established documentation and visual references so designers could know the “source of truth,” we were able to direct our design feedback discussions to be more focused on pressure testing emerging patterns. Having a cohesive understanding on the design team reduced rework and confusion for product and engineering teams, improving build velocity and cross-team trust.

Results

Established strong, reusable design foundations allowing internal and external devs & design to innovate more easily.

Published ~30 patterns, ~50 components for BigDesign; 40 components and 40 page templates for Catalyst storefronts.

Raised bar for design craft across the design, product and engineering teams

Pattern, style and component guides used by over 2,500 people on BigCommerce Figma community

The DevX strategy

But for our Open SaaS strategy to succeed, we had to make the platform intuitive not just for merchants, but for developers building storefronts and apps.

I saw an opportunity: by owning both the end-to-end developer experience (DevX) and our design assets, we could create a unified, developer-friendly system. Developers needed these assets to build, thus we could justify investment in our design systems while pushing towards a better end-to-end DevX.

I formed the company’s first design team dedicated to DevX, pairing it with Platform Design to ensure shared ownership of both the journey and the design assets developers rely on.

The DevX team built quickly, so they could design, test, and iterate on patterns we could then add to our libraries—free from the slower cycles of our legacy Control Panel. I staffed the team with an experienced Product Design Manager, a Lead Product Designer strong in craft to construct the libraries, an ambitious Sr. Product Designer to own the full DevX journey, and a Sr UX Researcher to build a structured understanding of the developer personas we served.

The result? The team was able to work seamlessly to launch new assets, like our Figma UI kits and UX writing guide, into an revamped, refreshed Dev Center, based on customer research and modern design. The Dev Portal’s improved flow for creating apps reduced friction for developers. We finally made it easy to build on BigCommerce—and raised the bar for what a platform experience could be.

DevX: a sandbox for Platform Design

Dev Center showcasing BigDesign assets

What we launched

Establishing the Platform Design team allowed us to improve the products, artifacts and experiences we launched across the platform, and made it feel more like connected parts of a whole.

Here are some of the products / experiences that resulted:

Developer portal redesign, for submission of apps to BC marketplace

App management for developers

Carts report, using new data visualization style guide

Carts report, mobile app

The AI vision for BigDesign NEXT

Our vision and plan for BigDesign Next is to move to ShadCN/ui, for compatibility with a wide range of AI tooling such as v0. This would make it easier for teams to prototype and build with consistency and beauty. By providing proper context and prompt examples to models, this lays the foundation for the next gen work around design systems, so it can be more efficient. Having our current libraries already defined gives us a good foundation for this next chapter.

App landing page

My Apps

Catalyst B2B template - home page with categories

Catalyst B2B - my orders, logged in

Customer groups

Settings

Part 2: Creating a UX Debt and Quality Program

I launched an initiative to reduce UX debt, as we had a long tail of user facing issues that had been ignored for some time. We logged 700+ issues and fixed ~290 of them.

Is Quality Even a Problem?

Across the Product Design team, there was a growing sense that we were sacrificing product quality in favor of speed. This showed up in 1:1s, in cross-functional retros, and in our Culture Amp surveys—where one team member wrote:

“…we pay lip service to quality, but don’t actually allocate the resources.”

  • Product Design team member, Sept 2023

We had years of legacy UI, inconsistent language, and new features shipping without parity or polish. Designers were frustrated—but we lacked a shared framework for what “quality” actually meant.

To dig deeper, I ran a team-wide workshop to understand how designers defined product quality. What emerged was striking: quality wasn’t just about the end result—it was about the conditions that enabled great work.

According to the team, high-quality products shared these traits:

  • User validation: Research was conducted early to define the right problems—and solutions were tested with real merchants.

  • Cross-functional collaboration: Designers worked closely with devs, PMs, and marketers throughout the process.

  • Iteration & flexibility: Teams had room to pivot based on feedback and weren’t locked into early decisions.

  • Design ownership: Designers had influence over implementation—reviewing code, refining interactions, and polishing content before launch.

Many of these sound obvious. But in reality, they weren’t consistently happening—especially under delivery pressure.

As a result, we began incorporating these insights into our OKRs. We prioritized foundational improvements like:

  • Running research with enterprise merchants

  • Driving post-GA iteration on newly launched products

  • Ensuring design review before dev handoff

  • Investing in our design systems to improve speed and consistency

These were early steps in what became a multi-year journey to raise the bar for quality—not just in outcomes, but in how we work.

Redefining Quality to Include UX

At BigCommerce, “quality” was narrowly defined as fixing bugs and improving reliability. While important, this limited view sidelined usability issues that deeply impacted the user experience.

I partnered with PM and Engineering leaders to expand the definition of quality—bringing UX into the conversation as a core pillar, not an afterthought. This shift gave us permission to prioritize improvements that had long been deprioritized.

We introduced a UX debt framework that treated design gaps as real product risk. My team developed a system to audit, categorize, and track usability issues across the platform, aligned to four key principles: useful, efficient, usable, and desirable. By shifting mindsets, we unlocked cross-functional support to improve experience quality at scale.

Executing with Quality

Once we’d aligned on what quality meant, the next challenge was execution. How could we actually move the needle?

We faced years of accumulated UX debt—some issues simple to fix (like copy and visual inconsistencies), others requiring full redesigns, such as onboarding for single and multi-store experiences. At the same time, we needed a way to ensure new features met our standards. Not every product team had design support, and releases sometimes went live without any design oversight.

To close that gap, I worked with PMO to align on research and design steps needed as part of our Product Development Framework to ensure that we are delivering a minimal viable experience. I worked with engineering leadership to update our Definition of Done—the shared contract between product, engineering, and design. We added two simple but transformative rules:

  1. No front-end feature ships without a design review.

  2. All new features must use BigDesign components.

These changes gave design a clear seat at the table, embedded quality into the delivery process, and set a new baseline for how we built.

Tackling UX debt, one audit at a time

One of the first wins in our quality journey was securing budget for a dedicated UX writer—a role we’d never had before. He quickly became a key partner in elevating the experience across the product.

Together with our designers and domain teams, he led over 30 UX audits—deep dives that surfaced not only confusing copy, but also broader usability issues and design friction. These weren’t just surface-level observations; they exposed systemic patterns across the platform that were hurting our users’ confidence and efficiency.

To make sense of what we found, we built a tagging framework to classify each issue:

  • BigDesign/Styling – Are we using our design system correctly?

  • Navigation – Does the flow make sense and help users orient?

  • Interaction – Are behaviors consistent and predictable?

  • Copy – Are we following UX writing best practices?

  • Task Flow – Does the design support what the user is trying to do?

We didn’t want these audits to live in a vacuum. So I created a central Confluence hub—a guide for how to:

  1. Identify UX debt

  2. Document it consistently

  3. Resolve it collaboratively

By making UX debt visible, structured, and actionable, we turned a vague frustration into something teams could actually fix—and gave them the tools to do it well.

Documenting the debt

I asked one of my Product Design Managers—who had built effective design operations on the mobile team—to co-lead this effort and scale it org-wide.

Together, we:

  • Created a UX Debt ticket type in Jira with custom fields

  • Added impact labels (uxlow, uxmed, uxhigh) to help teams prioritize

  • Grouped tickets into epics aligned with domain teams to establish accountability

  • Designed a lightweight framework to help teams evaluate UX issues alongside bugs

We wanted teams to identify issues and fix them, not just file them—and that meant reducing friction, clarifying ownership, and making prioritization against other higher impact features easier.

Bringing resolution to debt

I was able to secure engineering support on the Customer Support team, who had an interest in helping to fix some of these issues.

With the help of PMO, we created a dashboard to help us see where issues were getting created, which teams had the most, and who was resolving them. We resolved some 290 tickets, that would otherwise have never been addressed.

Audits captured in FigJam

How to categorize UX debt

Jira ticket type

Prioritization framework

UX debt dashboard

Results

Secured cross-functional engineering support, including a Customer Support engineering pod, to directly contribute to UX fixes

What products with good or bad quality had in common, according the PD team

What should the quality bar look like for us?

Expanded definition of quality

Shifted company-wide quality perception, expanding the definition of “quality” beyond bug count to include usability, clarity, and design consistency

Logged 700+ issues across 30+ in-depth audits, establishing an organizational baseline for UX quality. Resolved over 290 UX debt tickets.

Established Confluence documentation to standardize how teams identify, log, and resolve UX debt going forward

Enabled non-designers to log and triage UX issues, increasing visibility and shared ownership across product and engineering teams

Created a scalable UX Debt tracking framework in Jira, including custom ticket types, priority labels (uxlow, uxmed, uxhigh), and epic-level accountability