The product owner and the development lead wanted the same transaction flow with more fields bolted onto it. That flow was built around the backend database structure, not around the person filling it in, so it carried no hierarchy and no visible field dependencies. The user absorbing that ambiguity was a cashier or a support rep managing high transaction volume during a live customer interaction, not a power user with time to spare. Payment technology was already under pressure from the pandemic-driven shift to omnichannel transactions, and at a platform scale touching over 130 million merchants globally, every ambiguous field carried the price of a lost transaction.

Designed for the System, Not the Person Running It

Two separate fights on this engagement turned out to be the same fight. One was about a form. The other was about who gets to own a design system. Underneath both was the same habit of building for the convenience of the system that already existed instead of the person forced to operate inside it.

The Flow That Made the Cashier Do the Math

I didn’t argue the point directly. I built a prototype and had the product owner and development lead run through it themselves, timed. Once they saw how long the ambiguity actually cost, and how much of that time was spent guessing which fields depended on which, the direction changed.

The fix wasn’t more fields. It was grouping dependent fields together, so entering one made its downstream requirements visible instead of discoverable only on submission failure. I also reordered the flow to match the actual sequence of questions a cashier asks a customer during a transaction, not the sequence the database happened to store them in. Neither change cost additional development effort. The product owner got a faster flow, the users got a legible one, and the updated field groupings were structured cleanly enough that the design system absorbed them without a special case.

No One’s Job, Everyone’s System

The organization had already tried, and abandoned, one failure mode before I arrived, and was living inside a second one. I recognized both patterns against a published design-systems team-scaling framework rather than naming them from scratch, which is what let me diagnose the failure mode quickly instead of relearning it by trial and error over another six months. Originally, teams built in isolation, a solitary model where each product team maintained its own version of shared components with no coordination at all. That gave way to a centralized model where one team owned all contributions, and any product pod could commit new components and patterns directly as they shipped features. Centralization was the status quo I inherited, and it was already failing for a different reason than solitary work had. Quality varied by pod. Redundant patterns accumulated because no one was checking for overlap. The products consuming the system ended up with disjointed experiences module to module, despite there being, on paper, an owner.

My first instinct was to shrink the problem, not restructure it. I proposed keeping a centralized team but making it smaller, with a simpler intake process attached, effectively a tighter version of the same model the organization had already tried once before under a different name. Working through it across individual and small-group conversations, I reversed that position. The council structure and the decision tree itself were mine to design, since the source material named the failure patterns but didn’t prescribe a fix. A federated model with a decision tree for commits was the better fit, not because it centralized quality control tighter, but because it distributed accountability. Any pod building something new had to run it through the decision tree to confirm they were using existing components correctly or had actually built something novel worth contributing back. Governance stopped being one team’s job, which meant it also stopped being one team’s bottleneck, and stopped being no one’s job the way the solitary model had left it before that.

Three models, in order: solitary, where nothing was shared; centralized, where one team owned everything and became the bottleneck; federated, where accountability distributed across every contributing team.

Where This Fits the Broader Pattern

Design systems fail in predictable stages as organizations scale past a certain number of contributing teams. Solitary ownership breaks down first, every team maintaining its own components with no coordination. What follows is usually an over-centralized team that becomes its own bottleneck, the exact failure this platform was living inside before the federated model replaced it. That’s the field this engagement sat in, not a claim about what this specific rebuild proved on its own.

Model concepts inspired from source: https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0

The Question I Ask First Now

The correction here wasn’t proposing governance. It was recognizing that centralization and quality aren’t the same lever. My first draft of the fix just made the bottleneck smaller, a tighter version of a model the organization had already tried and moved past once. The version that worked distributed the decision, not the workload, which is a different design problem entirely.

That test now shapes how I evaluate any process I’m asked to fix. Before proposing a structure, I check whether the failure is a capacity problem or an ownership problem, because a smaller centralized team solves the first and makes the second worse. The transaction flow work taught the adjacent lesson: the cost of ambiguity is invisible to the person who designed the system and fully visible to the person forced to operate inside it. Timing that gap, rather than arguing it, is still the tool I reach for first when a stakeholder is confident their flow is fine.