A+FCU Banking App + Financial Modeling Capabilities
In our Designing Digital Interfaces course, we’ve been working on integrating financial modeling tools into a mobile banking application of our own design. I’ve been working with my own redesign of the banking application for A+ Federal Credit Union, a local Austin credit union primarily serving education employees. Within the expected functions of a banking app, the financial modeling features that I’ve integrated include viewing a quick overview of financial status (income, spending, and upcoming bills) and a deeper view into spending habits. I’ve also added functionality that allows users to view what amount of money is safe to spend at any given time, including the ability to set a ‘reserve’ amount and add notifications for nearing and exceeding a ‘safe to spend’ amount.
PROCESS + GOALS
I created wireframes for 2 separate flows which I then tested with 4 participants in their homes. For background research, I asked participants what bank they use, what budgeting tools (digital or analog, if any) they use, and what their primary financial concerns are when thinking about their budgets and spending.
My participants, who ranged in age from 22 – 40, were asked to accomplish 3 tasks for each wireframe flow. My primary goals were to understand how users navigated through the different financial modeling tools, how easy it was for them to understand the categories and vocabulary assigned to the tools, and what functionality they felt was missing.
IDENTIFIED PROBLEMS + PROPOSED SOLUTIONS
I discovered a number of problems throughout the wireframes and flows I constructed, but the most prominent problem is in the structuring of the features within the system (information architecture and navigation) and the headings used to describe them in the menu, where most of the features are currently located. Users had differing interpretations of what information they expected to find within each category heading, but no single user was able to navigate quickly and easily to the correct place.
To revise the screens, I intend to consolidate the ‘budget tools’ categories into one ‘finances’ bucket and nest that within ‘transactions.’
Another problem that I discovered is that the categories in the ‘total spending’ visual are not quickly interpretable. In its current form, a user would need to click on every slice of the visual to know what category it refers to.
To revise this, I intend to add a clickable legend to the visual, both to make the visual tool easy to quickly access, but also to give users an alternative path to navigate to individual category transaction details.
Our original assignment in the course was to redesign a banking app. Through this exercise, I got my first real taste of wrapping my head around information architecture. It was difficult, but because my redesign focused on the app’s core functionality, it made sense to place links to key tasks on the home screen, where users would be most apt to need those functions.
When it came to integrating the financial modeling features, it was challenging for me to decide how much of those features to integrate where it would be highly visible to users, but not take up precious real estate needed for core functionality. On the other hand, I was wary of isolating and hiding all the financial modeling tools in nested menu areas where users weren’t apt to ever find or utilize them. To add to this, of the 4 test participants I spoke, most don’t use budgeting tools (1 participant uses mint.com rarely), although they all expressed the feeling that they should and would like to. That leads me to feel even more strongly that key pieces of budgeting features should be established on highly-accessed core areas, but link to more robust sections of financial modeling, to allow users to dive deeper as they see fit.
Another key takeaway from my testing was how important context is when considering usage. I tested my apps in users’ homes, which gave me an appreciation for their lifestyles and needs. While I was working with Keara, a single mother of a toddler, her son was making his disapproval of us known, and known loudly. He was tugging at her, vigorously inspecting my camera equipment, trying desperately to tap the computer keyboard, and eating post-its. In the middle of the test, she turned to me and said,
“See, this is good for you to have someone who has a child hanging all over them trying to figure something else out. This is real life.”
Seeing firsthand how distracted, by necessity, Keara was has shown me how important it is for her to be able to find the information she needs from an app quickly to be able to accomplish her task and refocus her attention. If an app requires too much reading or interpretation, she’s not going to want or be able to use it.
After this round of user testing, I’ve identified some key problems with the structure of the information architecture, which I will address first. After restructuring where the financial modeling features ‘live’ and how users can access all or parts of them, I will also revise the smaller, individual problem areas that are caused by poor or missing user interface elements. After my revisions, I plan to test with a new group of users for feedback and further iteration.