How I built a system to help users save money
This week, I had a whole new experience when the bank I have been building wireframes for chose to integrate a new core product as fast as possible. The new product has four key features: user financial trends, analysis of specific transactions to see if they are historically anomalous, a “what-if” financial modeling system, and an ability to figure out when it is safe to spend at any time. The last time I wrote, I said I was going to build out my screens, do usability testing with 8-10 people, and build out my flows. Though I did accomplish this, I am going to focus on how I developed the new product, how I tested it, what I learned, and present my new screens.
In this week’s post, I am going to discuss
- my process,
- revised information architecture concept model,
- testing outcomes,
- screens and
- next steps.
Since the new product I have been tasked to incorporate in the mobile banking application is about financial analysis, I decided that its fundamental purpose is to help a customer save. Thus, at its core, the mission of the new product is to help users save money. After doing some background research, I found out that Americans are not saving a lot of money at all. To me, this means the product should help Americans move from living paycheck-to-paycheck to a state of financial stability which I will define as having saved three times the amount of money you spend each month.
So now, I have framed the challenge in a new way. I am not longer trying to fit four different products into my banking application. Instead, I am going to determine how can a banking application help a financially illiterate person gain the confidence to begin saving their money and get out of the situation where they are living from paycheck to paycheck.
This led me to ask questions like, “Why don’t people save money? What are barriers to financial planning? How can a mobile application support decisions that lead to long term saving?”. There are products out there that help a user budget. So why isn’t America jumping on board and living within their means, putting away a little bit every month, learning to invest and take on other habits that will lead to long term financial stability? Of course, there are many factors a banking application has no control over. It can’t change the very real circumstances that Americans live everyday. What can it control? How can it help users to change their behavior in simple ways?
Thus, I started to reframe the challenge again. I asked myself, “How can the banking application create a situation in which the user feels like saving’s support is invited? What circumstances would a user be in, in which a he or she would more likely value a little nudge that would lead to better financial health?” This was a fruitful line of questioning because I recognized that though a user may intellectually recognize that saving money is better, he or she may not emotionally be able to grasp it. There are many barriers to behavior change and there’s no way a banking application can help a user to become better at saving if it does not take those into account.
To help me systematically think this challenge through, I built a service blueprint using sticking notes. Along the vertical axis in purple sticky notes, I wrote the headings: triggers (data), system triggers, triggers (user), system’s response, customer service response, and next steps. By triggers (data), I am referring to all the data a banking application can track including frequency of a kind of purchase, location of purchases, the collective spending habits of users in a similar location and income bracket, and individual user spending habits. By system’s response, I mean what is the frequency, quantity or time that will lead to a moment in time a user may want help. By triggers (user), I mean what will the user be doing in the real world as well as in the banking application when the system is stepping in. By system’s response, I mean what will the system say to invite the user into the interaction. The rest of the terms are about how the user will go about accomplishing the new goal instantiated by the system’s response.
Triggers (data) – system is tracking how much the user is typically earning each month (biweekly paycheck) as well as when bills are usually paid
System triggers – a user does not get a new paycheck for 1 month
Trigger (user) – user logs in to the banking application
System’s response – a modal pops up and makes a friendly comment in which it says it has noticed that something isn’t okay and ask if the user would like some help figuring out how to make sure they have enough savings to pay a bill coming up in two weeks. Sign up for our new service.
User response – sign up later or sign up now.
In the end, I built out the product with a few use cases in mind. I specifically focused on a person who is living paycheck-to-paycheck. I wrote a few stories to figure out what the user may be doing and what his or her goal may be. I used this to help me revise my information architecture map. Then, I sketched my wireframes and built them. Finally, I ventured out into the field to do my usability testing.
Revised information architecture map
In order to revise my information architecture map, I first tried to incorporate feedback I’ve gotten that the original map was unsightly and seemingly disorganized. Though I’ve used the map for my own sensemaking, it also needs to be something I could hand off to a developer so that way they can understand the lay of the land, so to speak. After I revised its appearance for clarity, I added in the new feature I developed called Safe to Spend.
I attempted two forms of usability testing this week. First, I tried usability testing as I have always done. This was super pertinent since I am just at the beginning stages of building up my idea. It is important to get other people’s perspectives – to see if they can make sense of the flows. Getting to hear someone think aloud as they attempted to figure out the new feature, I learned about what I did not consider, about how I displayed information, and the copy I wrote. Getting a handful of people to test my screens, I get to learn about where I need to make design considerations in a rapid and cheap way. I was able to get really actionable feedback.
I learned a lot of important ways to revise. I chose the top three. They are visualized below in the next section.
The second way I tested my application was through cognitive walkthrough. This involves trying to use the application from the perspective of a first time user to try and understand if he or she can achieve their goal. I tried to figure out if the user wants to save money, would they understand how to move their way through Safe to spend. You can see how I visualized this process below. Using this method, I was able to reflect on cases that I had not previously considered including user states of mind and cash flow.
Below, I have visualized the top three errors I revised in my screens.
Safe to spend screens
Below are the Safe to spend screens. I labelled each flow with the task that it accomplishes plus indicating which of the requested features it addresses.
For my next steps, I want to develop my banking mobile app into it is fully complete, revise my information architecture map so that it is both clear and consistent, as well as build out the safe to spend feature. My hope is to create a full product that I can use in my portfolio.