Case 01 · pawabloX · Under NDA
One system, seventeen markets
One design system across seventeen markets, shared by design, engineering, QA, research and product — and open enough that anyone in the company could build with it.
- Role
- Head of Product Design & UX · system owner
- When
- Apr 2025 — present
- Where
- betPawa · 17 African markets
Challenge
Seventeen markets and no shared system. The same component existed several times over, and every team described it differently.
Approach
Foundations first, then components, then patterns — one library living in both design and code, with a standard each layer had to meet.
Result
Five disciplines working in one language. Dark theme, once quoted in months, shipped as a single release.
The problem
What was actually wrong
betPawa runs across seventeen markets, and years of legacy had left the same control living in several places at once, behaving differently in each.
The cost was not dramatic, it was constant. Every feature re-argued decisions a system should have settled, and any change that touched the whole surface was quoted in months — so nobody proposed one.
Before
After
My role
Who did what
Mine
- Set the direction: systems before screens, foundations before components.
- Defined the layers — variables, components, patterns, key pages — and the standard each had to meet.
- Opened the system up in Claude, so people could build with it instead of asking for it.
The team’s
- The design team built the layers out and owned their product areas within them.
- Front-end and engineering owned the system on the code side.
- QA and research defined the states and the evidence it had to cover.
Process
How it went
- 01
Start from what is in production
We audited the live markets rather than the library. The gap between the two was the real backlog.
- 02
Foundations before components
Colour, type, spacing and states first. Nothing is visible for weeks, which is exactly why most systems skip this and stay fragile.
- 03
One library, two homes
The same components in design and in code, so nobody had to translate between them.
- 04
Let everyone build with it
With the system inside Claude, an idea arrives as something you can click through instead of a document to be explained.
Before
After
Decisions
What was chosen, and what it cost
Foundations before a visible component library
- Over
- Having something to show in the first month
- Because
- A library on unstable foundations locks the inconsistency in, and every fix after that means moving everything again.
- It cost
- Weeks with nothing to demo. That is a plan you have to defend twice.
A system people could build with
- Over
- A design-only library with the usual handoff
- Because
- It changes who is able to make something. Ideas stopped being described and started being built.
- It cost
- A second surface to keep in sync, deliberately and on a schedule.
Outcome
What came of it
Five disciplines now use the same names for the same things, so far less gets re-explained at every handover.
Dark theme is the proof, not the goal: months of retrofit became one focused release, four months after the system existed.
Product, UX and tech share ideas as working prototypes now, so customer feedback arrives before engineering is committed.
Lesson
What it cost me to learn
Watching how the team used AI over several months, I saw us looping — prompt, fix, prompt again — and calling it progress. I wrote it up publicly as “The Dark Side of the AI Loop”. The advantage goes to teams who use AI to learn faster, not to produce more.