Pockets
The new way to organize and pay money using your mobile device
Pockets is a financial management hub that informs you on what money you have to spend.
By utilizing the old fashion way of budgeting with cash, pockets allows users to create digital pockets to organize and spend their money with clarity and less stress.
.png)
Problem
There are many challenges to consider when managing finances, especially among the young generation where financial literacy is increasing. Becoming financially independent is a stressful task and those that are new to managing their own finances are often stressed and unequipped to deal with it efficiently.
Financial related stress is increasing among 18-30 year olds from the lack of a proper modern budgeting tool that helps them understand how to manage their money.
1/3
Young adults lack financial literacy and management skills
Solution
Engage the user with an interactive way to manage their finances in a visually organized manner, providing features that allow for real-time updates, and user inclusion so that they have full-time awareness of how much money they have to spend, and where they need it to go.
Process
Utilizing the design thinking process I was able to understand the challenges people face when emerging into financial independence and develop a solution to fit their needs.
Starting off with research, my goal was to capture how users felt, thought, and behaved when it comes to managing finances. I then utilized UX methodologies to synthesize research into insights to generate solutions. After choosing one of the solutions to design for, I test the design for user feedback and implementation.
My role
Research
Ideate
Evaluate
Synthesize
Design
Working as a lone designer I was faced with the challenge of not being biased with my own thoughts and had to carefully consider all information provided. Luckily I was able to confide in a mentor weekly about my processes and thoughts throughout the project.
Research
I began by devising a plan to understand how people struggle with managing, organizing, and planning their expenditures. Starting with a survey, my goal was to capture insights about my demographics in order to isolate my target audience for interviewing.
.png)
Research plan
Understanding my demographics
As I analyzed the results of the survey I began to recognize who my users were and why I would need to talk to them to understand more about their struggles.
.png)
Survey
43 participants
69.2% are between the age of 21-31
only 48.9% say they are comfortable with managing finances
20.9% say 50% of their stress is financial related
only 45.5% say they are confident making financial decisions
68.2% work between 31- 40+ hours a week
Conducting interviews
I planned and executed 4 online interview sessions to further my knowledge of how my demographics are thinking and feeling and uncover behavioral traits when it comes to managing finances. To execute the interview sessions, I put together a guide to keep me focused and keep the conversation going to get the insights I was looking for.
Interview guide
How I chose participants to interview
My selection of participants was based on the answers they provided in the survey and whether or not they met the criteria of my target audience. Ultimately I would have lots of potential participants to pool from, however, I would soon learn that talking about finances with a complete stranger is often a touchy subject. Of my 43 participants, I was able to find 7 that met the criteria I was looking for. in the end for various reasons I was only able to conduct 4 of them.
“Being able to see visually on a piece of paper what I am spending is everything.”
“All-inclusive, easy interface. The bank linkage in real-time would be ideal.”
Synthesis
Once my interviews were complete and I had my notes together, I began extracting the DNA from my participants in the form of insights. In order to do so, I decided it would be best to place notes and insights onto sticky notes and let the affinity mapping process commence.
View
mapping process
Reflecting on what i've learned
At the end of the process of breaking down insights into codes and then themes, I would come away with 8 themes that would be chunked into three defining categories and several key insights. The most important piece of knowledge that I would ultimately conclude from research is that my users just want to know how much they have to spend.
Empathy mapping
Utilizing what I've learned so far, I created an empathy map to capture how my users are thinking, feeling, doing, and seeing in order to better understand how to design for them later on.
.png)
Persona
By creating a persona to capture who my user is and why they need a solution, I begin to wonder how I can solve their needs, and think about what solutions currently exist for them and why they don't work.
No solution already?
I found 3 competitors that seem to perform the strongest and be most popular. By conducting a heuristic analysis I was able to understand how each competitor's application is used and why it falls short of my target audience's expectations.
I learned that none of the available applications accurately informs the user how much they truly have to spend in real-time based on what they want to be set aside for expenses.
The applications do not work with the user directly and required tons of backlogging work.
These methods do not help the user manage their money, they just simply inform the user of where their money is being spent (if the labels are accurate)
Heuristic analysis
Ideate
HOW
MIGHT
WE
To answer the HMW I began generating ideas onto sticky notes that would accomplish/solve the HMW questions. the sticky notes are labeled 1-3 to represent which HMW question it answers.
Answering the HMW questions started creating concepts that could potentially help my users.
How can I provide a solution to my audience
Provide the individual with the means to make confident financial decisions to relieve stress and uncertainty.
Provide financial resources that help individuals be aware and prepared.
Provide organized financial information that is easy to interact with and digest.
I ended up producing 3 concepts that reflected the ideas generated when answering the HMW questions.
After considering and discussing the tree concepts, I decided to move forward and develop the third option (the concept to the right).
A financial hub that synchronizes bank accounts, credit cards, and expenses, provides real-time data and allows the user to create spending tiles used as pathways for managing and paying to keep finances organized.
The concept at its essence can be broken down to the idea of organizing cash into envelopes with labels on them that are set aside for when you need it. Most importantly the user will know how much they have to spend, not only for what they have set aside in pockets but the total amount available to spend after creating their pockets.
How it works flow
What do my users need most out of this design
To understand what my users need within my new concept, I utilized user stories to capture the most crucial moments to design for.
This exercise challenged me to think about what my users would want to accomplish using my design.
Turning user stories into a story map
Creating a user story map helped me understand what the most valuable product (MVP) needs to be in order for my users to have a successful experience.
This process allowed me to focus on what needed to be implemented and start to unfold the structure of the design as well.
Design
The architectural composition
Starting with site maps, I set out to develop the structure of the design. This provided me with the bones of the interface to come.
How should this thing work
User flows were a great way to understand how my users would navigate and complete each task (red routes). My challenge here was creating a process that is simple and provides the user the ability to quickly complete their tasks.
Categorizing a transaction
This is used when a user cant use mobile payment and has to use the debit card linked to their pocket's account.
The purpose is when the user has a pocket with money that would be used for the purchase but due to lack of mobile payment could not. So you are substituting the transaction with the money in your pocket.
This feature went through multiple re-labeling stages as it caused confusing mental models with the verbiage on the label along with how I delivered the task scenario for this feature in user testing.
Paying an expense
This is for users that have created an expense for their calendar or perhaps have an expense tied to a pocket
Using mobile payment
Use mobile pay to use the money you have set aside in your pockets
Creating an element
This is for creating a pocket, documenting an expense, or adding another account for your management.
How should this thing look
By now I had all these thoughts about how this thing might look. I had to start sketching out screens to get an idea. I implemented a quick guerilla testing exercise using a quick paper prototype to test the initial idea.
.jpeg)
.jpeg)
Paper prototype
Using marvels POP application I created a quick click-through to get a feel for how participants reacted to the initial concept. I learned from my initial feedback that post payments were confusing in verbiage and task flow. (this would be my first encounter of troubles with this feature)
.png)
Guerilla prototype
Moving onto digital wireframes
Turing sketches to digital wireframes. This stage provided a whole new perspective that would lead to big changes later on in the process. It also gave me time to find and reflect upon edge cases that users may encounter.
At this point, I became conflicted with my interface layout decisions and desired to conduct A/B testing in order to gain input for decision making. My conflict was with the main home screen that allowed the user to navigate tabs, along with the action buttons at the top. I felt like something simpler should be implemented that prioritized the call to actions.
Edge cases
Here are some of the early edge cases identified. Some more would be identified later on, but not designed for
These edge cases deal with a user wanting to make a split payment and a user that does not have enough in there pocket to complete the transaction
Lets throw some branding to the solution
In order to continue with the development of the interface into high-fidelity designs, I needed to figure out some branding. The name pockets came about because of the cash-like ability to place physical cash into separate pockets for budgeting purposes. By utilizing a simple brand platform outline, I was able to determine brand values and appearance. Now let's talk colors.
Starting with a color scheme, I employed the use of color theories to guide my decisions and a $100 bill to guide my explorations. Why did I choose the $100 for colors? Because of the symbolism of the positivity and excitement holding a $100 bill brings along with its prestigious colors. Not all bills are green.
Brand platform
Building the hi fidelity interface
Designing the Hi-fidelity interface felt like a project of its own. At some points, I even had to go back and remind myself why I was designing in the first place. Utilizing a style guide was key to maintaining consistency within text sizes, colors, and spacings. The high fidelity interface implements quite a significant change from the mid-fidelity however the paths taken to accomplish each task have remained the same.
Evaluate
Lets see if this works
Utilizing a prototype built in Figma, I was able to conduct 2 rounds of user testing to determine what was successful and unsuccessful about the functionality and visual organization of the interface. After each round of testing, I implemented feedback provided by users and my mentor in order to increase the performance of the functionality
Usability test plan
Round 1 results
After the first round of testing was complete, I gathered my notes and feedback to decipher the usability issues and organized them by priority to focus on what needed the most attention. The criteria for the usability problem resulted in a critical fix or not determined if the issue directly impacted the user's ability to accomplish a red route task.
Test 1 results
Key changes
Starting with the homepage, you can immediately tell the difference in color with the primary call to action, along with the main pay icons' position adjusted to sit on top of the navbar instead of floating. My theory with the original design is that the main pay icon was being ignored due to lack of noticeability.
Original
Revision
This is the page where you select the pocket you want to pay. A change was made here because of the elimination of the split payment button, and the need to make categorizing a transaction more noticeable. Also to provide a greater difference between the pay page and the main home pockets page.
The pocket page was changed in order to separate the functions of mobile pay and categorizing a transaction. In the original design, both actions were contained to the user needing to select the pay icon first. You may also notice recurring deposit has been eliminated in order to simplify the design and not produce confusing mental models among users
This page was altered to provide greater aesthetics with the linked debit cards along with emphasizing the categorizing of a transaction button with size and color. This was the main route out of 2 that test participants took to categorize the restaurant transaction under their food pocket.
When the user is confirming an expense to be paid, a screen that prompts them to confirm the payment appears. the original design was confusing to users as they often thought they were being asked to reselect the storge (in this case) pocket rather than confirming the payment.
Round 2 testing
I utilized the same test with modifications in the verbiage for round 2 with new participants. The main difference in this round was eliminating the split payment feature and set up the user for an edge case.
Categorizing a transaction was still a pain point among all users except for one that executed the task flawlessly. I discovered that perhaps my scenario provided confusing mental models on par with the verbiage of the catatorgizition button.
Another issue that arose from the adjustments made from the round 1 session was the need to make primary and secondary actions consistent with color and size in order to guide the user more effectively through the use of hierarchy.
Test 2 results
Final Design
Conclusion
My conclusion of this project is that I provided my audience with the ability to know how much they have to spend on what they need in life and that I achieved this by implementing a design that is organized engaging and works in real-time with the user.
If I were to continue the project I would want to hand off the design to a developer and create a working prototype that can be used in real context to conduct dairy studies. I believe in doing so I would find more minor usability issues and discover opportunities to implement features that enhance the overall experience.