Banking Not Budgeting: The Perils of Adding Features
Designing Digital Interfaces at AC4D is a mixture of visual design education, user testing, and like many of our courses, an exercise in asking “Why?”
We’ve been tasked with redesigning a banking app of our choice. My choice is Ally Bank, an online-only institution. We redesign by creating wireframes- draft versions (either paper or digital) that can be quickly modified and tested.
Four weeks ago I began to tweak existing features such as checking balances and depositing checks. Over the last two weeks our cohort have been tackling something much bigger: adding budgeting functionality to our banking apps.
My process began with drafting a “Process Flow Diagram.” Essentially, it’s a visualization of how budget functions would fit into existing functions, from the user’s perspective. A process flow details all the choices a user would make when they view a screen, in this case, a mobile app.
After completing a a process flow, I created wireframes of screens that included the new budgeting functionality. And I began to form “missions” for users in order to test the viability and usefulness of Ally’s new budgeting functions.
Here were the “missions” I gave my users, and the reasons why in bold.
Why Are We Doing This?
In full awareness of putting the cart before the horse, these reflections came after my user testing. This assignment gave me the opportunity to:
- Expand my research capabilities as designers by user testing
- Apply a system-wide awareness (using process flows and system maps) into instituting a new app function
- Gain greater empathy for users in using a new function
- Gain greater empathy for my imaginary coworkers at Ally Bank, whose work could be affected by adding the new functions
Banking Not Budgeting
I tested five users, all non-Ally customers. Zero of my five users used their bank for budgeting. None. It didn’t matter whether they used their banking app daily, or only used their bank’s mobile site twice a month.
This leads us to the reason why aggregative budgeting apps exist. The most popular being Mint or YNAB (You Need a Budget). These two apps can do something that single-bank applications cannot: pull in data from two or more financial institutions, budget all expenses in one place, and set goals that relate to a user’s complete financial state.
This led me to a difficult realization: either I imagine that Ally can have the capability of collecting info from different institutions (a la Mint or YNAB); or I operate in the complete opposite sphere, where Ally only tracks Ally expenses and transactions. I opted for the former, which I would come to regret.
“‘Current Flexible Cash’ What the heck is that?”
…stated one user. Current Flexible Cash was my idea to give users a “safe to spend” amount, a subset of their checking account. The idea was for users to know how much cash they have on hand that’s available to make urgent cash purchases.
Here’s how it was introduced. Users saw this designation on their first screen, “Snapshot.” Stuck in the middle of the screen, users communicated it seemed unimportant, and the graph, “confusing.” As they continued their missions, they saw that “Current Flexible Cash” was connected to both “Budget Categories.” Any money that wasn’t budgeted, or in Savings was considered “Flexible”.
I attempted to introduce this “Flexible Cash” concept in a tutorial, which popped up when users clicked the middle button of the Snapshot screen:
From my users’ near unanimous feedback, budgeting is not the expected functioning of a banking app. If introduced, it must not conflict or even interrupt the more common banking tasks. I still have hope that users can find value, but the structure, and especially placement of budgeting functions needs to improve. Perhaps “budgeting” should be its own tab.
All of this confusion resulted in my major takeaway from these tests: in the way I presented budgeting with Ally, users found no immediate value added. For them, the primary goal of a banking app was to check recent activity was accurately documented. Or to recognize inaccurate or fraudulent transactions.
Big Questions & Next Steps
Moving forward, I plan to operate on the reverse assumption of this user test: Ally will not have data from user’s other institutions, and therefore should create budgeting functions that don’t rely on external data, but still provide value to the user.
Ally could theoretically have Mint or YNAB functionality, but why should it? How do we create value with these functions when most use banking apps simply as an official ledger, checking to making sure all is well.
These are the questions I’ll keep in mind when moving forward in doing a Heuristic Evaluation and Cognitive Walkthrough with users.