MTB Wallet Ecosystem

MTB Pay started with a question, not a screen. Our team was about to design a payment ecosystem for Myanma Tourism Bank — and none of us had built a payment product before. No amount of internal opinion was going to substitute for hearing from the people who'd actually use one.

So before anything was designed, we ran UX surveys in Burmese, focused on the flows that would carry the most risk: money transfers and wallet top-ups. We asked how people moved money today, which wallets they trusted and why, where top-up processes confused them, and what would make them hesitate to put money into a new app.

The answers were printed, clustered, and argued over as a team — and they became the base layer every later decision was built on.

With survey insights in hand, we mapped user journeys in FigJam — tracing how a customer would move from first open through KYC, their first top-up, and their first transfer, and where each step could lose them.

Those journeys became low-fidelity wireframes. And before a single high-fidelity screen was drawn, we put those wireframes in front of users for usability testing. Deliberately unglamorous — rough screens, real tasks — but it caught structural problems while they were still cheap to fix.

Only after the flows survived testing did we move to high-fidelity UI. By then, the risky decisions had already been validated.

The research kept pointing at the same truth: Myanmar runs on cash. People would try a digital wallet, but the moment they couldn't turn balance back into kyat at a shop nearby, they'd abandon it. A wallet alone was never going to be enough.

So the answer wasn't an app — it was three. MTB Pay, the customer wallet for transfers, top-ups, bills, and banking. MTB Pay Agent, the tool for shop agents who convert cash into balance and back, on the bank's behalf. And MTB Pay Admin, the web dashboard where MTB staff watch users, transactions, and the agent network in real time.

I owned end-to-end UX and UI across all three. The two mobile apps share one design system; Admin runs its own, built for the density a data-heavy dashboard demands.

Each product exists because of the other two. A customer tops up or cashes out through an agent — digital balance moves through the system, physical kyat changes hands in person at the shop counter. The agent is the doorway between the two worlds.

And because agents handle real money in the bank's name, the bank needs eyes on everything: every user, every transaction, every agent location. That's Admin's job — quiet oversight across the whole network.

Remove any one product and the system stops working. Designing one meant designing all three.

The customer app carries the widest audience of the three — from city users who've tried every wallet on the market to first-time users whose only banking experience is cash. That range set the design bar: every core flow had to survive someone using a payment app for the very first time.

The app covers the full everyday money loop — transfers, cash in and out, bill payments, banking, history, and profile. We designed each flow around the same principles the research surfaced: show people exactly where their money is going before they commit, confirm clearly when it's done, and leave a trail they can return to. Transfers and top-ups — the two flows our surveys flagged as highest-risk — got the most iteration and were tested at wireframe stage before any visual polish.

Trust shaped the visual layer too. This was a bank's wallet, not a startup's — the UI needed to feel official and calm, with the balance always legible, actions predictable, and nothing flashy standing between a nervous first-timer and their money.

Four designers, three products, six months to internal release. Nothing about that math works without a system underneath it.

I built the mobile design system that powers both MTB Pay and MTB Pay Agent — tokens, components, states, and interaction patterns shared across the two apps. One system, two very different tempos: the same components had to serve a nervous first-time wallet user and an agent processing a queue at a shop counter. Getting that right meant designing components around money legibility — amounts, confirmations, and transaction states that read instantly at either speed.

The Admin portal ran on its own system, built for data density rather than touch — I contributed to it, but it was primarily led by teammates. Splitting the two systems was the right call: forcing dashboard tables and mobile wallets to share components would have compromised both.