SaveQuest: A Savings Game
A DesignLab Concept Project
BRIEF
A bank wants to use their reach to improve the financial health of its customers.
Identify a real user problem and develop a helpful solution within the existing design system.
SOLUTION OVERVIEW
I created a gameified savings tool that works off the user’s purchasing patterns to reward a change in habits, demonstrate long term impacts of small choices, and make savings-building more fun.
LESSONS LEARNED
- Shame keeps a lot of people struggling with money in silence.
- Talk to users to find the problem, not the immediate solution.
- People ignore onboarding, but read contextual instructions.
USER INTERVIEWS
5
users
USER SURVEY
77
responses
TASK FLOWS
2
tasks
PROTOTYPES
22
screens
USABILITY TESTING
7
tests
ITERATIONS
3
revisions
01. INTRODUCTION
I think personal finance is fascinating because it is the foundation for people’s lives. Money impacts just about everything else, and yet we so rarely talk about it directly and honestly. It is a vulnerable and often fraught topic, so I jumped at the chance to work on it.
The project brief stated that “the bank wants to use their reach to improve the financial health of its customers.” That was my starting point. The research would inform the rest.
Project Limitations
This project was completed “from the outside”, without any involvement from the business itself. This means I did not have access to any information from the business and therefore had to make a number of assumptions. The resulting project was not constrained by the realities of the business, but it was also not informed by the vital information only they would know.
02. USER RESEARCH
I wanted to see how users approach money in general and savings in particular. Then I wanted to see what kinds of savings tools were available from the competition.
User Interviews
I began by talking to the users. I recruited and interviewed five people. Most of them were not current Capital One users, but everyone used their own bank’s app.
Most Requested Feature
People overwhelmingly wanted a snapshot view of their spending by category, ideally one they could customize.
Why Do Users Want This Feature?
I could have just stopped my prying there. People want to see a spending breakdown by category, that seems reasonable enough. It is not a feature Capital One’s app currently offers, and it would be a cool addition.
I was still curious. Why do people want this feature? What did they expect it to do for them?
When I asked these follow up questions, people usually responded with some version of
“Seeing how much I’ve spent on takeout or shopping will make me spend less on those things.”
Why Do Users Expect That Outcome?
After another round of whys, I learned that
users expected that seeing those numbers would “shock” or “shame” them into spending less on discretionary categories, and that would help them save more.
User Survey
Now that I knew what feature the users wanted and what they expected it to accomplish for them, I wanted to find out if the feature they wanted would solve their problem.
Are the people who see their spending breakdown in a budget more likely to save than the people who don’t?
Among the interviewees, the person who did the most spending tracking work by manually entering their expenses in a Buddy tracker had no savings at all. None.
Is that an exception or the rule?
To find out, I created an online survey and got 77 responses.
Formal Budgets Are Rare
Very few respondents kept a formal budget: just 8 out of 77 respondents.
Most People Don’t Save
Only 39% of respondents have at least 3 months’ worth of living expenses saved, but they are not distributed equally among the budget groups.
- 100% of people who keep a manual budget.
- 50% of people who rely on an app for budgeting.
- 50% of people who have no budget at all.
- 37.5% of people who have a general sense of their finances, but no budget.
- 15.8% of people who tried to keep a budget and failed.
Trying and failing at budgeting corresponds to the worst savings outcome, and the people who rely on an app do no better than the people who don’t budget at all.
User Research Summary
- Keeping a budget is a lot of work and most people don’t stick to it.
- Just seeing the numbers helps some people save, but for most people it is not as helpful for changing habits and building savings as they expect it to be.
- There is a large group of people out there trying to shame themselves into saving more, and it is not working. They need a different solution.
“I’ve tried to keep a budget. It went out the window as soon as a sale happened, or Covid happened and I leaned on shopping to self soothe.”
Persona
Rachel is based on the combined insights from the user interviews and the survey. She has tried and failed to stick to a budget, and often leans on spending money to soothe her anxiety and stress. She wants to spend less, but her shame-based approach to saving has failed her many times.
Empathy Map
Rachel is really stressed out. Saving more money would ease a lot of her stress in the long run, but in the short run, spending money is the only thing that helps her feel good for a little while at a time.
Spending money is fun. Saving money is not…but what if it could be?
03. DEFINE
The shaming approach clearly doesn’t work for a lot of people. Spending money makes people feel good, right now, while saving money has no immediate emotional payoff.
All sorts of things are gamefied now. Marketing, education, even investing. Why not savings?
THEORY: adding a small element of fun right at the point of NOT spending money would do a better job helping people work toward their financial goals than the shame approach could.
Feature Overview
- Show the user their spending, organized into the most common “I overspend on this” categories.
- Ask the user to choose one of those categories.
- Encourage the user to not spend on that category for a defined length of time.
- Every day they do not spend on their quest category, prompt the user to confirm a transfer of the typical amount they would have spent on it into their savings account.
- On the days the user does spend in the quest category, nothing happens. No transfer, no “fail” notification. They save only what they do not spend.
- Show the user how these small savings would add up over a year.
Preliminary Functionality Requirements
- Badges and visual trackers to help the user track their progress and stay motivated.
- Positive messaging only. People feel enough shame about their spending as it is, adding to that would not help.
- Experience levels with features that unlock as the user makes progress toward their goals.
- Short sprints instead of ongoing self-deprivation. Most people can give up life’s little pleasures for a little while, but no one wants to go on an endless diet, financial or otherwise.
Competitive Research
Now that I knew the direction I wanted to explore, it was time to see if anyone has already done something like this, and if so, how well it was working. Learning from competition’s experience is much easier than reinventing the wheel, and I wanted to make sure I did not inadvertently copy someone else’s creation.
I found two products with a similar approach to my chosen direction. I’m sure there is a lot more out there, but due to the time limitations of the project, I focused on the most prominent competitor products.
Wells Fargo’s Daily Change
Wells Fargo launched a standalone app to gameify savings in 2016 and discontinued it in 2019. It was well liked by its users, but I could not find any actual reviews because it has been discontinued. I could not find out why it has been discontinued, which would have been really helpful to know.
The app worked by letting users pick a pre-populated challenge for one or two weeks at a time, and pre-select the transfer amount they would confirm whenever they completed the action. The app’s functionality was similar to what I had in mind, but it had a few key differences:
- It was a standalone app instead of integrating into the existing banking app.
- The actions were not connected to the user’s spending history. A user could pick any action they wanted and input any transfer amount. While this would help build the savings, it would not require a change in spending in order to work.
- It doesn’t seem like a user could run more than one challenge concurrently.
Qapital’s IFTTT Rules
Qapital uses behavioral economics principles to encourage people to do what they know is good for them. It is a third party app that connects to a user’s bank account as well as any apps a user chooses to connect it to, then transfers money based on the rules the user activated. For example, a user could say to transfer X amount every time they booked an Uber, or watched a YouTube movie, or reached a steps goal.
Critical Issues
- A third party app with ability to withdraw money from the user’s bank, which would be a concern for anyone worried about their data privacy and security.
- A monthly fee for use.
- Rules could be based on user’s spending, but most of them are not.
- Transfers happen in batches and with no warning, surprising users and causing overdraft fees.
- Transfers cannot be cancelled.
- Once the money is transferred to Qapital, it can take several days to transfer it back.
Task Flows
Once I defined what my feature would do, I began to figure out how it would work.
I mapped out a pared down task flow of the happy path as a starting point.
It was definitely going to change as I kept working, but it was a helpful starting point to start wrapping my head around what key screens I needed to create in order to let my user successfully navigate through my feature.
I wanted to spend more time on the overall user flow, defining some error states and working through all the various what if’s, but the timeboxed, student nature of this project limited the scope of the work.
Wire Flows
Once I had a task flow, I moved on to fleshing out what functionality each key screen needed to contain to get the job done. I did that with some rough wire flows.
I did not worry about the visual design of it right then, that part would come later. I also did not include every single element that the final screens would require. At this point I simply needed to plop down the essential functionality on some rectangles so I could iterate from there.
04. KEY SCREENS
Once I had some idea of how the feature would work and what the main screens should do, I sketched some layout and functionality ideas for each key screen, then iterated until I arrived at the final version.
The Quest Selection Screen
Once the app analyzes the user’s spending, it will generate savings “quests” for the user to choose from. The quests would be based on which discretionary categories the user spends their money on, and the amounts would be based on how much a user typically spends on that category in an average week.
The user would then choose which quest they want to try.
The quests I set up for this case study are based on the categories people mentioned in user interviews as their top “I would really like to cut down on this” indulgences.
Originally I thought I should have an option for the user to create their own custom quest because they know their spending and goals better than anyone, but then decided it would be too complicated to do for the initial version.
This screen has to accomplish the following:
- Convey the essential information about each quest: how much the user spends in a week, how much would be transferred every day, and how much a user would save in a year
- Provide access to additional information, such as user’s history with the feature, feature settings, and information on how the feature works.
- Provide an easy exit from the feature back to the rest of the app’s functionality.
The Quest Overview Screen
I built out just one quest for the prototype. I picked coffee as the easiest, least individualized thing because I did not want people to get hung up on “well, I don’t buy XYZ kinds of clothes!” in testing. I thought that even the people who don’t drink coffee would feel comfortable using the feature as if they did, for testing purposes.
The quest overview screen had to fulfill the following functions:
- Provide the topline financial information about the quest with more room to describe what each number signifies.
- Provide the user’s spending data the quest is based on, and a way to edit it. Maybe they buy coffee for the office once a week and get reimbursed for it, or maybe the app pulled in something that’s not coffee at all.
- Provide a CTA to choose when the quest would begin, and a button to confirm starting the quest once they choose the starting date.
The Quest In Progress Dashboard
The quest in progress dashboard presented a few challenges. I needed to show a lot of information in a compact way, and I spent some time exploring different layout ideas and deciding on which information would really have to be shown on this screen.
I ended up fitting the days indicator in one horizontal row, with quest-specific numbers displayed just below. The informational links are present in a less prominent way, and if the user needs to cancel the quest for whatever reason, the Capital One default big red button is hard to miss.
05. VISUAL DESIGN
The feature had to blend seamlessly into the existing app, so I looked for Capital One’s style guide. Unfortunately, I couldn’t find it in open access, but I did find several portfolios of the designers who worked on it. The style guide has evolved since it was created, but by cross-referencing the designers’ portfolios with the screenshots of the live app, I was able to put together a decent approximation that was close enough for the purposes of this project.
Typography
The Capital One app uses a proprietary font called Optimist. I couldn’t find it for download because it’s proprietary, but I did find a fairly similar font, Taxon. I recreated the typographic scale from Rob Huddleston’s portfolio and adjusted it slightly so that it fit over the screenshots from the app.
Color
The color palette has evolved quite a bit from the designer portfolio sources, so I mainly relied on the screenshots for color reference.
Icons
I found the entire Capital One icon set on Phil Marine’s portfolio, which made me very happy because now I didn’t have to attempt to recreate them. I reused existing icons and combined two of them to create the main icon for my feature.
06. TEST
Next came the moment of truth: testing. Will the users understand how the feature works? Will they care? Only one way to find out.
Testing Goals
I wanted to find out the answers to the following questions, in general order of importance.
- Do the users understand what the feature does?
- Does anything about the feature make the users uncomfortable?
- Would the users want to use it if their bank rolled it out?
- Does the onboarding provide all the information users need?
- What types of notifications would the users want/expect?
Testers
- Six women, one man
- Age range: 28-55
- Two existing Capital One customers
- Five wished they could save more than they currently did; two were happy with their current rate of savings
Tasks
- Set up a new SaveQuest
- Complete one daily transfer
- Explain to me in your own words what the feature does and how it works
Test Process
Because I was testing two different tasks, each with its own set of screens, I decided to create two different prototype: one for setting up a quest, and another for completing a transfer.
The Setup prototype asked the user to set up a new SaveQuest to limit coffee purchases for a week.
The Transfer prototype asked the user to imagine it’s day one of the quest and they did not buy a coffee today.
I made small iterations on both prototypes after the first two tests made some glaring usability issues quite apparent.
I kept the changes small and quick – altering copy, making minor layout changes, etc.
I knew these changes would skew the test results, but since I lined up a good number of testers, I treated each batch of 2-3 testers as its own separate test and iterated between them. This approach kept the process more nimble and I learned a lot more this way.
Testing Outcome Summary
Wins
- All testers successfully completed both tasks.
- Testers liked the feature overall and said they would be interested in trying it out if their banking app rolled out something similar.
“I like that it’s showing me the big picture impact of small spending decisions over time.”
“I like that it’s not shame-y.”
“I feel like it would keep me from spending recklessly without even knowing where the money is going.”
Fails
There was really just one fail, but it was a really big deal.
Most people did not understand what the feature actually does and why it does it until AFTER they completed the Transfer prototype.
This was a really big problem, and the main reason why I was iterating between tests, trying to address this issue. The small iterations I had time to do between the tests improved users’ understanding of the feature and addressed some of their concerns, but did not do enough to fully solve the problem.
07. ITERATE
I made the following iterations to make the feature’s functionality more self-explanatory to the users:
- Revise the onboarding screen
- Add contextual instructions
- Adjust the notifications
1. Onboarding
People did not read the onboarding screen no matter what I did. The first version was a wall of text, so I should have known nobody would read that, but even after I broke up the text and added more visual hierarchy, they still did not read it.
None of it mattered. Five testers dove straight in. Two skimmed through the instructions, but did not pay close attention. They all expected the app to tell them what to do and why while they interacted with it.
“I didn’t worry about the instructions because I know and trust my banking app. I would be a lot more careful if it was a brand new app I just got from the Apple store.”
I did not try breaking up the text into separate screens because I ran out of time and users to test it with.
It is important to provide an onboarding screen so that the users know the feature made an effort to explain itself to them, but I cannot rely on that screen to do any work other than trust building.
The rest of the feature would have to do the actual explaining as the users interact with it.
2. Contextual Instructions
Once people started the process, they did read and absorb the small snippets of instructions under the screen title. For example, this seemingly small change made a huge difference in helping users understand what they are signing up to do.
However, I realized that this approach can only get me so far. The Select Your Quest screen shown above carries a lot of information, and I could not cram all the instructions about every aspect of it onto the screen, because then people would stop reading just as they did not read the onboarding screen.
For example, several users were confused about the Daily Transfer, and rightly so. The transfers were explained in the onboarding screen but…Nobody Reads the Onboarding Screen.
In testing, the users were willing to continue the process because it was a trusted app and they were sufficiently curious about the feature to proceed. That, or because they knew it wasn’t real and would not affect their actual money.
3. Notifications
Every tester carefully read the notifications in the Transfer prototype. The wording of these notifications was critical.
The first notification had to be vague enough to appear on the lock screen (no reference to banking), but precise enough so the user knows what this is about. The latter took some iterating to get it right.
The original version of the first notification was alarming to people. Clicking on the Confirm option felt risky, especially because they felt the text did not provide them with enough information.
Once I changed it to be more precise (you did not make a Coffee purchase today) and to indicate exactly what will happen next (you will login), subsequent testers felt comfortable and informed.
The Transfer prototype’s in-app notification screen was the “aha!” moment for the testers.
This was the point when they understood what the app was doing and why. I was happy to see I managed to convey it at some point, but less happy that it was at this point and not earlier.
The testers really liked seeing all the information in the second version of the notification. Because it’s a notification, people read it carefully and appreciated knowing exactly what was happening and what they did to make it do that.
Dashboard in Progress
Testers really loved seeing the star appear on the dashboard tracker after a short delay. This interaction felt very satisfying and motivating.
They understood intellectually what was happening on the in-app notification screen, but this was the point when they felt it emotionally – and liked it.
“Yay! I got a star!”
“This would motivate me to do the thing I already want to do.”
Those responses were incredibly rewarding, especially because in the initial user survey I asked how people felt about their finances, and I got some heartbreaking answers:
The iterations definitely improved the prototypes, and I was able to validate that with the last two testers, who had a much smoother experience than my earlier volunteers.
08. NEXT VERSION
The feature needs to explain itself to users a lot sooner. People should not be surprised when the app prompts them to transfer their money after they don’t buy a coffee – or even worse, when it doesn’t do anything because they did not understand they weren’t supposed to buy a coffee this week in order for it to work.
In addition, I need to give users more control over several critical aspects of the feature as they set up their first quest.
1. Add Choose Source and Destination Accounts Screen
I assumed users would have just one checking and one savings account. I also assumed they would want to transfer their money from checking to savings. In testing I found that’s not necessarily the case.
- Some people have individual and joint checking accounts.
- Some people have multiple savings accounts.
- Some people keep all their cash on hand in their checking account, but still want to track how much they didn’t spend thanks to this feature.
Adding a screen where they can choose source and destination accounts before they get to the quest selection screen will accomplish several things:
- Give the users more control over the behavior of the feature.
- Convey to the users that the feature will transfer their money, which was the key missing bit of information.
- Give me extra real estate to reiterate why the feature will transfer their money – i.e. when they don’t make their usual purchase.
I think both of those problems would be solved by adding a few additional screens in the Setup prototype.
2. Add Customize Notifications Screen
Now that I know people read their notifications, I think this aspect deserves some careful attention, and a few additional notifications need to be designed and tested in the next iteration. The feature would also need a screen where the users can control the notifications they receive.
- Quest Starting Soon – the majority of testers said they want a notification the day before the quest is starting to remind them about it. This would be a good place to reiterate that the feature will transfer the money IF they don’t buy that coffee. Because the majority of testers said they definitely wanted it, this notification would be on by default, unless the user turned it off.
- Quest Day – I did not ask if people want it, but it makes sense. People run on autopilot and most of these purchases are mindless. A reminder that today is a quest day would help people adjust their behavior.
- Quest Fail – this notification needs to exist as an option for the minority of users who want it, but it absolutely cannot be on by default. The majority of testers had a strong negative reaction to the prospect of receiving this notification.
“I already know what I did, I don’t need my banking app to shame me for it.”
“F*** you, Capital One, I want my coffee!”
3. Manual vs Automatic Transfers
I believe this should be on Manual by default, because automatic transfers can get people into trouble. Things like bill autopay, checks getting cashed several days later, etc. A single bounced check or late fee because the autopay did not go through due to insufficient funds thanks to this feature, and the user would hate the feature forever.
However, the users should choose to keep the transfer manual, or have the option to change it to automatic during their first quest set up.
One tester said she would assume the transfer is automatic – “that’s why I set up this feature” – and she would normally dismiss the prompt to transfer and not log into her banking app to confirm what’s happening. The same tester said she would not want the hassle of manually confirming each transfer and would not use the feature if that was the only option.
4. Add How SaveQuest Works Section
Even though people skipped the onboarding screen, they all tried to click on the How SaveQuest Works tab once they got to the dashboard screen. It is possible that people wouldn’t feel the need to do that after the above changes are made, but it’s still helpful to have a single place where they can get all the information once they are engaged enough with the feature to want to know more.
The explanation of levels and benefits of each level would be here.
One tester said she would expect this area to also contain articles about nudging and the psychology of behavior modification.
5. Add a Your SaveQuest Section
Users would navigate to this screen via a dashboard option, or by clicking on the bubbles of the tracker. Most testers tried clicking on the bubbles after they set up the quest and it was unsatisfying to them when nothing happened. This screen would have the room to show what happened on each day – i.e. no star on Wednesday because of this Starbucks transaction.
It would also show quest history, cumulative savings over time, success rate per type of quest, a graph of savings increase over time, user’s level and how many stars they need to reach the next level.
09. CONCLUSION
This project was immensely satisfying for me. I got to talk to people about an important and usually taboo topic, and then create a potentially helpful tool to address a real problem. This project showed me that the cliches of UX design are cliches because they are true.
- Talk to the users
- Ask why, then ask why again
- The first answer is rarely the answer
- Testing is everything