Adding Analytics to a Mobile Banking App

We’ve been focused on creating screens and redesigns for a mobile banking application for the last few assignments in our digital interfaces class. This new assignment threw us a curveball. The prompt was to imagine that the financial institution we’ve been working with has recently merged with a company that specializes in financial analytics and modeling software. Our challenge was to integrate this new technology into our recently redesigned mobile banking application and test it with users.

Finding Inspiration

The first thing I did was look at a few existing budget and money analytics tools that currently exist. I used Mint a few years ago, so started by re-logging into my account to review how they have it set up.  I know that many people really like mint, but it never really worked for me and always felt kind of burdensome. I’m also not a fan of circular graphs and charts so in reviewing mint I knew I wanted to do something a little different than what they have created. Next, I thought about applications that I really love and ended up opening my Airbnb app to review how they have it set up. Despite it not being a banking app, I found it really useful in how straightforward and clear they present information, and place emphasis on providing users simple tools and tips to improve their bookings or activity. These were both things I wanted to include in my screens.

Testing Methodology

After creating my screens I sat down with 5 users to test the functionality and see what they thought. My goals were to make screens that were clear, intuitive and made people feel like they had the tools to improve their budgeting/spending/saving if they were so inclined. To do this I asked participants to use the think-aloud protocol. This is similar to a stream of consciousness where the testers talked me through exactly what they were seeing, thinking, and doing. Using this method helped me understand the why behind what they were doing.

The four flows/tasks and the screens involved.
The four flows/tasks and the screens involved.

Testing Results

I found that I hit that mark with some things, but missed on others. Overall, testing really helped me see where I could make edits and improvements in my design.

Monthly Budget Overview Screen
Monthly Budget Overview Screen

For example, Flow 1 and 2 the user goes to their monthly budget overview screen to better understand their spending for that month and see if it’s safe to spend $200 they weren’t expecting. This screen came across as overwhelming for all my users. Being struck with lots of numbers, a math equation, and a graph all at once was too much. Additionally, having the safe to spend amount in the top right corner was not very noticeable, and the legend for the graph was missed by many participants. To solve these issues, my thinking is to either remove the equation at the top of the page (since this information is also in the graph) and the legend. Then I will add labels next to the call out of the amounts on the graph and when they are clicked an additional info popup will appear to explain more in-depth what these numbers mean if a user is interested. This should make the screen cleaner, and more approachable.

Things that users really liked about this screen was the clear status indicator at the top and the smart filters at the bottom. All my users thought the smart filters were great and said they would use them frequently instead of filtering through their transactions looking for certain things.

Anomalous transactions flagged by the app with spending insights.
Anomalous transactions flagged by the app with spending insights.

In flow 2 users were asked to look for transactions in their checking account that the app may have flagged as anomalous. Every user first looked at the amounts, then the recurring buttons, followed by the entity name label, and then finally found the information button flags. In my next iteration, I plan to move these buttons to a more noticeable location and change the icon to be more of a flag instead of information.

On the message screen almost all the participants were surprised that the message was related to their spending habits instead of a fraud security alert. Some said they appreciated it, but the general consensus was that there should be an option to have control over what gets flagged and the messages they receive. Many also said they would expect to see any important messages when they logged in, and not have to go search for them.

Click here to run through the wireframe flows yourself!

What I learned about testing

I learned a lot about the value of user testing, and what makes it run smoother.

  1. Scenarios and the wording used in setting up tasks for users matters. For example, in flow 2 where users were asked to look for flagged transactions, the wording became very important in differentiating that they were looking for potentially fraudulent activity or just transactions that were out of the ordinary for their spending habits.
  2. The more mundane the context information the better. I found that testers can easily get distracted by filler information in wireframes, especially if it’s not believable or stands out in some way. For example, on one screen I created savings accounts for dog savings and fun money just to show that a user might have multiple accounts to choose from. Labeling these as “dog savings” and “fun money” caught people’s attention and distracted them from what they were doing.
  3. Test with your mobile device, but turn the lock function off during testing. I found it really helpful to have users test the mobile app on either theirs or my mobile device to the functionality felt more real. However, I did not turn the sleep function off, and it became annoying to keep having to unlock the device throughout the testing session.