Design a Mobile Payment Service
Prework 2 of Ironhack UI/UX design bootcamp
The Problem
Whole Bank, my fictional client, detects that traditional credit/debit cards show big inconveniences for traveling customers because they might lose cards or the cards get stolen on the way. Therefore, the bank would like to develop an app to let customers pay without using physical cards.
The Goal
The goal was to create a payment feature on the bank’s existing mobile app that allows customers to pay for things using the app.
My Process
I followed Design Thinking process to identify pain points through user interview, define problems, brainstorm ideas and create low-fi prototype.
Step 1: Empathize
I interviewed five people about their experience using cash and credit/debit cards abroad. I selected people who travel abroad at least once 3 months.
Interview Questions
Background questions: Age, occupation, frequency of travel, travel destinations, how to prepare money for travel, experience of using mobile banking app.
Experience of payment while traveling: What activities do you usually do during the trip? How do you pay and why? How do you like and dislike the payment methods you used? Have you met any trouble with payment while traveling? How did you solve it?
Experience of mobile payment: Have you tried any mobile payment? If yes, how do you like and dislike it? If not, how do you feel about mobile payment? How do you prioritize these three payment methods: cash, card, mobile payment (assuming all without transaction fee)? Will you still bring cards while you have mobile payment and why? What is an ideal mobile payment app for you?
I tried to make the interviews loosely bounded and asked open-ended questions without leading users to certain answers.
Personas
After the interviews, I identified two types of personas: Card Lover and Cash Lover.
Step 2: Define
These are the pain points I discovered through the interviews:
- It’s troublesome to carry cash.
- Cards have transaction fee.
- It’s not easy to acquire cash abroad.
- Existing mobile payment (Apple Pay) is not easy to use.
Users also suggest that an ideal mobile payment should be:
- Easy to use like a metro card. They can pay with just one touch.
- Secure. Requires password or fingerprint.
- Can be used in as many places as possible.
- No transaction fee.
I decided to address two main points that matter most to users in the new payment feature:
- Easy and convenient to use, simulating metro card experience.
- Secure but not at the expense of convenience.
Step 3: Ideate
After defining the problems to solve, I moved on to planning how to solve them. First, to simulate the metro card experience, let’s see how users use metro card (see below). Some users would skip the step in purple because they touch machine directly with their wallet or a separated card holder. Therefore, it means that I should try to make the task flow of new payment app within five steps.
Task flow of new payment feature (see below): after users turn on phone without unlocking it, they swipe left to access QR code scanner linked to the bank’s app (assuming it’s possible technology-wise) and then scan to pay. The feature acts as a shortcut to the payment function of the bank’s app so that users can pay quickly without taking the traditional path (turn on phone, unlock it, click the app, click the payment button and then pay). However, users can still access to the payment function in the parent app if they already unlock the phone.
To address security issue without sacrificing convenience, I added a design in Setting page that users can set the maximum price they are willing to pay without fingerprint in order to speed up the process for small amount of transactions. I also added a button in QR Code Scanner page that users can choose to pay with another card.
Step 4: Low-fi Prototype
Conclusion
Through following Design thinking process, I was able to identify pain points and user needs and create a solution to solve the problem. The next steps will be to do the usability test with a live prototype and iterate until I find the best solution.
Things I learned
- Acquire users for interview from day 1! (Yes, even before designing interview questions.) I started to find users after I finalized the questions. However, it took me a while to schedule the meetings and users might not be available at the time I wanted and that delayed the project. Also, some users canceled the appointments or postpone them during the process. Therefore, it’s better to acquire users early on.
- Design user interview questions and conduct the interviews without leading to certain answers.
- Consolidate interview findings and create personas
- Create low-fi prototype and design the workflows.
