Budgeting Meets Banking: Adding Features to an Already Complex App
Last week’s challenge was to add in additional features to our banking app, specifically budgeting features. This included an overview of finances and their trends, a ‘what if’ feature that allowed people to alter their recurring bills to see the effects on their budgets, the ability to compare a single transaction to other past transactions, and a simple way to see what is available for someone to spend. Incorporating all of these features was a challenge. They each overlap in various ways and could have numerous paths a person could flow through. Below is an overview of the flows, you can see that there are several repeated screens, indicating that they show up in multiple flows.
To begin, I built out a Spending and Budgets section that housed the majority of the required features. It could be accessed in multiple ways, from the More menu, through the View Accounts section, and even from individual transaction details (as seen above). While I spent a lot of time configuring how I thought people would handle each of the tasks presented them, I realized in my first user test, that I was very wrong.
I ended up conducting in-person user tests with five individuals between the ages of 28 and 38 with a variety of banks. All but one of them used banking applications on their phone. The breakdown can be seen below.
I met each participant in-person and presented them with four tasks, one at a time. They were instructed to think aloud, so that I could get a better idea of someone else’s thought process for each task. I also watched their behavior, which allowed be to probe on certain actions to understand why they were doing certain things. Below are several major problems that my app encountered during user testing.
Problem 1: Transaction Comparison
While creating the flows, I thought that tasks that involved individual transactions would send people through the Checking Account page and list of transactions to the Details for that transaction and then to the Spending and Budgets sections (like seen below). Unfortunately, people wanted everything to be accessible through the Spending and Budgets and I had not finished building that feature out with all its functions. For instance, one task was for people to compare their last HEB grocery trip to their past grocery trips. To do this people could go to their HEB transaction, click Details, see that it was under the average grocery trip amount, click More Info and see a direct comparison to the average grocery trip over the last 6 months (as shown in Fig 3). Unfortunately, this is not at all how people managed this task.
Several people said that they would just manually compare their past couple grocery trips either just in their head as they browsed or by exporting an excel sheet. Two people managed to click on the Details button, but were confused about the actual comparison box. Most people tried to attack this task by going through the Spending and Budgets screen in Figure 4. They wanted to see the Grocery breakdown and figured if they wanted to compare grocery purchases that this is where they would go to do so. I figured that this could be a way to access this information, but I thought that someone’s first inclination would be to go through the transaction screen in accounts.
While it was disheartening to see that people couldn’t figure out my intent, it was good to see how other people attack the tasks, so that I can better prioritize which features to add functionality to first. This was echoed by a participant who told me that he didn’t even want the granular ability to compare one grocery trip to another. He just wanted to see spending in Groceries by month. Sometimes he just goes to the store for beer and sometimes it’s for a large family trip, so he knows there will be plenty of disparity between trips.
For this issue, I would want to be sure to make all the pathways functional, especially by coming from Spending and Budgets. That’s where people are looking for the information, so that’s where they should be able to find it.
Problem 2: Habit Changer
Another similar issue came to light for the Habit Changer feature. This allows people to alter their recurring bills to see how it affects their budget. This feature was again accessible through the transactions page under Details on recurring bills (Fig 6). People wanted to find it from the Spending and Budget page under the various categories, but they could not click on them. Almost all of the participants missed the button that says ‘Change Your Habits’, which gets them to the Habit Changer page (Fig 7).
Problem 3: Available Money
The last major problem that I encountered was around the quick look at what money is available for someone to spend. I created a Money Bar that had a breakdown of where someone’s paycheck is allotted (see Fig 8). It included the amount that would be going to monthly recurring bills, the amount that would go to their savings account and the leftover money that was free for them to spend. I thought I would put it on the View Accounts page, so it was easy viewing for those who wanted to see it quickly. However, this was clearly a bad design as many of my participants had no idea what it was telling them. Not an easy, quick look after all.
Several people told me that it was confusing that the amounts did not add up. To solve this, I would either put the income breakdown on a totally different page or I would include the Checking and Savings into the breakdown. Instead of having a breakdown of the paycheck, it would show your Savings and Checking, but would show one part of the Checking as reserved for your outgoing recurring bills. This would hopefully cut down confusion and would give people a clear answer to how much money they have available to spend.
Through my user testing, it was really clear how important testing with other people is during the creation of a product. Last round of user testing, tasks were more straightforward and people had a fairly easy time navigating the system. This time, not so much. But, I learned a ton by just getting my product into the hands of someone else and watching them interact with it. It helped me really understand what pathways were intuitive to people and how they think about the tasks at hand and will allow me to better situate where things are housed within the app.
The other learning that I had during this round was that free food and beer are great motivators for people to come do user testing. Having the cohort bring their friends to AC4D and do user testing with people they don’t know was a great way to get participants that I didn’t know. And a great way for them to see what we’re doing and to get free food!