A global betting platform needed to speak Kenyan — football-first, M-Pesa ready, and built for a market where sports betting is deeply cultural.
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.
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.
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.
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.
"Live" became a navigation destination, not just a filter. One tap from anywhere to see what's happening right now.
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.
Showing sports content even in the logged-out state builds trust — users can see the product works before creating an account.
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.
Don't translate a product. Rebuild the money flow from the user's mental model outward.
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.
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.
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.
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.