Redesigning Chase Bank Mobile App: Make it smart!

This is the very last blog post about my journey of creating Mobile Bank application. Eight weeks of the Rapid Ideation and Creative Problem Solving flу by so fast!

From conceptualization and concept mapping to the very first prototypes and to… integration another product into existed wireframes! What a journey!

Last week, when we were about to finish working on our designs and present the final version to the class, we got a new challenge – our bank has acquired a financial modeling product, the intelligent features of which would be valuable for our consumers to have.

The goal was to integrate the following features into the application:
1. Provide a snapshot of your finances and their trends.
2. Allow you to analyze any specific transaction in any account to see if it is historically anomalous in the context of all of your spending.
3. Provide a drop-dead simple “what if” modeling system based on “playing with” your recurring payment amounts, so you can see how changes in monthly spending impact your account.
4. Help you figure out what amount of money is she to spend at any given time.

We had 10 days to come up with ideas, draw dozens of sketches, do usability testing, iterate, iterate, user test, and iterate again, and finally present the result to the classmates and get their feedback.

The implementation of these features made me come up with the new architecture of the app. So, to provide a snapshot of your finances and their trends, I’ve decided to create a new top-level section named “Smart Money” in the main menu. In this case, “Smart Money” is assumed to be a trademark, and a catchy brand name that Chase would market as a differentiating point from the competitors; with “Safe-to-Spend” being another trademark (originally registered by Simple, but, for the purpose of this exercise, also available for Chase to use as a part of the newest intelligent features).

User feedback has called out the need of the “Smart” features to have a “why” and “how” explanation – so that some trust is built between it and the user. Throughout the application, the user is given a fair amount of detail on anything that is a result of financial modeling and analysis algorithms; including the Safe-to-Spend formula, which is outlined explicitly (and is actually not that complex).

Page 2

(click to enlarge)

It was interesting to learn that many users do their budgeting in very, very different ways, so the bank application interface has to be agnostic to a certain budgeting approach as much as possible. We don’t want to force the user to do planning in a certain way; instead, we want to give a number tools to have at their disposal. “Safe-to-Spend”, being one of the most helpful tools here, has to be customizable through Settings, in case the user is expecting it to work in a different way.

Another feature, “Smart Money Notifications”, was getting only positive feedback: people thought they would find it very useful if it was giving insights into their spending patterns and help them save money.

It would be awesome if it could tell me: “Wow! You spent so much money in bars or restaurants! Did you mean to do that?” <…> Oh, it does tell me that!

The “Future Transactions” section that already has existed, fits very nicely with the concept of Projected transactions. Now, “Future Transactions” contains both (1) scheduled transactions, that are actually scheduled to be processed via the Move Money section and (2) Planned and Forecasted transactions, used for financial modeling, where “Planned” transactions are the ones that user has set up, and “Forecasted” are the ones that the intelligent system creates for the user based on the behavior of the user over a length of time. The user is given options to turn a “Forecasted” transaction into a “Planned” one, by confirming it; or they can delete it easily. The user is also provided with some information on why a certain “Forecasted” transaction was created in the first place, and what was the data that was used to create it.

Page 3

(click to enlarge)

One of the big challenges was to find the language which everybody would understand. Especially hard was to find right words for the types of “Future Transaction”. During a collaborative workshop with a potential user we came up with “Projected”, “Planned” and “Forecasted” transaction.

Page 4

(click to enlarge)

Page 5

(click to enlarge)

The existing framework has fit the “What If” projections feature very well and nicely as a part of Planned Transaction creation flow, giving users a way to see how their balance trend changes if a certain transaction is taking place, regularly or in a single occurrence.

Page 6

(click to enlarge)

Lastly, with the ability to analyze anomalies extensively, a very important and useful security feature comes into play: fraud detection. Along with the regular channels (confirmation through a cell phone, text or email), the user would receive a push notification that would lead them into the transaction that seems suspicious to the Smart Money system; allowing the user to easily dismiss the alert, or file a fraud report.

Importantly, the user is given some detail on why the transaction is considered suspicious (in this case, the user has never had history spending money in casinos, and is also not currently situated in Las Vegas).

Page 1

(click to enlarge)


The Navigation Concept Map has transformed quite a bit since the very first iterations of the product, yet is still very simple and straightforward.

New Navigation Concept Map

(click to enlarge or download)


During this course I’ve learned and improved my skillset in the following areas:

  • Rapid ideation and prototyping. From paper to a digital format, to hands of potential users.
  • User testing. Getting the product in hands of users, setting up the right expectations and context, with the goal of extracting the valuable feedback in an efficient way. That was a game-changer!
  • Details matter. Details in the prototype is what helps users immerse and feel like they’re really using a real product.
  • Peer-to-peer critique sessions with the other students at the school. Taking control of the sessions, so that 15 minutes of it would result in dozens of actionable ideas.
  • Taking feedback in general. Defensiveness doesn’t help; empathy does. If someone gives feedback, even some that I might not necessarily like or agree with, they do it because they genuinely believe in it, and it comes from their experience and certain view to things; when my applications get in hands of millions of users, that view would inevitably represent a large cohort of people.
  • Iterating. Taking feedback and making the product better, then taking feedback again.
  • Being efficient in making decisions out of a seemingly infinite amount of possible options. Deciding on things that I, as the design professional, believe would be the most valuable and usable for the consumers.