Making good design judgement the default across eight squads

Eight squads built one product, but local decisions about findings, actions, status and confirmation created conflicting behaviour despite approved components. Each difference became expensive when repeated across Digital Banker.

Bankers risked relearning tasks while content and accessibility defects spread. The program needed reusable, challengeable decisions without making a principal designer the approval queue.

The design system defined controls, not when to show a finding, order actions or trust a status. Squads filled that gap independently, often unaware another team had faced it.

Reusable decisions had to survive different constraints and release dates while exposing assumptions about permissions, data freshness, recovery and accountability. They also had to preserve designer ownership across work nobody could see in full.

Stronger review and design-system compliance had produced late critiques after product and technical choices hardened. The disagreement was about meaning, not components.

I compared flows across squads and found four recurring families: findings, actions, status and confirmation. Each needed a shared product pattern containing its decision rule, content contract, states, evidence and exceptions while leaving component ownership with the design system.

Governance moved from approving finished screens to propose–review–adopt–measure. Squads could propose from live delivery, review with affected peers and adopt provisionally; decisions and exceptions travelled with each pattern instead of relying on oral history.

I inventoried repeated decisions and failure cases with design, content, engineering and product partners. Each pattern recorded purpose, trigger, required information, states, accessibility, limits, approved components, a steward and evidence needed to leave provisional status.

We stress-tested drafts with stale data, conflicting permissions, interrupted work and long content. AI generated challenge sets, not evidence; designers checked them against policy, research and technical reality, discarding impossible combinations and controls outside the design system.

I did not create a mandatory gate or standing review board because accountability belonged with squads, not meeting availability. We also deferred patterns with only one implementation; one squad’s constraints could not establish reuse.

Fortnightly sessions used real proposals: designers named the reusable decision, showed failures and asked peers for a bounded answer. Content defined language contracts, design-system partners checked components, and engineers tested states across squad architectures.

Product leads allowed provisional adoption during delivery when ownership, limits and unresolved evidence were recorded. Designers later brought cross-squad examples without prompting, an observed sign that stewardship was becoming shared practice.

The map gave eight squads a common index. Adoption lines mean a squad referenced or implemented at least one family, not that every pattern shipped; this was directional, not a measured reduction in delivery time.

Teams challenged purpose, states and evidence earlier, while proposals, limits and exceptions preserved organisational memory. This was observed in working sessions; banker and customer effects remained projected because pattern adoption was not isolated from wider platform change.

I now treat inconsistency as a decision problem, not a component problem. Governance starts with a small pattern set and a propose–review–adopt–measure loop, while an engineer joins from the first implementation so observed behaviour keeps each reusable decision honest.