Design Thinking Exercise

My first UX case

Designing an app or, in my case, a tool for an existing app, can be really daunting, but with the help of the design thinking methodology, the process can become very fluid and intuitive. Here’s the story of how I created my first app.

1. The client

Let me start by providing some information about the company I was supposed to work for. Whole Bank is a traditional bank from Framingham (a small town in Massachusetts) that is slowly turning into a more technological and user — friendly bank. Its main goal is to offer its customers a different way to save and manage their money. Recently, it has set up an online app and now it offers innovative options such as the incorporation and use of virtual currencies to its customers.

The problem

Whole bank detected that the actual credit/debit system presents several inconveniencies for users when they travel: cards are susceptible to damage or loss and some shops only allow payment with one type of card (generally credit), which forces users to withdraw money from an ATM beforehand.

The idea was to develop a tool that allowed customers to pay without having a physical card exclusively when travelling.

And that’s where I came in.

In order to find a suitable solution for the company’s problem, I decided to follow the design thinking methodology. I started by setting the scene: I asked myself a few key questions to help me get a better insight of the current situation and to plan the next steps. These questions were:

• What problem are you solving?
• Who is your audience?
• Who is your client’s competition?
• What’s the tone/feeling?

2. User Interview

Once I located myself inside the problem, my first step was to interview some users to get real information. I set up the number of interviewees in 5, a number not too big to collect a vast amount of data, but enough to let me recognize patterns. I needed 5 people who had travelled and had used their credit/debit cards abroad to find out what their main problems were in order to define my problem statement and start working.

I started by devising the questions I would ask, which would be focused on finding out what were their habits when travelling (if they carried all of their cards with them, if they withdrew cash before travelling), their use of bank apps and their thoughts about paying via smartphone.

Then I set about interviewing. It was my first time and I have to admit that I was aware that I would experience some difficulties. To start with, I was concerned that my questions weren’t good enough, or that they didn’t provided the data I needed. I was also worried that my interviewees might be wary about disclosing personal/financial info with me. I also felt nervous about interviewing people because of my shyness, but as soon as we engaged in talking, all my nerves disappear. However, I came across some problems I didn’t foresee; first of all, it was quite a challenge to establish a date and time for my interviews (people are very busy and technical hitches might cause you to reschedule your interviews after juggling to find a date). It was also difficult to find a point in which I could listen and have a conversation with my interviewee and take notes at the same time, especially during the first interviews; I had to ask the person to give me some time to write down their answers, which stopped the natural flow of the conversation to the detriment of both me and the interviewee.

Despite all this, I was able to collect a valuable amount of data to continue my design process.

Some notes I took during interviews

3. Defining the problem

I extracted all the data from my interviews and I was able to recognize some patterns as well. I pinned down my user’s pain points and made interesting findings. I was also able to differentiate two groups of users: mobile advocates (those who use bank apps and think that paying with their smartphones is perfectly safe) and traditional users (those who don’t trust bank apps and will keep using their cards because they don’t trust smartphones). Here are some of my findings:

Pain points

1. Problems with debit cards abroad (which ended in a compulsory use of a credit card or the withdrawn of money from an ATM)
2. Reluctance to use bank apps and paying via smartphone for security reasons
3. Shops/banks apply a currency change different from the official

Other findings

• Not everybody owns a credit card
• General unawareness of NFC technology
• Some people don’t carry their cards with them when travelling (only money)
• Asking the type of currency in which to pay would be appreciated

After writing and processing all the information, I reviewed the requirements from the company in order to define a problem statement. Whole bank already had an app available in which the user logs in (with personal credentials or fingerprints if available) and they’re able to consult their financial information and perform some tasks such as wire transfers, blocking lost/stolen cards and applying for loans. The company wanted a feature for that app that allowed payment. They also wanted the app to be used at the point of purchase like an ordinary card without entering any data when paying/checking out (the information would be already on the platform). At that stage, I also should forget about security issues.

With all that in mind, I defined my main problem to solve: to devise a way to pay abroad via smartphone to avoid travelling with credit/debit cards (and the problems that go with them), easy and safe enough to encourage bank customers to use it.

4. Ideation

Once the problem was identified, I moved on to find a suitable solution. I started by doing a quick brainstorm. I wrote down several ideas that might solve the problem without any kind of restriction. Then, I revised them (keeping my requirements and user’s pain points in mind) and wrote a couple of disadvantages for each one in a different colour. Highlighting the disadvantages helped me weighed them up to select the best ones for further developing. These preselected ideas were: payment via NFC, payment via pin code and payment via barcode.

I wrote down how they might work and drafted quick user flows for each one of them, illustrating the steps a user would have to take with very basic icons. This helped me get a better understanding of each method, visualize the number of steps needed to complete the payment and assess the level of difficulty of each option. Once more I wrote next to each preselected solution a few drawbacks that needed to be considered when selecting the final idea to develop. Here are a few of them:

• NFC: technology not available for all smartphones, unknown to many users, not well spread through shops.
• Pin code: users would have to memorize a number to enter in the payment terminal and the requirements established that no data should be introduced when paying
• Barcode: readability difficulties for scanners, technology not available in all shops

To finally select an idea, I jotted down the advantages and disadvantages of each option. I gave special importance to choose a payment method that was fast, easy and simple, so that it could truly became an alternative for credit/debit cards. Also, the disadvantages should be as little as possible. Therefore and after too much consideration, I ended up choosing the barcode method.

Brainstorming and selection

5. Prototyping

Before start sketching any screen, I thought carefully of how the process would work and I wrote it down to be able to check its functionality. The idea is that the user creates a “virtual card” that is linked to a bank account of their choosing and that works both as credit and debit card, avoiding problems at shops. Whenever the user wants to use the it, the app displays a picture of a card with a barcode of the number that the cashier scans to make the payment. It also includes the card number in case there’re problems when scanning and it needs to be entered manually. Once the user has accepted the payment, the money is withdrawn from the account. Since the user has to log in to the app every time they want to use it, there’s no need for further personal verification when paying. The app can also detect the country the user is making a payment from and allows them to choose between currencies if it differs from the user’s. I named the service Travel wallet, because its main goal is to become a replacement for physical cards (and therefore wallets), providing everything the user needs when travelling.

Once I refined the process, I created a journey map to illustrate how an user could activate the service and how to use it afterwards.

How to hire travel wallet:

The user logs in the app, which takes them to the home page. There, they select the travel wallet option. The first time the user enters, there’s an explanation of the service and later the user is asked whether they want to hire the service or not. To complete the service’s setup, the user is asked to:

1. select the account the card will be linked to
2. introduce their credentials (coordinates card or whichever system the bank uses)
3. introduce a pin code sent via text to the user’s phone number
4. the card is ready to use

The user can now choose between start using it or go back to the home page.

How to use travel wallet:

The user logs in the app, which takes them to the home page. There, they select the travel wallet option. Now it has been hired, the user is offered the option of getting the card: a picture of the card appears with the user’s name, the card’s number and the barcode. The cashier scans the card and a new screen will appear on the app showing the bill (all items to be purchased and total amount) and asking the user to confirm or cancel payment. Whenever available, a currency screen would appear before this last screen to let the user choose the currency they want. Whether the payment has been cancelled or confirmed, a new screen appears to ask the user if they want to start again/keep shopping (taking them to the card screen) or to go back to the home page.

That’s how fast and simple using travel wallet is!

The last step was to prototype a few screens. I illustrated both processes mentioned before: how to hire and how to use travel wallet. I draw the screens on dotted paper to help me give the same dimensions to all screens and to help me arrange and lay out the content I wanted to include more easily. Here’s the result.

6. Conclusion

The design thinking methodology has helped me a lot during this exhausting yet satisfying process. It has helped me structure my messy thoughts and ideas to build a product step by step from its foundations to the (rough) details. Through this first contact with the UX world, I have learned some things that I reckon might be useful in the projects to come:

• User interview is vital: it’s the key to understand the people you’re designing for (what worries them and that they need). Asking the right questions it’s just as important.
• Keep requirements and user’s needs present at all stages of the design process: this will prevent you from losing sight of what you want to accomplish.
• Brainstorm freely and then add your restrictions: write down every idea that comes to your mind, no matter how crazy it might be. Then, apply your limitations (defined by both your client and users) to value it’s feasibility.
• Write things down before start drawing: writing things helps your brain making sense of all the ideas stuck inside it and makes it easier to detect problems before putting effort into creating screens.