Improving the payment experience for credit cards on the DBS digibank app


This project is done in collaboration with two other incredibly talented UXDI students, Ken Lee-Sanekata and Koh Khai Liang from whom I’ve learned tremendously. You may access the video link to our prototype at the end of this post.

We acknowledge that some of these proposed changes could be radical and may not necessarily adhere to strict requirements set by the Monetary Authority of Singapore (MAS) and the bank itself. We also neither considered the intricacies of implementing it into existing legacy systems nor the interdependencies between the different departments within DBS—knowledge and data we do not have access.

Our Design Process

We managed the design flow in three distinct phases: Research, Analyse, Prototype.


Our research phase can be summarised in three different steps: finding out about DBS, running a task analysis, collecting public reviews and conducting user interviews.

From the start of the project, we knew it was going to be a difficult, as evidenced by the number of accolades the bank has received in the areas of digital transformation and mobile banking. Surely, those awards have to mean DBS has done extremely well in their digital transformation efforts.

Task analysis
We conducted a task analysis to determine the frequency of a task people typically do when logged into their DBS mobile banking account. We did a time-boxed exercise in which we first brainstormed individually some everyday tasks, based on our own experience, of having used mobile banking.

Then, as a group, we discussed, grouped and agreed on the list of tasks we will be asking existing DBS/POSB users to rank in order of frequency. We wrote the tasks on post-its, recruited some users, and informed them that could add a new task if it weren’t in the set of cards.

The result of this exercise can be seen below.

We observe, from having spoken to five users, that the typical user expects to do the following on mobile banking:

  • Transferring funds from one account to another (both DBS and non-DBS)
  • Checking account balances
  • Checking unbilled and billed transactions (debit & credit cards)
  • Paying their bills (via GIRO, bill payment system, etc)

Public reviews
We thought it was important to understand the public sentiment of the current mobile application. We collected data from various public sources such as specific articles posted by DBS on their Facebook page, tweets, as well as app store reviews from Apple Store and Google Playstore.

Grouped insights from public sources such as Facebook, Twitter and App Stores

User Interviews 
Knowing now the common tasks and having built an understanding of the current challenges users faced based on public sources, we formulated our user interview questions in the following areas:

  • How frequent do they use online banking (desktop and/or mobile);
  • What do they do and how do they do it;
  • Past experiences of fund transfers, bills payment, new credit card applications, requesting for waivers, etc.
  • The last visit they made to a physical bank branch and for what reason
  • How they track their account balances and spending habits

Our goal was to elicit as much behavioural data as we could about the person’s online banking experience. As the questions were general, and not necessarily DBS-specific, we also interviewed non-DBS online banking customers.

Running our user interviews

The result of our user interview can be seen in the below affinity maps:

Affinity mapping of our users behaviour’s in two areas: iBanking (or online banking) and credit card
User personas for the typical online banking customer (left) and credit card owner (right)

Usability Test on the Current Mobile Application

We conducted a usability test on the current application and found the following:

  • Users preferred to have a simpler authentication process (e.g. login, fund transfer, adding payee)
  • Users feel that the visibility of the credit card details can be improved (e.g. sometimes, users scroll past without realising they had gone past the date they are interested to find out about)
  • Users feel disabled without their dongle when using certain services within the app

For this project, we decided to focus on Matthew — specifically, in the area of making credit cards payments because we believed that we could enhance his experience through visual and usability improvements.

Analysis for Process Flows

Matthew’s path to make payments for credit card bills

Currently, users can pay for their credit card bills via two pathways:

First pathway for both DBS and non-DBS cards via the hamburger menu
Second pathway for DBS cards only via the user’s dashboard

We reduced the two pathways to a single one. Taking inspiration from the first pathway, we combined both DBS and non-DBS credit cards into a single consolidated view. This way, users will not have to go to different parts of the mobile application to pay their credit cards.

Proposed user flow for the DBS mobile app

Matthew’s Journey to pay his credit card bills

Matthew’s Journey, pain points and potential areas of improvements


Creating the mockups for our interactive prototype

We began the rapid prototyping process with sketches on paper. In total, we had two different prototypes, Prototype 1 (P1) and Prototype 2 (P2), with each one having a different design and interaction framework.

The reason for having P1 and P2 was because we wanted to determine which of the two prototypes users preferred to use when we eventually conduct the usability test.

P1 with annotated comments
P2 with annotated comments

Running a usability test on the two prototypes

We ran a usability test to find out about the obstacles our users face when using either one of the prototype. The key issues for P1 and P2 are documented as such:

  • The placement for the “Make a payment” button in P1 (and the current mobile app) was not obvious to users. We observed users going back to the home screen to find a button to make payment. We therefore needed to reconsider its placement. Following the principles of “mobile comfort zones”, we decided to place and pin the “make a payment” button at the bottom of the screen.
  • Users didn’t know they could change credit card once they arrive at the make payment page.
  • Lack of a visual cue on the “slide to pay” button resulted in users trying to slide up (instead of left as intended). We placed an arrow (of a darker shade of red) to indicate the direction they should slide in.

Combining the best from both prototypes into one

P3 with annotated comments. This prototype combines the best from P1 and P2.

Next Steps

  • Further develop Vanessa’s personas. We have developed a concept, however, due to time constraints, we couldn’t develop this prototype. The concept removes the dependency on the dongle when adding a payee; borrowing the idea of “share a contact”, a feature commonly found in phonebooks and Whatsapp, a “secure link” is generated by the sender and sent to the recipient. Clicking the link will prompt the recipient to add the sender as a payee.
  • An automatic categorisation of transactions. Users reported having insights into their spending will be helpful. Using machine learning, supervised classification can work great IFF there exists a dataset containing millions of transactions with categories assigned to them. If that is not available, I believe a combination of support vector machine and topic modelling might work. However, I suggest using supervised classification for its accuracy.
  • Better customer support. Users highlighted that customer service officers were sometimes hard to reach. Extending the existing callback feature (currently possible in the DBS website) as a “feature” (with certain form fields such as name and contact number pre-filled) in the mobile app might be helpful.


  • Make a conscious effort to consider the business goals. In the midst of satisfying user goals, I think at times, we forget to consider the business the goals. That is something I will work on in subsequent group work.
  • When in disagreement, always test the idea out. My team and I had differences in how we wanted to design the mobile app. We agreed to create two designs and run usability tests on it. I’m glad we did that — because P3 will never be a sole result of P1 or P2.
  • Collaborating can be hard. We all have a vision of the product in our heads. Communicate the ideas out into the open and actively listen.

Once again, thank you, Ken and Khai Liang, for bringing your visual design skills to this project and your patience. I couldn’t have done such a great high fidelity mockup on my own. I hope to get to work with both of you again — be it either for the final two projects or further down in our careers!

Prototype Video

Assets are built in Sketch and developed in Flinto.

Like what you read? Give Ridzwan Haron a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.