Make My Payments Mobile App

The Challenge

Payment Systems Group recognized that its customers were increasingly using smartphones and that its current website didn’t support mobile devices very well.

We needed to design and develop a mobile app for smartphone customers. The array of account management capabilities on the desktop version made this a daunting task. In order to not create an extended waterfall project, we let Agile development be our guide – create a minimum viable project with features added in quick succession.

Research

In order to launch a viable product with value to our customers, we first had to learn what that was. What would customers need? What do they do most often? Are their behaviors different if managing their account from home or on the go?

We wanted to use two sources for our research – data and customers. Google Analytics was used to provide data on what functions customers used the most and what were the most common tasks. Next, we wanted to explore the minds of our customers.

Our goal was to explore customers’ mental model and stay away from specific site functions (engineering model).

We performed a task analysis of every major function on the customer portal. This gave us an initial guide to what we could bite off for version one and what would be left to tackle later. We created surveys and interviewed current customers and also people that didn’t know about the program.

Then we were guided by “The 5 Why’s.” For example, the Make My Payments website offers some very sophisticated scheduling. Should we simply replicate that or is there a deeper purpose to each customer’s actions? A customer wants to move an upcoming debit to a different date. When does this occur?  Why does this occur? It’s not enough to simply know other bills have come due and they want to move this one. Several “whys” later, deeper answers flushed out.

Revealing Deeper Issues

Planning

Problems We Faced

1. Since mobile is an entirely different animal from desktop, we didn’t want to assume we knew where customers would go for performing tasks.
2. We wanted to solidify where future items would go, even though they wouldn’t be put in version one, the minimum viable product.
3. As a unique service, not many features/functions fell under “conventional categories.” For example, while most customers might expect the ability to change their email address to be under “My Account,” where would “Change My Lender’s Payment Address” go?
4. We wanted to differentiate items for a Kano Analysis: required, desired, exciters, neutral, and dissatisfiers, to help us know what needed to be in the app.

How We Solved It

We asked! We used Directed Storytelling to avoid asking, “what are you trying to do?” but rather we engaged them to tell us a story about why they would need to check their account from a mobile device. “You’re going about your day and suddenly your bill pay account comes to mind… tell me what’s going on.”

It was most important to know customers’ goals, not tasks.

This allowed us to create Concept Maps and Affinity Diagrams. We began to see how customers aligned tasks with goals and more importantly, what they were thinking. Again we were putting the customers’ mental model first.

Fortunately we had already developed personas from a major redesign we did shortly before the mobile app project. We were able to take these already developed personas and bring them into the dialogue.

From the concept maps, affinity diagrams, and personas, we constructed our scenarios and use cases. I made the decision to bring in our development team at this point and get feedback from them before we moved on to design and prototyping. This way, we at least had a “yes, this is feasible” signoff. Anything outside this realm got put to the side for later.

Prioritizing Features

We wanted to prioritize features, not based on guesswork, but on the expected impact on user satisfaction. We used the Kano Analysis to help us. We categorized all the features that came from our current website as well as anything new from our customer research.

For example:

1. If the app allows you to change your debit date, how do you feel?
2. If it does not allow you to change your debit date, how do you feel?

Based on answers such as, “I love it,” “I expect it,” “I don’t care,” “I can deal with it,” and “I don’t like it,” we were able to categorize and prioritize features.

Design & Prototyping

As our first effort at an app, we felt it was prudent to spend plenty of time in sketches and low fidelity mockups.

This was probably one of the best decisions we made as it allowed us to change rapidly with a very low investment in resources and direction. As they say, “iterate early and often.” So true!

We performed generative research by creating cutouts so users could easily swap screens and buttons.  This allowed users to create what they wanted and afterward, we would ask why they made the decisions they did. We performed several usability tests with paper mockups just to test out ideas and get user’s reactions. We brought the development team back in and called it an “arts and crafts” session. Oddly enough, it was a really fun event and garnered significant buy-in from the developers. After all, they weren’t just told what to do, but were able to “own” suggestions and ideas. After several iterations of paper mockups, we moved on to wireframes in Balsamiq.

Usability Testing

Our Balsamiq wireframes were then put out to the test. We performed five studies with eight participants in each group. Balsamiq was a great tool for this, again because of minimal investment in product creation. We were able to quickly iterate, update our script and questions and perform another test.

Final Product