Mobile Banking App: Opportunities for Improvement

Throughout quarter 2, we redesigned various mobile banking apps. We are continuing to build upon the redesigned systems this quarter through additional evaluation methods. To set some context, the following is the process we’ve used to arrive at where we are today.

Process and Methods

We went through the identification of user goals and the creation of narrative scenarios around those goals. We also created concept maps that allowed us to articulate the system’s components in a way that the relationships between them and the system’s overall “shape” could be understood at once. This shape is the mental model that users begin to build through experience with the app. By zooming out to this diagrammatic level of abstraction, we are able to create alternative ways to organize the system that are more coherent and more directly support user goals. Once we were confident with the system’s organization (aka the system’s “architecture”), we were able to begin creating potential representations of the screens, or wireframes, that the app might contain. These were organized into flows through the system that mapped to user goals, like “depositing a check”. Each flow was subjected to evaluation by two methods:

  • Think-aloud testing: observing users while they describe aloud what they are doing and what they are thinking along the way. This method uncovers difficulties users have with comprehending the system and can offer insight into their pre-existing mental models around the domain in question.
  • Formal critique: soliciting feedback from colleagues on the quality of the design based on their opinions.

This brings us to where we are this quarter. We have added two additional evaluation methods to our arsenal to cover different aspects of the design:

  • Cognitive walkthrough: based on theories of cognitive problem-solving in unfamiliar situations, evaluators go through a series of task-based flows (such as “depositing a check”) and ask themselves a few questions at each step. The questions put evaluators in the mindset of a new user to evaluate the learnability of a system.
  • Heuristic analysis: evaluators determine whether each element onscreen, throughout the entire system, follows or breaks a set of well-established guidelines for designing a user interface. Because this method covers every element on every screen, it is much more comprehensive than the other methods which are task-oriented. Each heuristic amounts to a rule that should generally not be broken. We have performed these two methods on our wireframes, and what follows are the results from mine.

Results

Each problem identified can be classified as either an issue that is required to be fixed or one that can be lived with, at least in the short-term. I will be focusing primarily on sharing those issues which would be required to be fixed before releasing the product. However, I’ll also be sharing a significant enhancement that will likely contribute greatly to user satisfaction. Primarily because this project is at the pre-development stage (no code yet), it will be relatively easy to address most of the problems, at least in the wireframes. To see full lists of the problems, refer to the following files:

PDF files for reference:

Problem #1: Users have no way to recover from a forgotten username/password. (Heuristic Analysis—problem ID 5)

For the case that a user has forgotten either the username or password, the design offered no clear path to recovery. This is an absolute must-have prior to release. The following image shows the proposed solution to this problem as well as two others (lack of a Log In button and the clear separation of the Touch ID link).

Issue-01

Problem #2: The available options for setting up recurring payments does not allow for full customizability—e.g. every 3 weeks is not supported. (Cognitive Walkthrough—problem ID 29)

In the following proposal, the Custom option is provided for those users who have the need to enter a recurring payment using less common frequency parameters. After selecting Custom, users would have to enter whether they would like the payment to recur daily, weekly, monthly, or yearly and then how often. For example, the user could now enter “weekly, every 3 weeks”.

Issue-02

Problem #3: The system does not indicate that the back of the check must be signed before the photo is taken. (Heuristic Analysis—problem ID 57)

With people using written checks less and less, it’s likely that some users will not understand that a check must be endorsed with a signature prior to depositing it. Those users would receive a failure-to-deposit message, perhaps days later, with no prior indication that this was a requirement.

Issue-03

Problem #4: If users change their mind about an entry made on an earlier step only after completing other steps (of a payment/transfer/deposit), it is cumbersome to back up through those steps in order to make the one change. Additionally, the user feels as though they must confirm each subsequent step moving forward again. (Cognitive Walkthrough—problem ID 11)

The proposed solution to this problem also addresses another significant problem (Cognitive Walkthrough—problem ID 3) where the user is disoriented because they are dropped into the middle of a flow without having a window into all of the information required to complete the task successfully. The proposed solution is to include a summary screen where the user can see each piece of information required to complete the task, can enter that information in any order, and is always confident that the selections that were made are being saved appropriately. Among all of the enhancements proposed during the latest round of usability evaluation, this is the one that is likely to have the greatest positive impact. The following example shows how this would play out for the Pay a Person task. The same pattern would be applied throughout the app for other Pay flows as well as Transfer and Deposit.

Issue-04

Next Steps

In practice, designers must make subjective decisions to balance the consequences of breaking the “rules” against the details of the particular context and user goals. We’ll be presenting our findings this evening and then going on to make those subjective decisions which will also include thinking about feasibility.