Bank Islam finances students’ studies and wants to keep them as customers for life. Yet the current app offers few ways to pay a bill, and it feels dated. I designed Pay Bills for its desktop and mobile apps: JomPAY, saved favourites, new bills, card and financing payments. I prototyped every flow and tested the shared patterns with 9 users.
Bank Islam was redesigning its two digital channels, internet banking on desktop and the GO mobile app.
This case study covers one piece of that work: how customers pay bills.
Young users, Muslim and non‑Muslim, with a focus on students and fresh graduates.
Bank Islam gives them financing to study and wants them to stay as loyal customers after they graduate.
Pay Bills and the spending report
Out of scope: transfers, registration, and GO Dreams and Invest, covered in other sprints.
A short list of entry options
Tiles such as Own/Other Account and DuitNow.
Everything else sat behind DuitNow
Favourites in a long list under a search box. New Transfer opens a list of ID types, from mobile number to passport to account number.
Organised by how money moves
Not by what the customer wants to pay.
These are my observations from the screens, not findings reported by users.
Students and fresh graduates need to pay bills easily, but the current app gives them few options, organised by how money moves rather than by what they pay, makes them re-enter payee details every time, and feels dated.
We followed the Double Diamond model: Discovery, Definition, Development and Delivery.
The handwritten kick-off notes capture the starting point: the brief, who the users are, and the plan.
We started with video-call interviews to learn users’ pain points, then ran exploratory interviews on feature enhancements, new services and UI changes.
Interviewed over video calls.
Students and graduates.
Pain points, feature enhancements, new services and UI changes.
One empathy map, built from all 7 interviews.
She prefers banking apps for her transactions, and loves deals, travel and local brands.
Pay bills and other dues easily
Make cashless transactions seamlessly
Check her balance weekly and her daily transactions
Julia’s journey, mapped step by step, showed where banking gets in her way. The low point is step 7, when she pays her bills: “why it’s not easy to pay, why so many clicks”.
People pay for different reasons
“Hanging out with friends for lunch and pay them using the app”
Repeat payments take repeat effort
“Feels frustrated when I have to add the payee details every time”
Paying should feel as easy as messaging
“Money transfers and bill payments should be no more difficult than sending a message on Whatsapp”
People want to know where their money goes
“I wish I can have a weekly summary of my expenses”
Spending should give something back
“Why aren’t we get rewarded for spending money :D”
The design feels old-fashioned
“Design is not so much appealing, old fashioned”
Quotes are from the empathy map built from all 7 interviews.
How might we help students and fresh graduates pay the different people and bills in their lives as easily as sending a message, without re-entering the same details every time, and stay on top of their spending?
Pay Bills inherited one question from the Fund Transfer work: where should saved payees live? These are the patterns explored there, next to the one Pay Bills uses.
| Criterion | A · Bottom sheet | B · Favourites inline | C · Dedicated step (chosen) |
|---|---|---|---|
| Repeat payments | Favourites are not on this screen, so they cost an extra step. | Fastest: favourites are visible on arrival. | One extra tap, then a full list. |
| Entry screen clarity | Clean: a few options only. | Crowded: options and a favourites grid compete. | Clean: five routes, nothing else. |
| As favourites grow | Not applicable. | The grid pushes content down the screen. | The list can scroll, search and be managed. |
| First-time payers | Clear. | Favourites can distract from New Bill. | Clear: New Bill and JomPAY are first-level routes. |
| Desktop and mobile | A bottom sheet does not map to desktop. | A grid is cramped in a side panel. | The same steps work in the desktop side panel. |
A qualitative assessment from reviewing the screens. It was not measured in testing.
Icon tiles that start with how money moves.
One screen with five labelled routes.
A favourites list under a search box.
A dedicated Favourites step with names and logos.
A verify screen, then a separate Approve step.
One review card, then an i-Access code.
One Pay Bills screen leads to every way of paying: Favourites, New Bill, JomPAY, Pay Card and Pay Financing. Each route is short, and ends with a review and a success screen.
Pay Bills opens as a side panel over the dashboard, so people keep sight of their accounts while they pay. Favourites and New Bill follow the same steps as on mobile.
A shared design system keeps desktop and mobile consistent, covering typography, a component library and an icon set — ensuring the same visual language across desktop and mobile.
Moderated sessions on high-fidelity prototypes, on mobile and desktop.
9 people in two groups, students and graduates, aged 17 to 30.
A short interview, then a scenario task. After the task, people rated ease from 1 to 5 and told us what they liked and what to improve.
Sending money to a payee, on the mobile and desktop journeys.
Paying bills, and sometimes financing, is part of their routine.
They wanted saved payees, grouped by type, and a clearer favourite button.
Clicking Next many times felt long. They preferred fewer pages.
I designed and prototyped Pay Bills across both channels, then handed the designs and recommendations to the client for implementation.
Favourites, New Bill, JomPAY, Pay Card and Pay Financing.
Favourites and New Bill, in a side panel.
A spending summary by category.
One for mobile and one for desktop, in the Final solution section.
Findings shaped refinements. Post-launch data was out of scope.
Thank you for taking the time to read this case study.
