IBM iX · Swiss private bank · PrimeVue
Swiss private bank design system
Ten products, one bank.
A private bank's customers re-learned the interface every time they opened a different product. I audited the estate, chose the system the team would actually adopt, and wrote the governance that keeps it from fragmenting again.
- 10+Products audited
- 1stGlobal navigation standard
- 5–10Foundational components
Confidentiality Client work delivered through IBM iX under NDA. The institution is anonymised and all product branding is removed. Structure, audit findings and the governance model are accurate; visual identity and product names are not shown.
01 Problem
In private wealth, coherence is part of the product.
Ten digital products, each on its own legacy foundation, each with its own UI, navigation, colour and type. No global navigation layer at all. Individually every product worked. Together they didn't feel like one institution.
A customer moving between products re-learned the interface every time, which hurt findability and accessibility. In private banking, that inconsistency doesn't read as a design problem. It reads as carelessness.
What was asked for
- "Our products look inconsistent. We need a shared component library."
What was actually needed
- A library alone re-fragments within a couple of releases unless someone defines who decides what, and how fast.
02 Discovery
Making fragmentation countable.
You can't argue for consolidation with an opinion. With the junior designer, I ran a heuristic audit of every product against Nielsen's ten heuristics with WCAG observations, working from screenshots gathered in client interviews, alongside research comparing internal and open-source design systems.
The audit had a second job: separating divergence that existed for a real reason from divergence that was just residue.
- Divergence with no reason ConsolidateResidue, not a decision. Most of what the audit found.
- Divergence with a real constraint Theme itTeams that diverged for a reason keep it, through the token theme.
- Genuinely product-specific Leave aloneSome differences are the product.
Most of the divergence wasn't a decision anyone made. It was residue.
The middle bucket is the one audits usually get wrong. A team that diverged for a real constraint will resist consolidation, correctly, and theming exists precisely for them.
03 Decision
Why PrimeVue, and not something more elegant.
| Option | Vue.js native | Client licence | Developer familiarity | Themeable to brand |
|---|---|---|---|---|
| PrimeVue | Yes | Already held | IBM team fluent | Full token theming |
| Build bespoke | Yes | Not needed | Learning curve | Total control |
| IBM Carbon | React-first | Open source | IBM standard | Strong IBM identity |
| Vuetify | Yes | Not held | Unfamiliar | Material identity |
Three reasons, none of them about taste:
Vue.js platform
The platform commitment was already made by the business and the development team.
Existing licence
The bank already licensed PrimeVue.
Team familiarity
The IBM developers already knew it. Bespoke would have consumed the four months in foundations.
04 Governance
The deliverable most design systems skip.
A component library is an artefact. A design system is an agreement about how decisions get made. Without the second, the first decays: a team hits an edge case under deadline, builds a local variant, and the estate quietly re-fragments. That's how the bank arrived at ten interfaces in the first place.
| Deliverable | What it covered |
|---|---|
| Usage guidelines | When each component applies, and when it doesn't |
| Do's and don'ts | Written so a developer with no design background can self-check before review |
| Global navigation standard | The cross-product layer that had never existed |
| Accessibility baseline | WCAG enforced at component level, not left to each team |
The compliant path has to be the fastest path.
05 The pushback
Engineering said it was too expensive. They were right.
Consolidation is real work with no feature output. A quarter spent on foundations is a quarter of roadmap the business doesn't get. Told that way, it's a bad trade, and engineering was right to resist it.
So I stopped arguing consistency, a design value nobody outside design is obliged to hold, and argued cost. Ten variants of the same component means every fix made ten times or not at all, every developer onboarded to ten conventions, and accessibility re-litigated per team in a regulated institution. None of that appeared on a roadmap, which is why it never got weighed.
A phased path closed the argument: 5–10 foundational components first, enough to prove the system and small enough to be judged on evidence.
06 Team
Two designers. Four months. Ten products.
The obvious move is to hand a junior designer the repetitive audit work. Instead I gave them whole components (form elements, card variants and the navigation component) reviewed against the system rules rather than my own taste. That meant writing the rules well enough that someone could apply them without me in the room. Writing governance for a junior designer and for the bank's future teams turned out to be the same exercise.
07 Outcome
Phase one, honestly scoped.
- Delivered
Branded theme
A customised PrimeVue theme with brand tokens for colour, type and spacing.
- Delivered
Foundational components
Five to ten primary components, themed to the tokens.
- Delivered
Governance document
Usage guidelines, do's and don'ts and the global-navigation standard, for designers and developers.
Reflection
The unglamorous deliverable was the real one
The library demos well. Governance decides whether it stays true after the second release.
PrimeVue over bespoke was right
Designing for what a team will adopt, on a stack it already trusts, is most of the job.
Baseline adoption from day one
An unmeasured system is the first line item questioned when budgets tighten, and a baseline is very hard to reconstruct later.