bpCore

A design system at enterprise scale is not a Figma library. It is a governance infrastructure — a set of technical decisions, process structures, and organisational agreements that determine whether independent product teams make consistent decisions without requiring a central authority to review every one. At the scale of a multi-product portfolio with teams operating on independent roadmaps, the limiting factor is almost never the quality of the components. It is whether teams actually use them — and whether the system survives the first year of production without fragmenting back into the state it was built to replace.

The failure mode most organisations encounter is predictable. A design system is built with genuine technical quality, shipped with internal fanfare, and quietly abandoned within 18 months. The components are too rigid to accommodate real product complexity. The contribution pathway is too slow or too opaque for squads to use. Governance sits with a small central team that becomes a bottleneck rather than an enabler. Teams learn to work around the system rather than through it, and the component library that was supposed to consolidate debt instead becomes another layer of debt sitting alongside the existing one.

What separates a design system that survives from one that doesn’t is rarely technical. The token architecture can be well-structured, the components well-built, the documentation thorough — and the system can still fail if the organisational conditions for adoption are not deliberately designed. Adoption has to be more clearly faster than non-adoption, or rational teams will find ways around the overhead. Contribution has to be lightweight enough to use under delivery pressure, or gaps in the system will be filled locally and never consolidated. Governance has to produce decisions quickly enough to be useful, or it will be routed around.

bp’s product portfolio had reached the scale where the cost of fragmented design was measurable: in handoff overhead, in onboarding time for new designers, in the rework that accumulated when inconsistent components were discovered late in delivery cycles. The problem was not that the individual squads were building poorly — it was that they were each building the same things independently, and no mechanism existed to consolidate those decisions into shared value.

Before any system architecture decisions were made, a structured audit was conducted across all five product squads — cataloguing every component in active production use, mapping the variations that existed across teams, and identifying where debt was most severe. The audit was not a design exercise; it was an organisational diagnosis. The goal was to understand the actual state of the portfolio, not the stated state.

Component-level duplication was more severe than any single team had visibility into. Each squad could see their own debt clearly; no one had visibility across all five simultaneously. The audit made the aggregate visible — and made the case for a shared foundation in concrete operational terms rather than design principle arguments.

Interviews with designers across squads surfaced the workflow cost of the fragmented state: the time spent reverse-engineering other squads’ components when work required cross-product consistency, the overhead of maintaining squad-specific documentation for patterns that every team needed, and the recurring tension between delivery speed and visual quality when no shared component existed for the thing being built.

The audit also identified which components had converged naturally across squads — cases where teams had independently reached similar solutions — and which had diverged most severely. Convergent components became the first candidates for consolidation; divergent components revealed where the design problem was genuinely unresolved rather than merely under-communicated.

The governance model was the product. The component library was evidence that the governance worked. A system without contribution workflows eventually becomes a snapshot — correct at launch, increasingly outdated as products evolve around it. The governance model was what made bpCore a living system rather than a well-documented starting point that squads forked on day one.

The core design decision was incentive over mandate. Teams were never required to adopt bpCore — they were given strong reasons to want to. The first reason was time: using a bpCore component was consistently faster than building an equivalent from scratch, because it came with tokens, accessibility, documentation, and a code implementation already resolved. The second reason was quality: the review process that governed contributions meant every component in the system had been validated to a standard individual squads rarely had time to apply under delivery pressure.

Contribution was treated as a first-class workflow, not an afterthought. When a squad hit a UI requirement not covered by the existing component library, they had a clear, lightweight path to propose it for inclusion. Proposals were reviewed against explicit criteria — semantic correctness, accessibility compliance, token alignment, usage generalisability — and decisions were documented publicly regardless of outcome. A rejected proposal with a documented rationale was more useful to the squads than an approved one that had been accepted silently.

Cross-squad visibility was built into the governance process from the start. Contribution proposals were visible to all squads before decisions were made — which surfaced cases where multiple teams had independently identified the same gap, and allowed combined input to produce a better-specified solution than any single squad would have produced alone. The process created cross-squad communication that had not previously existed.