All case studies Case 08 · Financial services
financial services 2021 to 2022

Same Button, Thirteen Ways

Building Wema's first design system, and learning to speak to a board.

  • Raises design maturity
  • Leads and develops people
  • Shapes strategy
  • Commercially aware
Where
Wema Bank
When
2021 to 2022
My role
Head of Service Innovation
Themes
Design systemsAccessibilityBusiness caseCoaching

13 to 1

versions of the same button

  1. 01Situation

    13 product teams had each built their own version of the same button, date picker, error message and form field. It was inconsistent for customers, expensive for the bank and patchy on accessibility.

  2. 02The move

    For the board, I put 1 slide with 1 number on it: the annual cost of the rework. For the teams, I ran an audit workshop where they found the duplication themselves, then built shared components that were simply better and accessible out of the box.

  3. 03Result

    Adoption climbed, the experience became consistent, the accessibility baseline lifted everywhere at once, and build time on new features came down, which was the number the board kept watching.

Exhibit 08

Thirteen buttons, becoming one

13 teams, 13 buttons, 1 number for the board, and the single button that replaced them.

Same button. 13 ways. Each one remembers which team built it, and when.
Jargon, explainedDesign systemWCAG double-AWhy states matter

The situation

At the bank we had grown fast, and growing fast leaves a particular kind of mess. We had around 13 product teams, and every one of them had, over time, built its own version of the same basic things. The same button, drawn 13 different ways. The same date picker, the same error message, the same form field, each reinvented slightly differently by a different team under a different deadline.

For customers it was inconsistent and confusing. For the business it was expensive, because every team was maintaining its own version of things that should have been shared. And accessibility was patchy in a way that was nobody’s fault and everybody’s problem, because no one owned the baseline.

I set out to build the bank’s first real design system.

Two audiences, two problems

I realised early that I had two completely different audiences and therefore two completely different problems to solve. The product teams were attached to their own patterns, the way people are attached to things they built themselves. And the board that would have to fund the work was non-design, and simply did not feel the pain, because the pain showed up as slowness and cost spread thinly across everyone rather than as a single visible fire.

Moving the board

For the board I stopped talking like a designer entirely. Design language does not move a budget. I sat down with our engineering lead and we costed the mess, honestly. Then I put up one slide with one number on it: what it was costing us every year to maintain 13 versions of the same handful of things, in pure rework. Design debt expressed as money, not as aesthetics. They understood it immediately, because it was in their language.

Moving the teams

For the teams I did the opposite of mandating. A system people are forced to use is a system people resent and quietly route around. So I ran an audit workshop where the designers themselves found the duplication, which meant the case for change came from them rather than from me standing at the front telling them their work was redundant.

Then I made the shared components genuinely better than what people already had, and accessible to double-A straight out of the box, with the states and the focus behaviour already handled so they did not have to think about it. That made adopting the shared version the easy choice rather than the imposed one. And I published the reasoning next to each component, not just the component itself, so that people could disagree with it properly if they wanted to, rather than feeling handed a rule.

The person I remember most

There was a junior designer on the team who kept folding whenever engineers pushed back on him in reviews. He would have a good position and then abandon it the moment someone senior leaned on it. For a while I had been rescuing him in the moment, stepping in to make his case for him, which felt kind but was actually keeping him small and dependent on me.

So I stopped doing that. Instead I started prepping him beforehand, helping him work out how to evidence his position so it could survive pressure, and then in the room I stayed quiet and let him hold his own ground. About 6 months later he was running his own reviews. That is the part of this project I am most pleased about, more than the components.

Outcome

Adoption climbed across the teams, the experience got consistent for customers, the accessibility baseline lifted everywhere at once rather than screen by painful screen, and build time on new features came down, which was the number the board kept watching.

The lesson

To move designers, make the right thing the easy thing. To move executives, translate design into their currency.

Research

How I found out .

Each method, and why I chose it.

  1. WhyIf I had presented the duplication, it would have been my opinion. When they found it, it was their evidence.

Who it was for

The people it had to work for.

Composite and anonymised. Needs and frictions kept, names removed.

Persona 1 of 4

The product designer

Built her team's button herself, under a deadline, 18 months ago.

Needs
Something genuinely better than what she has, with the states already handled.
Friction
Being told her work is redundant by someone at the front of a room.
What surfaced

Written on the
inside cover

  1. No one owned the baseline, so accessibility was patchy in a way nobody could be blamed for.
  2. The pain was spread thin across 13 teams, so no single team ever felt it enough to fix it.
  3. Adoption followed quality, not mandate. The teams that switched first did so because the shared version was better.
  4. Publishing the reasoning beside each component cut the arguments. People could disagree with a reason, not a rule.
Artefacts

What the work left behind.

The artefacts that stayed useful after I moved on.

Most of this is under NDA, so each piece is described rather than shown.

  1. 01

    Audit board

    13 button variants, clustered by the designers themselves. The exhibit's second stage.

  2. 02

    The money slide

    1 number, the annual rework cost, in the board's currency. The figure belongs to the bank, so the exhibit shows the shape of it and redacts the number.

  3. 03

    Component documentation

    Every component with its reasoning beside it. Redrawn page in the exhibit.

  4. 04

    Adoption dashboard

    Shared component usage by team, by month. The number the board kept watching was build time.

Outcomes

What changed, and what I keep.

13 to 1
versions of the same button, and of every other shared pattern
AA
accessibility out of the box on every shared component
Down
build time on new features, the number the board watched
6 months
until the junior designer was running his own reviews
Impact
  1. The accessibility baseline lifted across all 14 products and around 3 million customers at once, rather than screen by painful screen.
  2. Customers stopped seeing 3 different banks inside 1 bank's products.
  3. The board learned to read design debt as money. That made the next design investment a far shorter conversation.
  4. Service design playbooks and SOPs written alongside the system standardised discovery, blueprinting and measurement across teams.
Takeaways
  1. 01 To move designers, make the right thing the easy thing.
  2. 02 To move executives, translate design into their currency.
  3. 03 Stop rescuing people. Prepare them beforehand and stay quiet in the room.
What I would do differently

I would have costed the rework before the audit workshop, not after. The number was the thing that unlocked the budget, and I found it later than I should have.

Contact

Got a problem nobody has framed yet?

A service to fix, a programme that has stalled, or a proposition that needs shaping. I'd like to hear about it.

mubbyrobyn@gmail.com
LinkedIn
in/mubaraqrobyn ↗
CV
Mubby-Robyn-CV.pdf ↓
Based in
Reading, UK. Hybrid or remote.
Work status
Full right to work in the UK. BPSS eligible.