Chase Online

Research

  • User Testing
  • User feedback
  • Archetypes, User stories
  • Competitive analysis
  • Domain research

Design

  • Brainstorm/Sketch
  • Wireframes
  • Prototypes
  • IA diagrams
  • Design patterns

Deliverables

  • Wireframes
  • Slide presentations
  • Prototypes
  • Design pattern library

Project Overview

Online consumers cost banks about half as much as customers who bank in the real world. Chase, the country's largest bank, wanted to draw more users online to maximize profits.

Early adopters had been banking online for years. Chase now wanted to target users who prefer to bank at a branch. By humanizing their online experience, Chase aimed to attract these wary users.

The team members for this project numbered in the hundreds and were spread out across the country. As the interaction designer on a multi-disciplinary scrum team, my contributions were to:

  • Collaborate with developers to create wireframes
  • Solicit feedback and approval from stakeholders
  • Aid in research planning, create prototypes for user testing
  • Identify, recommend, and document design patterns
  • Propose improvements to IA and navigation

Collaborating for the user

Developers and I worked to simplify flows where users had to navigate across the site to accomplish tasks. A great example is the "Accept Money" flow, which we reduced from 5 steps to 2.

1. In the old design described here, a user takes action on a notification that someone has sent them $40. They click to "Accept Payment" in the To-Do List on the home page.

Old Accept Money flow, image 1

1. The old Accept Money flow began with a user clicking to "Accept Payment" from the To-Do List on the home page.

Old Accept Money flow, image 1

The old Accept Money flow began with a user clicking to "Accept Payment" from the To-Do List on the home page.

2. After clicking Accept Payment, the old design took the user to Payment Activity, where they were asked to "Accept" again. Why? Because, that's where the accept money code lives. Changes to the siloed back-end were prohibitively expensive.

Having told the site to "Accept Money" twice now, the user is asked to confirm (not shown).

Old Accept Money flow 02

2. The user is taken to "Payment Activity," where they're asked to "Accept money," again.

Old Accept Money flow 02

The user is taken to "Payment Activity," where they're asked to "Accept money," again.

3. Finally, the user gets confirmation they have accepted $40 and completed their first task. But, now they're in Payment Activity. Would users know to click the bell icon in the header to get back to their to-do list?

I was sure we could do better. During countless meetings I plead my case to sympathetic developers. They eventually found work-arounds to enable my designs, despite back-end constraints.

Old Accept Money flow, image 1

3. The site confirms the user has successfully accepted the money. Now, how do I get back to my To-Do List?

Old Accept Money flow, 03

The site confirms the user has successfully accepted the money. Now, how do I get back to my To-Do List?

4. In our new design, when the user clicks "Accept Money" on the home page, the message refreshes to show a confirmation. Once the confirmation is dismissed, it is replaced by the next in the list.

This simple change represents some brilliant workarounds by the developers on my team. By working closely together, we found a solution to accommodate both our back end, and our users.

new Accept Money flow

4. The new design allows users to accept money without ever leaving their To-Do list. Much better!

new Accept Money flow

The new design allows users to accept money without ever leaving their To-Do list. Much better!

Maintaining Trust

The dev team and I also collaborated to improve the user experience of "read-only" mode. When the site undergoes maintenance, many components become temporarily disabled. During this time, users cannot edit content, instead they can read-only. User confidence in the site could be affected by how we communicate this.

The old design relied on users clicking on many disabled components. After seeing several error messages, users would presumably log out of the site. Only when they log back in would users see an explanation for the site’s limitations. Imagine their growing concern as users wonder, “what’s wrong with Chase Online?”

1. By working together, developers and I designed a solution within our technical constraints. Now, as soon as a user clicks a disabled component, they trigger a full screen error message. The full screen error explains the cause of the site's limited functionality.

2. Once users dismiss the error, an alert displays above the site as a reminder of its current status. Keeping users in the loop during outages, especially on a banking site, is vital to maintaining their trust.

Collaboration is critical when facing problems like this. Much of my role at Chase was to recruit teammates in our drive for better UX.

Full screen takeover explains Read-only mode

1. Developers and I designed a better way to communicate read-only mode that works within our technical constraints.

Dismissible error message atop site warns users of Read-only mode

2. When the user closes the full screen takeover, an error message shows at the top of the site until full functionality is restored, or it's dismissed by the user.

Full screen takeover explains Read-only mode

A full screen takeover alerts users to the Read-only mode.

Dismissible error message atop site warns users of Read-only mode

When the user closes the full screen takeover, an error message shows at the top of the site until full functionality is restored, or the user dismisses it.

User Focus

The header of a large consumer site like this is valuable real estate. Tools that show by default should get out of the way when user focus turns elsewhere. I established rules governing exactly when the header should collapse and when it should not.

Collapse Rules

Rules for when the header collapses are labeled in warm colors.

Stay Open Rules

Clicks which do not collapse the component are numbered in cool colors.

Collapse Rules

Rules for when the header collapses are labeled in warm colors.

Stay Open Rules

Clicks which do not collapse the component are shown in cool colors.

Value of Interactions

The rules I defined for loading spinners reflect the importance of different interactions.

1. Some interactions are too important for users to move on before the site has responded. When a user is awaiting confirmation on a transaction, we don't want to usher them into the next task. Instead, we cover the site with a white overlay and spinner, to express its disabled state while it loads confirmation.

2. When appropriate, we should not let a sluggish site impede a user's progress. Slow loading search suggestions should not keep users from searching. In such cases, no spinner is necessary, despite an unresponsive element.

Spinner Rule 1

1. A spinner shows over the disabled site while the user awaits confirmation.

Spinner Rule 2

2. The search suggestions are not loading, but that's no reason to keep the user from searching. No spinner necessary in this case.

Spinner Rule 1

A spinner shows over the disabled site while the user awaits confirmation.

Spinner Rule 2

The search suggestions are not loading, but that's no reason to keep the user from searching. No spinner necessary in this case.

Consistent patterns for cohesive experience

During the QA process, I found the site's structure and navigation to be confusing. We hadn't been consistent with component or page patterns. I looked for ways to fix these issues for a more cohesive experience.

I designed low overhead solutions to the problems I found, but would need support for them to be accepted. I began work on a presentation of my ideas to the large design team. As a consultant, who was not asked to do this work, I feared a poor reception of my critical feedback.

The relationships and trust I built by my previous work afforded me some support for new ideas. After weeks of laying groundwork and refining suggestions, we presented to a very receptive design department. While our latest version was on its way to launch, my proposals will guide future iterations of the site.

Dashboard Pattern

I documented existing page patterns to clarify what elements define them.

Hub Pattern

I pointed out the Outlier pages, showing where we deviated from our patterns.

Proposed Updates

I proposed low overhead updates to consolidate page patterns and simplify the IA.

Pros and Cons

I listed pros and cons of both approaches I proposed.

IA Comparison

I created docs comparing our existing IA (on top) with the simplified IAs of my proposals.

Dashboard Pattern

I documented existing page patterns to clarify what elements define them.

Hub Pattern

I pointed out the Outlier pages, showing where we deviated from our patterns.

Hub Pattern

I proposed low overhead updates to consolidate page patterns and simplify the IA.

Full Screen Takeover Pattern

I listed pros and cons of both approaches I proposed.

Full Screen Takeover Pattern

I created docs comparing our existing IA (on top) with the simplified IAs of my proposals.

Conclusion

I gained valuable experience working with such an enormous group of diverse professionals. Collaboration was crucial in solving the problems we faced. During the project, I became very interested in Design Patterns, Information Architecture, and "atomic" design ideas about designing systems of components instead of pages. I hope to pursue these ideas going forward.

The Chase Online redesign was a success in attracting more online users. Over the year of its rollout, the new site saw an increase of 5 million active digital customers. Today, the site has served 64 million people in total.

On Twitter, Chase customers commented about how the site is now "much easier to maneuver around!" Another remarked the redesign is "friendly, looks clean, organized, and easy to navigate."

My work on the project was quite appreciated. My immediate supervisor stated:

"Ben was the key asset to my team. He delivers work on time and with deep detail analysis. He is excellent at uncovering the "gotchas" in any design proposal, and able to provide a number of viable solutions on the fly." - Karin Goers, UX Design Director

Another onsite manager expressed:

"[Ben] is very adept at information architecture and is very savvy at organizing and grouping complex information in a logical and intuitive way. I highly recommend Ben and would welcome the opportunity to work with him again." - Kevin Utz, Creative Director of Digital User Experience