Bangladeshi migrant workers in Malaysia needed access to financial services — money transfers, bill payments, staying connected with home. The problem was that every existing solution assumed things these users didn't have: a smartphone capable of running apps, reliable internet, enough data budget to spare, comfort with digital interfaces, and often enough literacy to navigate text-heavy screens. Traditional fintech had built for a different user entirely. The brief was to create something meaningful for people with basic Android phones, slow connections, limited data, and no appetite for complexity — and to do it through a browser link, because asking users to install an app was already one step too many.
I spent time with migrant workers in Malaysia before designing anything. Not surveys first, not personas — actual time, watching how they used their phones, listening to what they were trying to do and where they gave up. What came back wasn't a user journey map. It was a clearer picture of what trust looks like for someone who has never used mobile banking before and has real money and real family depending on getting it right. I designed an MVP based on that research, tested it with real users in field conditions rather than lab settings, and got a result that was genuinely useful: seventy percent of users disliked it. That feedback reshaped everything that followed.
We eliminated app installation entirely. Everything had to work through a single shared browser link — no app store, no registration friction, no download on a slow connection. This was the foundational constraint that shaped every other decision. It also meant building something that felt like an app but ran in any browser on any basic device, which required a different technical approach to component design and asset optimization.
After user testing showed 65% preferred consistent box layouts over creative arrangements and 60% preferred darker colors, we rebuilt the visual language entirely around what users had actually shown us — not what looked better in Figma. Familiar faces in imagery over abstract illustration. Structured grid over expressive layout. Dark theme over light. These felt like regressions from a design craft perspective. They were improvements from a user reality perspective.
Bangla language support was treated as a structural requirement, not a translation layer added at the end. Language wasn't just about readable text — it was about cultural familiarity in every interaction pattern, every piece of imagery, every content choice. Users who had never used mobile banking needed to feel that the product understood their context, not just their words.
The final version that shipped was a compromise between what users preferred and what the telco partner required. The user-favored version — darker, more familiar, more culturally resonant — couldn't fully launch due to partner policies and vendor requirements. We shipped what was viable rather than what was optimal. The results were still strong. But this was the clearest lesson of the project: the best design for users isn't always the design you get to ship.
increase in service adoption, including first-time digital financial service users
Service adoption increased 32% after launch, with a meaningful portion of that growth coming from people using digital financial services for the first time. Customer complaints dropped 30% — a direct signal that the interface was making sense to users who had previously found similar tools confusing or inaccessible. Cross-service engagement grew 6.5% as users who gained confidence with one feature started exploring others. These numbers came from a compromised version of the design. The user-preferred version never fully shipped. The results suggest what a less constrained implementation might have achieved.
The hardest lesson here wasn't about design — it was about the gap between what users need and what business partnerships allow. We had clear evidence of what would work better for users. We couldn't ship it. I'd approach the partner and vendor alignment earlier in future projects of this kind, treating business constraints as a design input from the start rather than a late-stage filter on decisions already made.