How I built a foundation for greater product craft & quality.

Photo by Paolo Bendandi on Unsplash

My strategy

Delivering high-quality design execution was always part of my role—but making a meaningful impact on what we shipped required a deeper cultural shift across Product and Engineering.

The company had launched a broad “Quality” initiative focused on fixing bugs and reducing tech debt, but I saw an opportunity to expand this definition. I advocated for UX quality to be recognized as equally critical—elevating intuitive design and usability alongside system performance.

With BigCommerce’s strategic focus on composability and our need to support a wide spectrum of use cases—from SMB to Enterprise B2B—I led a design strategy with two core pillars:

  • Strengthen our design systems to improve consistency and scalability

  • Define and embed UX quality standards to improve how we build and release products

This work required reshaping not just our processes, but our mindset around what quality truly means.

Inconsistent, antiquated UX

Inconsistent UX across the platform was due to legacy tech (Angular vs React), outdated design specs, and fragmented implementation. Because we prioritized releasing new features and were rewarded for releasing on time, we deprioritized a focus on UX quality. Some of the challenges included:

  • Domain-driven silos: Teams prioritized their team goals over addressing global consistency, making cohesive cross-platform experiences nearly impossible to deliver.

  • Periodic rollbacks: Products were often released without testing appropriately. There were a handful of times we had to roll back the release due to customer complaints or last minute surprises.

  • Lack of front end engineering culture: BigDesign was poorly documented, inconsistently adopted, and lacked the engineering support it needed to evolve.

  • UX debt accumulation: Without oversight, usability issues compounded over time, degrading customer trust and increasing support costs.

  • Lack of strategic tooling: Designers had no clear reference for approved patterns, nor a process for evolving the system as new needs emerged.

  • No ownership of core platform UI (Control Panel): Critical shared experiences like navigation, onboarding, and notifications were orphaned (we addressed this in the Control Panel redesign - see Case study).

I realized we had a problem shortly after the designer who had been in charge of BigDesign (our design system library) left the company. Teams were launching products that didn’t align across product teams and the designers didn’t understand which patterns to use.

To fix, this we needed to establish a single source of truth.

“.. every time I do a download and 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

Part 1: Establishing the Platform Design Team

Why we needed it

BigCommerce had for years relied on part-time contributors within domain teams -- all the engineering work done was a grassroots effort, done in peoples’ spare time.

This approach lacked consistency, governance, and long-term ownership. Meanwhile, domain teams were building features with no shared understanding of correct patterns.

Engineers expected polished design specs, but often implemented patterns inconsistently or incompletely. Even on the design team, one hand did not know what the other was doing -- designers did not have a shared understanding of what the latest patterns were.

This set of libraries provided guidelines and patterns that we could all align on and build upon into the future.

My Role

  • Team formation, hiring & staffing

  • Strategic planning & execution

  • Champion and cross-functional advocate

  • Developer experience integration & design ownership

Design system / Platform Design OKRs

A design driven effort

Establishing OKRs

As a team, we established OKRs so that product design and UX research could improve the maturity of how we worked, with the goal of improving the quality of our products for our users. In 2023, we decided to commit design cycles to improving our libraries for both internal developers and external developers.

Designers worked on at least two tracks at a time — product design assignments with their product teams while contributing to the design systems work.

I hired and staffed the team with a Product Design Manager to lead, and several contributors, including a Lead Product Designer to do the craft work of building the components. The overall effort took at least 6 months until our libraries felt complete enough for wider consumption internally and externally

Team Scope and Deliverables

  • Rebuilt the BigDesign Figma Library from the ground up

  • Introduced new patterns like lozenges for product status, addressing pattern overloading

  • Created a design pattern intake process so patterns could evolve through real product needs

  • Published new guidance around navigation, panels, tables, opt-in/out features, and product status indicators

  • Enabled external teams (e.g. third-party app developers) to build more consistent UI

  • Provided storefront components and patterns for Catalyst, a composable, headless storefront framework.

Published libraries on Figma Community

I believed that as a design team we needed to lead by example - that no one would give this initiative support unless we were fully invested in making our design system come to life.

We had to get our own house in order first. Only then could we ask leadership and engineering for support.

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

Contributed to a 20% improvement in developer efficiency for common UI patterns

Increased pattern reuse and platform consistency by ~90%

The DevX strategy

BigCommerce had long deprioritized investment in our design systems—they were seen as cost centers with no direct revenue.

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