Home Work Experiments About Me
UX Design Market Localisation Mobile Web Shipped

Localizing BC.Game
for the Kenyan market

A global betting platform needed to speak Kenyan — football-first, M-Pesa ready, and built for a market where sports betting is deeply cultural.

Client
BC.Game
Role
Contract UX Designer
Duration
2 Weeks
Deliverable
High-fidelity designs + Dev handoff
BC.Game logged out state
BC.Game Kenya redesign
BC.Game scrolled state

A global product that didn't speak Kenyan

BC.Game had secured a licence to operate in Kenya — one of Africa's most active sports betting markets. But their global product was built for a different audience: heavy on casino games, crypto-native, and designed around a global palette of sports.

Kenya is different. Football dominates. Bettors want to see today's matches immediately. M-Pesa is the only payment method that matters. And the top local platforms — Sportpesa, Betika — had already trained users on how a betting app should feel.

My job was to redesign the interface so it felt native to Kenya, without rebuilding the underlying product.

2wks
From brief to full design handoff
3
Competitor platforms analysed
2
Core states redesigned (logged in + out)
🇨🇳↔🇰🇪
Bilingual design notes for Chinese dev team

The gap between global and local

❌ Before — Global Design
BC.Game original global design

What wasn't working for Kenya

  • Casino games front and centre — not relevant to the Kenyan bettor
  • Sports buried below casino, poker, racing, lottery
  • No football-specific surface or live match feed
  • Generic global hero banner with esports imagery
  • "Recent Big Wins" showed crypto jackpots — unfamiliar to local users
  • Bottom nav: Menu, Explore, Casino, Sports, Chat — sports not primary
✓ After — Kenya Localisation
BC.Game Kenya redesign

What changed for the Kenyan market

  • Soccer surfaced as the primary category in top navigation
  • Live matches and today's fixtures front and centre on load
  • Highlights / Today / Upcoming tabs — matches Sportpesa/Betika patterns
  • Live match scores and betting odds immediately visible
  • Bottom nav reordered: Home, Sports, Live (24), My Bets, Casino
  • Separate logged-in and logged-out states designed for conversion

What I changed and why

01

Football first, everything else second

Competitor analysis of Sportpesa and Betika showed a clear pattern: football is always the landing experience. Kenyan bettors don't browse — they come with a match in mind. The navigation needed to reflect that mental model immediately, not after scrolling past casino games.

Insight from research

Both Sportpesa and Betika surface live football scores and today's fixtures above the fold. This is the expected pattern Kenyan users are trained on.

02

Surfacing live — always

Live betting is huge in Kenya. The original app buried live games in a tab. I made it a permanent fixture in the bottom navigation (Live 24) so users could jump to it instantly from anywhere. The live match scores with real-time odds became the anchor of the homepage.

Design principle

"Live" became a navigation destination, not just a filter. One tap from anywhere to see what's happening right now.

03

Two states, one conversion goal

I designed the homepage as two distinct experiences — logged out and logged in. The logged-out state is entirely focused on getting the user to sign up: clear CTA, immediate value visible. The logged-in state shifts to helping them bet faster. This distinction matters because Kenya has a large casual audience who needs convincing before committing.

Design decision

Showing sports content even in the logged-out state builds trust — users can see the product works before creating an account.

04

M-Pesa as the primary payment path

The global platform was built around crypto deposits. In Kenya, M-Pesa is how money moves — it's not a payment option, it's the payment option. The deposit flow needed to lead with M-Pesa, with a familiar USSD-style input pattern that Kenyan users already know from every other financial app they use.

Localisation principle

Don't translate a product. Rebuild the money flow from the user's mental model outward.

Designing across a language barrier

The development team building this product was based in China. They spoke Mandarin. Design annotations in English weren't being picked up correctly — nuances were getting lost, and implementation was drifting from intent.

So I added Chinese annotations directly to my design files alongside the English notes. Using AI translation tools, I was able to communicate design decisions, rationale, and interaction details in both languages simultaneously.

It wasn't just about translation — it was about making sure the devs could build what I meant, not just what they read. The handoff became a bilingual document, and it worked.

Design file with Chinese annotations
Actual Figma working file — meeting notes and design discussion written in Mandarin for the Chinese dev team.

What this project taught me

🌍

Localisation is not translation

Swapping language labels isn't enough. True localisation means rebuilding the product's information hierarchy around local behaviour — how people pay, what they care about, what they expect to see first.

Speed requires constraint

Two weeks forced ruthless prioritisation. The homepage is where Kenyan users decide if they trust the product. That's where all the effort went. Getting one screen deeply right beats getting five screens done.

🤝

Communication is a design skill

Adding Chinese annotations wasn't an afterthought — it was the difference between a design that got implemented correctly and one that didn't. Meeting your audience where they are applies to developers too.

Next Project
AI Tool for Humanitarian Operations — UNDP Somalia