top of page

FINCH

Finch Pay in Store mockup
Welcome to Finch splash page.
Finch Budget page mockup

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

lucidchart icon
17fe66f8fb8849248bd6dcf727c7447c03bda88285b31e19f4cafecec49afc9d_200.jpeg
zoom icon
Figma icon
pngfind.com-google-forms-png-5309946.png
vidyard.png
pngegg.png
ogimg.png
invision.png
usability hub.png
1_Z8usc-jYE6RYJ11pq62u4A.jpeg
Finch Intro
Wild Nature

"Fortune befriends the bold."
-Emily Dickinson

 

02

DESIGN PROCESS

Design Methodologies

 
the-five-phases-of-the-design-thinking-process-

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

Finch Design Process

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?

skrill competitive analysis swot jpeg.jpg
xoom competitive analysis swot jpeg.jpg

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.

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.

 
chat_bubble_icon

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.  

survey icon.png

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%

survey question 2.jpg
Survey Question 3.jpg

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%

survey question 7.jpg

User Interviews were analyzed and organized via Affinity Mapping to distill common behaviors, needs and frustrations. 

 
 
Affinity Mapping Data.jpg

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.​​

Finch Empathize

“The sole meaning of life is to serve humanity.”

-Tolstoy

04

DEFINE

Making users...human!

 
person_icon

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.

Location-icon-design-on-transparent-background-PNG.png

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.

Persana Günther.jpg
Persona Nada.jpg

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.   

User Journey, Nada.jpg
User Journey, Günther.jpg

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! 

Finch Define

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.

Finch, split the bill.png

Split the Bill user flow

 

Card Sorting Results

Results Matrix.jpg

Sitemap

Finch sitemap revised v.2.png

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.      

Finch Ideate

06

PROTOTYPE

Low-Fidelity Wireframes

 
 
cardmapr-IUwX_P80DEU-unsplash.jpeg

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

 
 
mid-fi wireframes finch main pic.png

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. 

Finch Prototype

“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 icon.png

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 icon.png

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  

Rainbow Spreadsheet.jpg

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.jpg

Onboarding A

Onboarding B

onboarding B.jpg

Onboarding C

Onboarding C.jpg

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

Finch Test

08

HIGH-FIDELITY 

Hey, Good Lookin'!

 
 
Home screen mockup.png
budget page mockup.png
Pay with card screen mockup.png
  • 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 Hi-res main picture.png
Finch Hi-Fi Wireframes

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.      

Finch Future Steps

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!

Finch Conclusion
bottom of page