Further Expansion of the Bank App
At Rapid Ideation And Creative Problem Solving Class we are working on designing Mobile Bank Application. After getting critique on my previous app iteration, I continued further expand the application, covering the features and functionality that either wasn’t covered previously at all, or wasn’t covered fully.
Together with that, I’ve been performing a major clean-up of the assets.
Previously, every block would be its own element, or set of elements, on every artboard within my Sketch file. Need to make a slight adjustment to an element that repeats on many screens? Sure – go through every of these screens and apply it. This week, I’ve finally learned Sketch Symbols and have rebuilt most of the artboards using mainly Symbols, taking advantage of overwrites and even nested Symbols and nested overwrites. It’s been a huge help and I am expecting it to speed up my work significantly going forward.
The image below illustrates the number of screens designed; the image shouldn’t be used to examine individual screens. More detailed screen shots are shown throughout the blog post.
A feedback from previous classes was that all screens should be purely black-and-white (shades of grey). During the cleanup, I’ve turned most of the interfaces into greyscale colors, accommodating the other supplemental feedback received. However, elements like “Back” buttons, system dialogs, and the main navigation tab bar still contain blue color. The reason is that I try to rely on iOS interface templates – which guarantee that the users will find the UI more familiar since it’s similarly used in many, many other apps. Turning the tab bar into greyscale colors, unfortunately, had a negative effect – it was really hard for the users to see which tab is currently active; whereas Apple by default marks the active tab with blue color. An option was finding an alternative visual treatment to the tab bar – making an icon bigger and the text bold, for example. I’ve decided to let the blue color stay to ensure consistency of using native iOS elements to ensure easiest adoption.
All “Move Money” screens got populated with actual icons that make sense and I am expecting that to simplify the experience of using those screens.
Horizontal sliders in the “Move Money” sections are mainly for quick access; you can get to any item using them, or you can click “See All” and get a list of all possible options within the section.
I’ve developed more screens for 3 tab navigation items (Accounts, Activity, Move Money), added “Add to Favorite” switch to all Move Money flow and developed screens that manage your “Favorite” transfers.
I’ve implemented a feature that hasn’t existed before in the Chase app; to my knowledge, none of mobile bank application have that feature. I call this feature “anticipated transactions”. If you have monthly (or weekly, or bi-weekly) subscriptions or autopay set up, most likely your transactions form a certain pattern that is very easy to follow. Every month, there’s a transaction from Cable/Internet, from Cell Phone Service provider, from iTunes, from Spotify, and so on. Usually, it ends up on about the same day of every month.
So why can’t we show it in the “scheduled transactions” section? Although those aren’t really “scheduled” – as in, you didn’t schedule them in the Chase application – they are most likely to continue happening, and the estimated amount of the transfer is known beforehand. I’ve added it to my designs. On the designs above, T-Mobile’s $80.99 is the “anticipated” transaction with an estimated amount.
It’s hard to notice; I’m exploring the ways of making it more apparent to the user that certain “scheduled” transactions are just “anticipated” transactions, – what should be the visual treatment or language around it? That’s a feedback that I’m asking at the class.
I performed user testing with 5 users, and this time they were tasked to accomplish the two goals:
- Check transactions scheduled to go out of their Checking Account in January;
- Pay your American Express bill. Add that payment into “Favorites” for easy access in future.
As always, people were completely unfamiliar with my design of the application; all of them were also first-time users of prototyping software like Invision.
Everybody has completed the first task easily and didn’t have any issues.
However, to my surprise, the process on the second assignment wasn’t as straight-forward as I thought, and one user has spent an excessively long amount of time accomplishing the task (although, as he mentioned afterwards, his wife does all the bills for him and he doesn’t ever use mobile bank apps).
Some of the areas of the app that users had the most problems with were actually prototype issues, and not necessarily design issues:
- Most users tried to swipe the lists in the Move Money sections. Which is correct behavior, but is not realized in current Invision prototype, and to my understanding it’s not possible to realize that feature in a prototype at all.
The following problems were actually design issues:
- It was hard for most people to realize that See All is a functional button that they can click to see all options available (in lieu of swiping, which as mentioned earlier is not supported in Invision)
- Some people have clicked “Chase Bills” right away, although that option is only supposed to cover internal Chase bills (for example, Chase credit cards or loans); and an American Express credit card would be found under Credit Cards option. Everybody was able to get there but in a different amount of time and effort.
Testing the app with real people shows we how critical it is to have all buttons clickable on every screen because sometimes people’s behavior is unpredictable. One user tried to go through all buttons on the tab bar first because he wanted to familiarize himself with the app before he starts to complete any tasks.
This week I’m going to concentrate on Chat – a function that does not exist in current Chase Bank App. And of course, continue to do user testing to get inspiration for further improvements!