A shared organization, but not a shared system
BRI had five main product squads, along with other products, ad-hoc dashboards, and design contributors outside the department. The organization looked centralized, but each team had developed its own way of working.
Common components existed in several versions. Documentation was incomplete. Designers could not always trust the components they inherited, so rebuilding often felt safer than reusing. BRImo and Consumer Lending had also developed separate design systems, even though both belonged to BRI.
These two hero products show how teams built separate design libraries, resulting in different visual foundations inside the same organization.
A stronger library seemed like the answer. Before committing to it, I ran a workshop with product designers from different products and streams.
The workshop exposed three tensions
The discussion shifted the problem from component quality to the conditions surrounding the work.
- CapacityDesigners created local components to meet deadlines but rarely had time to maintain them.
- TrustComponents and documentation were inconsistent, and the implementation did not always match Figma.
- OwnershipTeams did not know when to contribute, who should decide, or whether system work should take priority over product delivery.
The workshop changed the brief. The library still needed work, but better components alone would not fix the conditions that had allowed the old system to decay.
The underlying question was no longer what to build, but how the organization would maintain it.
Two layers of the same system
To answer that question, I organized BRIdex into two connected layers.
What lived in Figma and code
System layer
- Foundations
- Components
- Documentation
How the organization maintained it
Operating layer
- Component workflow
- Reliability and maintenance
- Clear ownership
Both layers were necessary. Together, they connected the design assets to the people and decisions required to sustain them.
This reframed BRIdex from a library project into organizational work with time, ownership, and accountability.
BRImo as the pilot
BRImo was the first hero product to implement BRIdex. Its end-to-end revamp already required a new visual language across multiple streams, making it the right place to test the shared system.
I led a phased migration instead of replacing the legacy library at once. Designers and engineers audited existing components together. All design streams adopted BRIdex foundations, while coded migration began with Home, Payment, and Savings. Profile, Settings, and Help Center remained on legacy components until their turn.
- BRIdex foundations
- BRImo local components
- Revamped customer flows
- Reusable components contributed to BRIdex core
The transfer flow shows how both systems coexisted. Blue labels mark BRIdex components; black labels mark components kept in BRImo’s local library.
Input Amount: from local need to shared core
The audit found different Input Amount patterns across BRImo streams. I worked with cross-stream designers to define one version, built in the BRImo library with BRIdex typography and color.
Input Amount shipped in a customer-facing BRImo flow, then moved into the BRIdex core. It became our clearest example of a product component improving the shared system.
The pilot aligned design and engineering around one component direction. It did not migrate every legacy flow, and we did not measure time savings consistently.
What changed, and what did not
What changed
BRIdex moved from voluntary work to a departmental priority. I secured allocated capacity for six designers, defined clearer responsibilities, and helped the team release a shared foundation with documentation.
What remained difficult
Adoption remained partial. Many product maintainers continued using legacy local components. The OKR protected the central design team’s work, but it did not remove the migration cost carried by product teams. Without dedicated engineering ownership, implementation still had to be negotiated product by product.
What remained unmeasured
I defined measures around design time, development effort, onboarding, adoption, and prototype speed. The team did not establish a reliable baseline or collect the measures consistently. They show how I intended to evaluate BRIdex, not proof of business impact.
What I learned
BRIdex changed how I think about design systems. Library quality mattered, but it was not the hardest part. The harder questions were who had time to maintain the system, who paid the cost of migration, and what happened when shared standards competed with a product roadmap.
Securing the OKR made the foundation work possible. It did not solve adoption on its own.
If I approached the project again, I would establish engineering ownership and a migration plan earlier, alongside the component architecture.
People and moments
