Bring-em on board

Users thought "setting up" their bills to pay was a pain

Setup. It's the task users love to hate. And in our case, users would rather pay their bills the hard way -- logging into each merchant site or using individual merchant apps -- rather than let our online bill pay app collect everything in one place.

With our solution, users could log in once a month and pay everything. But would they?

SERVICES

User research
Developer collaboration
Design workshop with Product
Wireframing

OUTCOMES

Working to a tight deadline, delivered a user-tested experience that 70% of target users said they would use.

PHASE 1: DISCOVER

Our first job was to understand who was and wasn't using their banking bill pay, and why.

Our research over the past few years was validated by an updated study: One subset of consumers would never use their banking bill pay for a variety of reasons while another subset consisted of power users who rarely paid bills outside their banking app.

So we turned our attention to those users who were open to using online bill pay, but either never had or who used it only to pay a bill or two. Research during Discovery showed that they just didn't think about it -- their habits were so ingrained that they just never thought about paying bills in any other way than using their current, laborious approach.

Our work, then, would be to "break into" these ingrained habits in order to provide a simpler, streamlined experience that would save consumers time each month with an "auto-discover" feature capable of finding bills they already pay in other ways.

But we really had 2 problems to solve that ran counter to each other: Make it easy and "smart" so the consumer didn't have to do much to interact with the feature, but still give the user a sense of control over the entire process and avoid the process feeling "creepy."

ISSUES

Keep the flow as frictionless as possible -- until we want users to slow down
Create friendly, reassuring messaging
Aim for a one-click experience wherever possible
Design for responsive -- this would be used on mobile, tablet, and desktop

PHASE 2: DEFINE

Sketching out a simplified flow

As with all payment-based apps, we had to start first with the perception of security, including the user's sense of control. We wanted to make sure they felt comfortable throughout the process.

Convenience versus the creep factor
We'd been watching the sea change from "I don't want my bank knowing anything about my bills" to "my bank should help me out without my asking them to," and this feature was falling in line with that.

But research had shown that consumers wanted to be in control of the process, so no "auto-discovery" without them kicking things off. This added a couple of steps into the flow, which we roughly sketched out and tested with a bare bones prototype.

Context, context, context
Throughout the research and definition phase, we continually focused on our design intent of honoring the user's current context. We were about to interrupt their day; they might be accessing our app while away from home and, therefore, their paper bills; they might not even get paper bills and not want to flip back and forth between apps.

This meant simplifying everything as much as possible: the language, engagement options, and user interactions. We developed some basic guidelines: use bullets instead of a paragraph of text for legal language; show the "easy" options that don't require the user to look up anything first; allow the user to quickly skip past the feature if they wanted to.

Making the hard sell
One feature on offer in this new onboarding flow involved getting a little personal with users and their credit reports. Given the current situation of fraud alerts and identity theft, we knew consumers might not want to use that particular option.

So we focused hard on the messaging to make sure users felt comfortable with that service. During our research, we A/B tested different content presentations and tones. With the results of that testing in hand, we were ready to move into building wireframes.

PHASE 3: DESIGN

Because we were looking at a responsive experience that would be used in 2 different applications, we needed to take a step back to evaluate our approach and ensure the design would work in both environments, across multiple breakpoints.

Forward-thinking basics
We started by evaluating the 2 applications for navigation, design system usage, interaction patterns, and tone. Some style adjustments were needed to accommodate the older application, but the fundamental experience was identical.

Managing user speed
Because the "add" experience was so streamlined and quick, we were concerned that making it too easy to remove things permanently - as in, you're never going to get this back - would make for a poor user experience. So we intentionally created a delete experience that had a little speed bump to give the user another second and click to consider their decision.

Keeping everyone informed
All along the way, the design team held several design reviews with the cross-functional stakeholders: ADA (Americans with Disabilities Act) experts, software architects, development team leads, product management, and quality assurance leads. These reviews enabled these groups to become familiar with the design as it evolved and offered them the space to provide insights from their perspective.

PHASE 4: DELIVER

A coalition of experience and content designers then broke down the prototype into detailed wireframes for use by the development teams. Using Sketch, we provided flows for the teams based on the user stories they'd defined from our prototype and design reviews. In that way, our flows would map cleanly to their work breakdown in Version One.

We also worked closely with our excellent UI web developer as he created the foundational HTML and CSS the engineers then used when coding the feature.

I also created a well-received prototype in Sketch for marketing and product demo purposes using financial institution branding.

White label mockups

Representation of the widget within an iframe on an FI's web site.

Bring'em on board

Users thought "setting up" their bills to pay was a pain

SERVICES

OUTCOMES

ISSUES

White label mockups