Reducing the failure rate

Replacing a plugin by designing from scratch

Years ago, we had incorporated a plugin from a sister business unit to offer our users a specific feature, but recently-updated web analytics said something scary: there were a lot of failures and abandons during the activation flow.

We would need to take a step back and look at the feature holistically to understand the user challenges.

SERVICES

Competitive analysis
User research
Developer collaboration
Design workshop with Product
Wireframing

OUTCOMES

Working to a tight deadline, delivered a user-tested design with style guide and prototype for development.

PHASE 1: DISCOVER

The feature had been an issue for a while. Through previous user studies, we'd discovered that users understood the feature's benefits, but data analytics told us that not many were completing the sign-up process. As the users moved through the activation process, many dropped out or had their activation requests rejected.

The feature was technically complicated and "the database was all over the UI." How could we streamline this experience to avoid user drops? And more concerning, what was causing the failed activation requests once the user did manage to complete the flow?

We spent several days in deep discussion with software architects, product managers, and plugin representatives on loan from the other business unit. We also reviewed user studies performed over the past few years that might yield clues on the drops.

ISSUES

Choosing the right flow entry point
Confusing user flow
Cumbersome sign-up process
Technical assumptions resulting in failed activations
Heavy complexity re: types of activations
Lack of white label capabilities
Lack of responsive design

PHASE 2: DEFINE

Our goal was not to simply re-create the existing plugin with better fonts. We needed to start from the ground up.

Is it necessary?
The plugin had been designed to allow the user to submit multiple activation requests. But expert review and a quick user study suggested that users a) were frequently confused by the UI and abandoned immediately because it looked hard, and b) of those who attempted to use the feature, they only submitted a single request. Multi-activation had to go.

We also identified an entire subgroup of activation types that was little used. Product set about negotiating with our partners in the sister BU to take those off the table, removing a layer of complexity.

Make the right assumptions
Using what we knew about the user at activation time, we saw that we could streamline the flow by pre-filling much of the required information. This dropped the time required to prepare for activation by 70%.

And that technical assumption that resulted in failed activation requests? We removed it.

PHASE 3: DESIGN

Early design in Balsamiq:
Simplify the sign-up process by prefilling important info we already know about, like the email address

Because we were working with a known set of technical requirements, I was able to quickly create the flow as well as a Sketch prototype. One question we had was: What's the best point in the UI to offer this feature?

Testing
We identified the most logical places in the UI for the flow to be initiated, and I updated the Sketch prototype for some quick in-house testing. Of the 4 entry points we identified, 1 quickly proved to be a cumbersome experience so I removed that option.

The updated Sketch prototype was then converted to HTML and handed over to our 3rd-party research partners for study purposes with both existing and new users who'd never seen the UI before.

The results were good: Users identified the entry point that made the most sense for them, and they weren't confused at all by the flow -- they found it extremely straightforward.

The prototype continued to be the design document of record as we worked through several adjustments based on technical findings. At each build, I continued to maintain and defend the streamlined user experience.

White label usage and supporting internal stakeholders
A critical point of the design was to ensure it could be incorporated into financial institution web apps with their branding. After collecting several samples of different implementations, I set about configuring the design to reduce the load on the implementation team as much as possible.

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 perspectives.

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 and enable QA to meet their required in-house performance targets.

I also created a sample flow in Sketch for marketing and product demo purposes using generic financial institution branding.

Reducing the failure rate

Replacing a plugin by designing from scratch

SERVICES

OUTCOMES

ISSUES

Introduce the feature

Entry point

Streamline the flow

What's next?