Urban FT - friend pay
Friend pay (p2p) feature for whitelabel fintech
Summary
Urban FT is a financial tech company that specializes in custom built, white-label apps for its clients, which includes
Sprint, Boost Mobile Wallet, and 70 + credit unions across the US.
For this particular piece, I wanted to showcase the process and end results for a friend pay fuctionality (p2p in industry terms) that we were tasked to implement for its core white-label banking app. In order to maintain confidentiality, I’ve changed the branding and designs of the application.
For this particular piece, I wanted to showcase the process and end results for a friend pay fuctionality (p2p in industry terms) that we were tasked to implement for its core white-label banking app. In order to maintain confidentiality, I’ve changed the branding and designs of the application.
Company
Role
UX/UI Designer
(1 of 4)
(1 of 4)
Platform
Mobile, iOS
Final design screens (above)
The Problem & "how might we's"
Friend pay in its current form, as presented by an api partner of Urban FT, was recorded to have a very low use percentage
among the users of the banking application. Most reasons pointed to bogged down features, long flows, and inability for immediate
access of the funds. Another big reason was because users were confused by all the different styles of “transfers” that were
readily available in the app.
Our proposed solutions became several “how might we’s.” Namely, how might we streamline this process, and how might we establish
the “first time” value of this feature so people can return to using it?
Research
API documentation
First, we tore through 400 plus pages of API documentations provided by the partner to find and record the functionalities
of the friend pay feature. Some key things that we’ve discovered, and had questions about included,
- Feature to set up a “security question” and passcode for the recipient. This was put in place in case the money is sent to the wrong phone number or email. However, how valuable is it realistically to users?
- Feature to set up date and frequency. Again, is this something that people use frequently, or something that bogs down the flow?
- Technology limitation: The recipient must input his/her account number each time to accept funds. With this in mind, how likely are users to try this feature if they don’t have their account number readily available?
- Technology limitation: It takes 2-3 business days for the funds to be withdrawn by a recipient after he/she has accepted it.
User flows & wireframes
After we were able to outline all the technological features and limitations for this feature, we organized them into different
user flows. Once we were finished with creating the flows, we went through several processes of “Crazy 8s” to sketch the
key screens requireed for this process. (Crazy 8’s is a time-effective design technique, where you try to sketch out 8 widely
different concepts in the span of 8 minutes.)
User testing
We started with paper prototypes, then used the valuable feedback we gained to iterate on an Invision prototype. For example,
as we theorized, none of the users were keen on setting up a security password system. P2p was something they wanted to do
immediately, in and out, and having extra steps for it was an immediate roadblock. In terms of the security scarce of sending
it to the wrong phone number, we weighed the need for a smooth flow to be more important than the slim use-case of sending
it to a wrong phone number. Furthermore, there is the option of cancelling the money transaction before it hits the recipient.
The same was the case for setting up date and frequency within the flow. We correctly assumed that p2p was most often times
a singular affair. Some users expressed favorably for the option to set a date, but was not keen on having to do it within
the flow. Furthermore, we were able to obtain data of the usage of the date and frequency feature from our api partner, and
it numbered extremely low. Thus, we adjusted the flows by having the date pre-filled in the review screen, and getting rid
of the frequency option entirely.
Design
Atomic design: creating from components
For creating our high-fidelity components, we designed from a modular, component based approach. By doing so, and converting
these components into Sketch symbols, we are able to easily drop in and out components like Lego blocks to create screens;
extremely valuable to do, especially for a white-label product where branding must be changed for all of its clients.
Component-based approach (above)
High-fidelity screens (above)
High-fidelity screens (above)
Future steps
We were able to produce the redesigned p2p experience under our company’s deadline. There were definitely technological limitations
which we had to work around that were beyond our control, such as the flow from the recipient’s side. However, given the
limitations, we were still able to craft a much smoother experience that solves our “How might we” of streamlining this process
and letting users gain first time value. Currently, we are in the process of talking with developers and conducting design
QAs for this feature to be correctly implemented.
