|Time||Jan 2018, Individual Exercise|
|Key Words||Financial Service
Design Decision Practice
If you don't do everything on your own, you must have heard one of following conversations:
Using Venmo to transfer money has been a common practice. Although unsmooth experiences wouldn't directly drive people away from the product as there are few competitive alternatives so far, maintaing seamless transaction process and help people accomplish small tasks more efficiently are key to continuous growth. Therefore, I redesigned the core pay/request flow for Venmo, aiming to deliver unique and faster service that enable users to finish cash exchange in a second.
Two intuitive ways to discover the respective quick entries for PAY, REQUEST and SCAN:
A. Swipe down as if you 're refreshing the News Feeds;
B. Tap on the upper-right button.
Improved low which makes on-click payment possible. No repetitive work for periodic payments like rents, utilities and tele plan!
Asking "why"s to understand the problem is always the prioritized task for a designer. Before jumping into solutions, I interviewd 6 frequent Venmo users to learn about their daily interpersonal transaction habits, and to hear about their loves and hates. As the tranding peer-to-peer digital transaction tool, Venmo makes cross-bank transaction possible, and relieves people’s pressure on asking money from friends.
In fact, digital transaction is no longer a novel stuff. There is a handful of platforms people could choose from. What's special about Venmo? According to my interviews and daily observations, I quickly summarizes the frequently used services similar to Venmo. Though the following map does not include all the possibilities, but it is enough for me to draw some implications:
Professional bank-based financial services, regardless of the potential transaction fees and processing time, are more reliable when it involves large-amount cash flow. They have an image of "official" and "safe", and it can happens between any party as long as they have the account. On the contrary, payment method embedded in SNS like iMessage and Messenger are tied to personal networks. It is "instant" and "friend-based". From my understanding, Venmo is in the between. It is an independent financial service that addresses efficiency just like many to-business products, however, in the meanwhile, it leans on social networks and has more humane elements like emojis and news feeds.
"fast" but "warm". I kept this as my principles while redesigning the product.
So, in what specific circumstances will people use Venmo and who are they?
As a frequent user myself, of course I've already have some thoughts on the product. One of the biggest challenges I faced in this redesign challenge is how I can, as a designer, jump out of the bubble created by my user identity and have a more holistic view. I tried to talk to as many people as possible during the limited time frame, so that I could either verify or turnover my personal assumptions. I divided major use cases mainly by two variables:
(1) Whether the payment / request goes to a single person or a group of people;
(2) Whether or not the transaction happens in both two parties' presence.
The number of involved parties and the using scenarios influence how the user flow should go. I have to be aware of all kinds of situations and use cases to implement inclusive design. When I was doing the redesign, I always kept these two varialbes in mind to make sure the refined pay and request process would not bring inconvenience to any of the major using scenarios mentioned above.
Redesign a flow is different from desiging a product from scratch because drastic changes do not necessarily bring positive outcome. A ideal redesign in my mind is solving problems without completely changing the product. To achieve that, I need to examine the exisitng product in detail:
What has been done well and what has not?
What's the potential rationale behind current design?
How do users feel about the experience?
What could be improved and what should be altered?
To answer these questions, I summarized my raw interview notes and did an affinity mapping:
Apparently, not all concerns are related to the core transaction task. Due to the time limit, it was impossible for me to tackle all the problems. I decided to draw out the current user flow for one transaction on Venmo, and then map out the people's complaints more specifically.
After doing above research activities, I was able to define the high-level design goals and drew out crucial design implications for more in-depth ideation.
First and foremost, I drafted a new user flow for the pay and request procedure.
Major changes include:
（1）Bringing forward the pay/request selection.Users have clear pay or request goals before they initiate new transaction process on Venmo. Also, this could prevent misoperation in the first place so users don't have to go back and forth when they tap on the wrong button during the process.
（2）Optimizing recipient selection experience. Users hope to have more comprehensible search results and find targets as fast as possible.
（3）Extending emotional experience for people who send out money. While many users think the News feeds feature on Venmo looks creepy and they seldom interact with other people's activities, there's an opportunity to utlize this feature and encourage recipients to respond to senders ———— senders need a sense of assurance.
Based on the new flow, I brainstormed design alternatives for the changes I'm gonna make. I tried to document all the ideas poping up in my mind, regardless of its quality.
Making design decisions withought enough validations could be hard. So, I need users input on my concepts. Due to the time limits, I quickly made low-fidelity mockups for key screens and showed the design alternatives to users. By involving users into the process, I could make design decisions with evidence.
As I mentioned before, users know whether they are going to pay or request money. What's more, the original icon button for initiating a new transaction is hard to understand for new users. Therefore, my first job shall be improving the learnability of new transaction entry. But how can I let them select the transaction mode at the very beginning without destructing the existing home page experience? Taking feasiblity and novelty into consideration, I selected two concepts from the rought conceptes I've generated:
Decision: Due to the time constraints, I was only able to consult with one design fellow and one user on the two design alternatives. Both of them voted for the plan A because they think it is more intuitive and keeps the interface clean. So I decided to move forward with it.
The user raised one question I didn't think about beforehand: he thinks the current entry for scan code is too difficult to find. If he has the QR code, the app shall enables him to directy open the scan function. It doesnt' make sense to hide the scan entry under searching people function. Also, in most cases, people would scan to pay but not to request. I took this advice into consideration and developed a new version of design:
One common complaints I heard from Venmo users, old or new, is that searching people is so hard.There are too many accounts registered with the same name. Though it allows people to enter @username, phone number or email, if the person you are looking for is not your Venmo friend nor in your contact list, you need to take one more step to seek the right one from a sea of similar names.
After comparing these three plans against with each other, I decided to merge plan A & B:
In addition to distinguishing two major transaction modes, another important step to fasten the process is to let users do less maths. Existing design actually allows users to directly do maths in the $ field, however, users hardly notice the mathematical symbols on the keyboard. Is there a better way?
In face, users' instinct was to input the final result rather than calculating during the process. When it comes to payment, people know how much they should pay to another person individually. When people need to charge others, what they usually know is the total amount. So, how about letting the system do the math automatically? I came up two alternatives based on this user insight.
Decision: Shortly after I made the prototype, I questioned myself: do people actually need to switch mode during the process? Their intention should be very clear at the very beginning. Such assumptions then got confirmed by other users. If I don't need to consider half-way mode switch, plan A obviously does better in terms of mode identification.
However, the "toal" and "each" input field confused users. My intention was to let users flexibly enter either "respective amount" or "total amount" and the system would do the math. However, what if some people involved in the payment already paid you offline? User would still need to deduct that portion from the total amount. To make thing simpler, I iterated the design as follows:
Wait, what if the user has periodic payments (as mentioned in the user scenario analysis)? It would be trivial for them to fill out the detailed payment page again and again every time. Same with the request, is there any way to save both the sender and recipient's effort? Here comes my solution:
My initial thoughts about the "quick pay" entry was that it shouldn't be a frequent practice, hence I bury it in the same way I did on the home page. After a quick test, I realized that the context was different: home page looks like Facebook news feeds, and users would naturally swipe down to refresh the feeds so they could discover the entries easily. However, when it comes to payment detail page, users have the mindset that refreshing action would clear everything they've already entered. As a result, they would intentionally avoid "swiping down" gesture. In the end, I decided to move quick pay entry to the upper-right part of the header.
This is my first time to redesign an existing financial service, and it is even more challenging than I expected. How to narrow down scope and think as considerate as possible within such a short period of time has been the biggest challenge for me. For every single detail, a designer can spend hours or even days on it as she dives deeper. Therefore, keeping to think about the flow as a whole and knowing when to stop struggling with one thing become extremely important when time is limited. Also, I realized that there would always be back and forth among design decisions. Normally, I start from concept A and then iterate many versions (B,C,D....) as design proceeds. However, it is very likely that the final design looks more similar to concept A. In the past, I would probably feel upset because it seems I've wasted a lot of time. However, I do feel such spiral process is valuable. There is not best solution but only a better one, and you will never know which one is the better one unless you try and validate.