Integrating Financial Modeling Into Banking : Learnings From Prototyping And User Testing
Designing Digital Interfaces is by far the most tech heavy class we’ve experienced in our three quarters of study. Previously, our use of design software was based on deliverables for projects that weren’t digital products. So, we taught ourselves Adobe Illustrator and Sketch at our own pace and learned to use it in our own creative processes. For Chrissy Cowdry’s course we are all learning the standardized (albeit constantly changing) methods of wireframing and prototyping, and applying them towards mobile bank app redesigns. Our research methodologies and service design aptitudes are coming into play heavily whilst re-thinking an existing app. At the same time, the skills we are learning in this course are becoming handy in all of our other courses where we are being asked to make shit, and make shit fast.
The second portion of the class is to integrate financial modeling features into our traditional banking apps. The product must include:
- A financial snapshot interface
- A way to check on anomalous transactions
- A “what if” scenario for spending decisions
- A feature to help you decide how much is safe to spend at any given time.
Having very limited experience with finance analytics tools was a disadvantage for me and I needed to do some secondary research to inform what I would want to see in my product.
I had signed up for an Intuit Mint account to track my budget and spendings when I became a student with meager savings 7 months ago when I started at AC4D. I spent thirty minutes setting it up, and I haven’t looked at it since—until a week ago when I investigated how things were looking. While I know I’ve done a decent job of self-restraint over the past months, my Mint account didn’t give me a clear picture of where my money is being spent. I was particularly confused by the budgeting categories and transactions that were being grouped under them. There was a haphazard doctor appointment under groceries. And my city bus tickets were going towards financial spending?
I decided that organizing clean and specific parameters around my budgeting categories, as well as informing the product that, for ex. my bus tickets are actually a transportation spending, would be the quickest route to finding clarity and getting the most out of the tool.
After toying around with the app I grew frustrated that there was no way for me to tell the product that not just one, but ALL of my payments to Capital Metro, are bus tickets, in the past and in the future. I decided that since this was secondary research and I wasn’t in the field to do this testing, I would bring at least one subject matter expert to help find the solution to my probably.
So I opened a customer support chat with Mint and chatted with Stephon for a few minutes. I was disappointed to hear that, indeed, I can’t make rules for payees from the mobile app. Stephon instructed me to navigate to the web app to perform this task.
Stephon sent me a list of instructions and I taught the computer how I wanted my transactions and payees to be organized.
I didn’t find this particularly delightful or effective, so I decided that designing a more efficient rule-making feature for budgeting would be the first step to my new redesigns.
Designs and User Feedback:
I made wireframes for several scenarios and satisfied the features that the assignment required within those scenarios.
Scenario 1: The user gets an alert that they’ve gone way over on their transportation budget and they are prompted to investigate the cause and solve the problem. In this case the user sees that their Delta flight purchase needs to be better categorized and so they go through a once-and-done process so that the app will be smarter at sorting payees in the future.
Scenario 2: The user is saving up for a trip to Rome and realizes that they are behind the timeline they expected. From the financial “snapshot” landing page, the user is asked to find two ways to adjust their savings and spending guidelines to expedite their savings for Rome. In this case the user is able to manipulate the “what if” spendings feature to decide to cut down on eating out at restaurants. Additionally the user can adjust the percentage of their monthly savings they are committing to Rome by de-prioritizing the shoes and motorcycle they were also saving up for.
In this deck I talk about the responses I got from users during testing:
Wireframing for this assignment was tiresome and more ambiguous than the previous redesign of the banking app itself. It was more difficult to find a cohesive user flow and making symbols consistent throughout the wide-ranging capabilities the product was confusing.
From my users I have come away with several key insights to reflect on and use to build my next iteration.
- As a designer, don’t overcompensate in complexity because you started off not understanding something. Instead a designer should better use their resources and spend more time studying users.
- I assumed that everyone wants full accessibility on their mobile apps, whereas my participants expressed that they wouldn’t find themselves doing these tasks on-the-go. Banking and financing isn’t something users necessarily do on the subway or at lunch.
- A tutorial for first-time-use would be of benefit. I had conversations with multiple users in which I heard that they are used to having to tinker around with apps to familiarize themselves.
- A good app should be simple enough to be understood by someone who is new to finance and sophisticated enough for a weathered expert. Financial wellness is a trending topic and someone who is just starting to make money should have the same access and understanding to manage their income and investments as someone who has had money and saved money for decades.