OVERVIEW
Summary
Peer-to-peer money transfer applications have enabled transactions to happen faster than ever. Whether you're simply paying a friend back for lunch, paying rent, or even buying goods from a local store, these apps are quickly becoming the new cash-in-pocket.
Challenge
People use P2P money transfer apps for a large variety of reasons, but they all need to be fast, simple, and secure. The goal is to make a responsive web application that sets itself apart from the competition, and can be used by any user for any purpose.
Solution
I will design a responsive web app that will allow users to favorite other users for ease of payments, schedule future payments and repeat past payments, all while remaining intuitive for any level of technical ability.
What kind of people are going to use PayDate?
User Personas
E-wallet apps are used by a wide variety of people in a wide variety of situations. I tried to create personas that would represent these larger groups with enough differences to distinguish them throughout the rest of the design process.
How would my personas feel using PayDate?
Journey Maps
I made some assumptions about the thoughts and emotions my personas might feel while using some potential features of PayDate. Luckily, these personas and their emotions are based off user interviews, so my assumptions are guided.
How would users get from point A to point B?
User Story/Objective #1
"As a social college student, I want to be able to repeat previous payments, so that I can pay my friend back for the bar’s cover fee that he pays every week."
User Story/Objective #2
"As a fraternity member, I want to be able to schedule fraternity due payments, so that I don’t forget to pay."
User Story/Objective #3
"As a landlord, I want the rent money my tenants send me to be instantly transferred to my bank account, so that I have access to those funds as quickly as possible outside of PayDate."
How should the pages be organized?
Sitemap
How will users interact with PayDate?
Low-Fidelity Prototypes
I started by making low-fidelity prototypes for three primary user flows. Since PayDate will be a responsive web app, I created these prototypes for both mobile and desktop applications.
What will PayDate actually look like?
Mid-Fidelity Prototypes
Transferring my hand drawn sketches to a cleaner digital format, as well as making them interactive is the best way to move this project from an idea to a usable product.
How/what/where will usability testing occur?
I knew I wanted to do usability testing with my mid-fidelity prototypes before my next iteration to confirm the assumptions I made and find potential pain points for users.
I decided a moderated usability test was best for this stage, so I created a usability test plan including the problem statement, goals of testing, test methodology, metrics to be used, and everything in between. This helped me organize the logistics of conducting these tests.
I conducted two remote tests and four in-person tests. Three main functions of PayDate were explored during these tests for both the mobile and the desktop versions.
I decided a moderated usability test was best for this stage, so I created a usability test plan including the problem statement, goals of testing, test methodology, metrics to be used, and everything in between. This helped me organize the logistics of conducting these tests.
I conducted two remote tests and four in-person tests. Three main functions of PayDate were explored during these tests for both the mobile and the desktop versions.
What insights did I gain from the usability testing?
Errors Made:
• Users tried using search bar to filter the transaction feed
• Thought calendar button was some other type of grid view button
• User tried to click the admin/settings button to look for contacts to pay
Observations Made:
• Users felt like they would benefit from onboarding
• Users found it difficult to filter feed
• “Really easy to make or schedule new payments”
With these valuable insights I could start working on my next iteration; high-fidelity wireframes/prototypes. In this iteration, I wanted to include the introduction/onboarding screens, but I was left with one main question:
Which intro screen should I use?
I conducted a preference test to compare options for which introduction screen users preferred. In a situation where users are presented with a simple layout change, this type of test is great rather than an A/B test that benefits from large amounts of site/app traffic.
Option 1
Option 2
80% of participants chose option 1
• “Gives you more info on what you’re creating an account for”
• “More info, feels secure, I know I’m signing up for”
• “Gives you more info on what you’re creating an account for”
• “More info, feels secure, I know I’m signing up for”
How can I prepare myself for project hand off?
Style Guide and Design System
After the first iteration of high-fidelity wireframes, I decided to create a style guide for PayDate. While important information is included in a style guide, after some time I realized I needed to create a full design system in order to convey as much information as possible. Having these documents will come in very handy for a developer hand off in the future.
To see the full Design System, click here
How can I improve my current design?
This is one of the most important questions for a designer to be asking themselves. Luckily, I have access to a large community of UX designers right at my fingertips!
I asked for critical feedback from a few members of a Slack community I am part of. Figma makes it very easy to conduct these collaborative measures at any stage of the design process.
I asked for critical feedback from a few members of a Slack community I am part of. Figma makes it very easy to conduct these collaborative measures at any stage of the design process.
Which suggestions do I incorporate?
Sifting through design suggestions can be one of the trickiest parts of the design process. It’s important to not sacrifice your original vision, but also recognize where the user experience could be hindered by the first iteration design.
I decided to make the cards a solid color, but did not change the favorites tab. I think it is important to keep distinction between the two
I can’t show every refined design screen for PayDate in this case study, but I have included some of the best examples of the polished UI from this collaboration exercise.
Sometimes the changes can be subtle but make a huge difference in the quality of the design.
Final Prototype
Try out the key functions of PayDate for yourself with the prototype below!
