A System Nobody Owns Is a System Nobody Trusts (2024 - 2025)
Everyone blamed the teams for not following the design system. I saw the real flaw, and it was ownership, so I founded the Platform Design team to own BigDesign end to end and make consistency the path of least resistance for every team building on BigCommerce, inside the company and out.
TL;DR
- Everyone blamed the teams for not following the design system. The real flaw was simpler: a system nobody owns is a system nobody trusts.
- BigDesign ran on a federated model, so getting a component meant building it yourself and maintaining it forever, which made skipping the system the rational move on any deadline.
- A VP of Product saw what my hybrid design and engineering background could produce, and backed me to found the Platform Design team to own BigDesign end to end.
- We owned the React and Figma component library, a pattern library, a GPT UX writing assistant, and the Catalyst storefront base, leaned on by around ten internal teams and the external developers building on the platform.
- We ran as a partner and not a gate, with weekly design feedback, direct developer support, and a Feature Intake Process, and I stayed hands-on in the libraries myself.
- The real payoff came with AI: the pattern boilerplate now lets teams skip Figma and prototype in Cursor, Codex, or Claude, better than the old v0 mockups, which is the exact muscle I lean on now as a PM.
For a while I was a design manager with a strange split in my job. On paper I owned the design language, our system called BigDesign, but I owned it as an individual contributor, which meant that every time something needed to change in the actual code I was still knocking on the door of the front-end teams and waiting for a hand. I could see exactly what the system needed, I just could not always ship it myself, and that gap was quietly driving me a little crazy.
What changed things was not a slide deck. A handful of people around me had been promoting the same idea for a while, and then a VP of Product happened to see what my hybrid background, one foot in design and one in engineering, could actually produce when it was pointed straight at the system. That was the moment the argument stopped being theoretical. Together we made the case, and the Platform Design team was born with a real mandate to own BigDesign end to end.
Why nobody trusted the system
To see why this needed a team and not just better documentation, you have to look at how BigDesign was run at the time. It followed a federated model, which sounds democratic and generous right up until you actually live inside it. If your team needed a new component, or even a small tweak to one that already existed, the system did not hand it to you. It handed you a second job:
- Build the component yourself
- Squeeze the work into your own sprint
- Publish it with no real review
- And then own its maintenance, forever
Put yourself in that spot with a deadline breathing down your neck, and the rational move is obvious. You skip the system entirely and build a quick custom thing that solves today's problem and only today's problem. Almost everyone did exactly that, and honestly, who could blame them. The trouble is that a thousand reasonable local decisions add up to one very unreasonable global mess: the same pattern rebuilt from scratch a dozen times over, interfaces that looked and behaved a little differently in every corner of the product, effort duplicated endlessly across design and engineering, and a system that technically existed but that nobody actually owned or supported. The platform slowly stopped feeling like one product.
So the fix was never going to be another round of documentation, however pretty. The system did not have a knowledge problem, it had an ownership problem, and the only thing that fixes an ownership problem is somebody standing up and actually owning it.
What owning it actually looked like
So that is what we did. The team took clear, visible ownership of BigDesign, and our reason for existing was simple enough: give every other team the design infrastructure that lets them move faster, stay consistent without having to think about it too hard, and ship better work. In practice that meant building and maintaining a handful of things, and they are worth walking through, because the artifacts are the real argument here.
At the center sits the component library, a shared set of production-ready React components with Figma files kept in lockstep right beside them. Around ten product teams inside BigCommerce lean on it, split up by domain, and so do the external developers building on the platform, none of them having to reinvent a button or a modal ever again.
On top of the components we built a pattern library, which is really a library of good decisions. It defines how the components fit together to solve the UX problems that keep showing up over and over, things like onboarding, filtering, navigation, and the humble empty state. Patterns are what let a team build something brand new and have it feel familiar on the very first try.

Because so much of good design work is really just writing, we also built a UX writing assistant, a GPT trained on our voice, tone, and accessibility standards and wired into the tools designers already use. It keeps the words across the platform sounding like one product, and it takes a real bite out of the content debt that piles up the moment everybody starts writing their own microcopy.
For the storefront side, we designed the base for Catalyst, our out-of-the-box storefront experience. The whole idea was to hand agencies and developers a starting point that is genuinely production-ready and still lined up with platform best practices, so customization becomes a head start instead of a fresh fight every single time. And underneath all of it we stood up a proper documentation hub, one place for live examples, contribution guides, and references, so a new team could get their bearings without a scavenger hunt and without guessing which button was the blessed one.
A team, not a gate
None of this works if the team behaves like a checkpoint. We were very deliberate about being a partner instead. We ran weekly feedback sessions with product designers to catch reusable patterns early, we stayed reachable over Slack and email and the internal forums so a blocked developer could actually get unblocked, and we sat in on design reviews to spot system needs before they shipped, guiding contributions through a Feature Intake Process rather than policing them.
I had the good luck to build this with people far better than me at their particular crafts. Turner Vickery led on governance and the Figma side and the daily collaboration with product designers, Georgia Hough owned developer experience, the tooling and docs and workflows that quietly make or break adoption, and a group of staff and senior front-end engineers kept us honest on code quality and architecture. My own job as the lead was to hold the vision, run the day to day, own the Feature Intake Process, and stay in the libraries myself, hands on the Figma and the React, because I never wanted to be the kind of lead who had stopped building.
Why it mattered, and what it turned into
The shift from a federated free-for-all to a team that actually owns the system changed how BigCommerce ships. Teams move faster now, they run into far fewer inconsistencies, and when they do get stuck there is finally someone to call. The system is trusted and used and genuinely maintained, and I am convinced that has less to do with the technology than with the simple fact that the people behind it are visible, reliable, and clearly there to help you win.
The part I did not fully see coming is how much leverage all of this bought us the moment AI showed up. Because the pattern library ships with real, usable boilerplate, you can now skip Figma almost entirely and prototype a new feature straight in Cursor, or Codex, or Claude, and what comes out is a working front end that is a good deal better than the v0 mockups our product managers used to hand over. At least five teams are already working this way, using those prototypes to give developers a front end that already looks and behaves the way it is supposed to. The system we built to enforce consistency quietly turned into the thing that lets people build at AI speed without losing it.
That last part is not abstract for me, it is basically my day job now. As a product manager I lean on this exact muscle constantly, prototyping new BigCommerce features and delivering the front end in precisely the shape it should be seen in, which is a very different kind of value than a PM usually gets to add. And I still spend a good chunk of my time coaching other designers to do the same, because the whole point of owning a system was never to hoard it, it was to hand everyone else the shortcut.


