01
INTRO
Initial Assumption / Problem
'I forgot my card in my other purse!"
"I wish there was an easier way of paying."
"I'll have to pay you back next time." I never have cash on me."
Cash is out and cards are king, but isn't there an easier way to keep track of and use credit cards? What about sending money to friends when the need arises?
THE GOAL
To create a way of easily sending money to friends, and a more efficient way of keeping and using credit cards.
MY ROLE
As UX / UI Designer, I was responsible for the creation of all elements from conception to final design.
TIMEFRAME
4 months
TOOLS
"Fortune befriends the bold."
-Emily Dickinson
02
DESIGN PROCESS
Design Methodologies
User Needs
User Interviews
Surveys
Business Requirements
Assumptions
Competitive Analysis
Personas
User Stories
Job Stories
User Journeys
Problem Statement
Hypothesis Statement
Task Analysis
User Flows
Design Brainstorming
Content Auditing
Card Sorting
Sitemap
Usability Heuristics
Low-fidelity Wireframes
Mid-fidelity Wireframes & Prototypes
High-Fidelity Wireframes & Prototypes
Rapid Prototyping
Accessibility
Design Iterations
Usability Testing
Usability Test Report
User Testing Validation
Preference Testing
Design Iterations
03
EMPATHIZE
Inspecting the Problem Space
"Money is a terrible master but an excellent servant."
– P.T. Barnum
Why?:
A Competitive Analysis was chosen to better understand the current offerings on the market, to find functionalities that should be included in the design and discover pain points to avoid. Finance-speak can often be stodgy. How are competitors communicating with users? What are they missing in their offerings?
Three questions were asked as a framework for this competitive analysis:
-
Who are they?
-
What do they do?
-
How are they seen (market advantage)?
A UX Analysis, Marketing Profile and SWOT Profile were completed using the data collected.
Click image for complete Competitive Analysis
Takeaway:
-
Clear upfront pricing, status updates of transactions and a high degree of security give the impression of integrity.
-
Past unsavory clientele make it difficult for Skrill to gain market share in developed countries where more reputable players are present.
-
A simple app without the stodgy-ness or "financial-speak" of large market players could be interesting to users hesitant to use financial apps.
​
Preliminary Problem Statement:
Users need a secure way to make electronically exchanged money transactions with friends, and pay for items electronically at stores because they want a convenient and contact-less form of payment.
​
We will know this to be true when users adopt our app for money exchange and embrace contactless payment via smartphone.
To align stakeholder interests and clarify project objectives, a Business Requirements Document was developed. Look inside for a full handling of the topic.
Click the image for the full report
Exploration Through Research
​
Research Goals
1.To better understand user behaviors regarding payment apps and the context in which they are most often used.
2.To identify pain points and frustrations that current payment app users experience.
3.To identify features participants would use on a continual basis.
User Interviews
User interviews were conducted remotely via Zoom with four individuals of different backgrounds and ages, using open ended questions to elicit data conversationally. Recordings were made as well as interview transcripts.
Surveys
Surveys were conducted with 44 participants to uncover data regarding the financial app space. Ten Closed Questions and one Open Question provided a roughly 90/10 split in the quantitative / qualitative data set. The length of survey was kept to just 11 questions to encourage completion.
Why?:
Using both qualitative and quantitative data provides a clearer and more detailed analysis, then one method alone. The interviews were Semi-Structured allowing more flexibility to explore a particular lines of thought, while keeping a general guide for all the interviews, rather than using a Structured or Unstructured interview type. These particular research methods were chosen rather than Diary Studies (because of time constraints) or Contextual Inquiries (because of budget) as the best methods to better understand users and the actions they take surrounding financial applications and in-store payment.
​
​
A high rate of mobile phone usage for financial transactions was observed.
61.9%
At multiple times per week or more, frequency of usage was also excellent.
59.5%
Our two main proposed functionalities (sending and receiving money and purchasing items in a physical store) were key uses for personal financial app usage.
59.6%
User Interviews were analyzed and organized via Affinity Mapping to distill common behaviors, needs and frustrations.
Takeaway:
-
As someone who creates their own spreadsheets to track finances, a surprising finding was the interest expressed for a budget or financial tracking function within the app. A graphical depiction of spending habits & budgetary allowances would create value and resonate well with users. It would also further carve out market niche.
-
Interest was also seen in the international transfer sector. This is out of scope of this application, but an area to explore for future projects.
-
Special care must be had concerning the entry of data (that it does not become too laborious) as well as a simple and smooth onboarding process. These were two areas of concern heard from users. The word "simple" was heard frequently.​​
​​
“The sole meaning of life is to serve humanity.”
-Tolstoy
04
DEFINE
Making users...human!
Design Personas
Design-Personas communicate the motivations, behaviors and challenges of REAL people, and tell a story about WHY a user interacts with in application in a particular way.
User Journey Maps
User Journey Maps give a visual depiction of the process personas go through while accomplishing a goal, and how they FEEL along the way.
Why?:
From the plethora of methods to present research findings, Qualitative Design Personas and User Journey Maps suited this project best, by synthesizing the core user and bringing a human element to findings. For example, a large sample size was not available for Quantitative Personas and Persona Empathy Maps were not specific enough to fully flesh out the core audience of the app. Mental Models and Storyboards were considered, but the selected methods offered enough clarity in organizing the data.
Click image for complete document.
Personas Nada & Günther were created as realistic portrayals of the target audience. They help project participants understand this audience as objectively as possible and avoid conflicting user perceptions.
​
They enable:
-empathy for users
- prioritization of functionality based on the audience
- design decisions based on real data from users
User Journeys show Nada & Günther as they explore and accomplish goals using the core functionalities of the app.
​
These journeys aid in understanding how people feel as they encounter and navigate through the app toward their goals. By doing so we can reduce user frustrations and friction early in the design process.
Click image for complete document.
Takeaway:
While structuring the data, two personalities became clear: A 20's single professional female, who is socially active, enjoys going out with friends and wants an easy way to see where her money is going. The second is a slightly older family man who wants an easier way to pay and keep track of credit cards and carefully track spending. Empathy levels are now at 11!
ORIGINAL PROBLEM STATEMENT
Users need a secure way to send and receive money with friends, pay for items with their phones and track spending, because they want a more convenient way of paying, and an easy way to track it.
​
We will know this to be true when we see user adoption and engagement with money exchange, payment via smartphone and the spending tracking functionality.
05
IDEATE
Delineation Nation...
Why?:
Task Analysis & Flows, User Flows, Card Sorting and Sitemaps help to determine "what goes where" and find the most efficient way for users to navigate an application. By using these methodologies to understand the Information Architecture at this point, rather than later on in the design process, a better understanding of the complete application structure is possible, and time and money are saved.
Split the Bill user flow
Card Sorting Results
Sitemap
Takeaway:
-
A particular challenge was to incorporate a "friction-less" method of sending money to new users within the user flows. It became clear adding new users should be both within the contacts page, as well as within each P2P transaction functionality.
-
A closed card sort was used which did not allow participants to label categories. Later, it was decided to remove the "wallet" label and focus in on the "send" and "receive" functionalities directly in the navigation menu. This idea may have come sooner had an open card sort been used from the beginning.
-
The same holds true for notifications. The notification settings are now in the settings menu, but the notification icon itself has a new home at the top of the home screen.
06
PROTOTYPE
Low-Fidelity Wireframes
Takeaway:
Navigation placement was a main consideration at this phase. Being a responsive Web app, all screen sizes were considered. The most elegant solution, that allowed for users to interact efficiently on all screen sizes, was to displace the navigation menu at the smallest break-point. Tablet sized screens and larger have navigation located at the top, and when reduced to mobile size, relocated to the bottom of the screen. This mobile first thinking gives the application a "native" feel when viewed on extra small (mobile) screens.
Mid-Fidelity Wireframes
Takeaway:
During the Mid-Fidelity Wireframing process an app name was chosen: "Finch". The mid-fi wireframing process also allowed for a slightly more focused look at design as well as for usability testing. Testing revealed areas of improvement and further refinement shown in the following section.
“Do not seek praise. Seek criticism.”
-Paul Arden
07
TEST
Failing Towards Excellence
Why?:
Testing allows immediate user feedback, enabling functionalities to be best catered to people's needs. Usability testing as well as Preference Testing were chosen as optimal data collection methods as they are cost effective and offer a relatively quick turn around rate.
Usability Testing
-
As a guideline during testing and for stakeholder inclusion, a Usability Test Plan and Test Script were developed. A Usability Report was also created.
-
Errors were assessed via the Jakob Nielsen's Usability Severity Scale.
-
Data was organized using Affinity Mapping and "The Rainbow Spreadsheet".
Preference Testing
-
Two Rounds of Preference Testing were completed to test Finch's Onboarding process (via Usability Hub).
-
Testing objective: to determine a best case solution for user error during onboarding, discovered during Usability Testing
Usability Testing Takeaway:
Usability Testing resulted in many small fixes as well as some more critical ones. Fonts were slightly too artistic and missed the mark regarding accessibility. The need for a designated "Budget" page separate from a "Home" page became clear. Transaction details on confirmation screens were absent and users inadvertently missed the second and third onboarding pages. Because of this, preference testing was conducted.
Onboarding A
Onboarding B
Onboarding C
PreferenceTesting Takeaway:
During Usability Testing, half the participants mistakenly selected the "Get Finch" button (Onboarding A) taking them to a sign-up page, rather than the next Onboarding page. Further probing revealed this was an unintentional mistake. To avoid this, Onboarding B was created allowing users to either swipe or click to the following Onboarding screen or skip the process altogether.
Onboarding A was then set against Onboarding B during preference testing. While testing results offered no significant statistical advantage, users were able to offer reasoning behind their choice, which revealed a preference for the large button and the community feeling of "Already a Fincher?", but also the clarity of the "Next" button label. By using this data, new wireframes were designed to incorporate the desired attributes. The result is Onboarding C, which eliminated the error completely.
08
HIGH-FIDELITY
Hey, Good Lookin'!
-
Visual Design Principles, Grids and Spacing were applied to High-Fidelity Wireframes, in addition to Emotional Design to increase User Engagement.
-
Web Content Accessibility Guidelines from Section 508 were applied.
-
Design Documentation was also created.
​
Finch Prototype Walkthrough
09
FUTURE STEPS
What's next?
To help users better understand app functionalities, a "post-boarding" onboarding (after login) should be created. Coach-marks may be a good option, although some processes, such as adding a credit card could be built directly into the onboarding process.
​
A proper handling of security as not been yet completed. Some elements have been included, but a complete handling of login security, 2-factor authentication, purchase security as well as measures to increase user awareness need to be addressed.
10
Conclusion
Retrospective
The goal of creating a means to easily send money to friends and keeping track of credit cards was achieved.
​
Course correction through data: When data indicated that money tracking functionality was desired by users, this was added to the mix. By doing so, not only was value was added to the product, but a market niche that was not known at the beginning of the project was created.
What went well:
What didn't go well:
Using an open card sort rather than a closed card sort would have been a better option and perhaps a more efficient way of finding navigation labels.
Preference Testing can get confusing for the participants when too many design changes exist between choices. In future iterations only one design difference should be included.
Because of geographical limitations, I was not able to test and study certain financial apps. Removing this restriction will offer a more complete handling of competitive analysis in future projects.
​
In general, spending more time on information architecture strategies will save time and money in later stages. This will be a priority going forward.
Improvement areas:
Thanks for stopping by!