An old feature had a high failure rate, so we set about figuring out what had gone wrong.
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 from holistically to understand the user challenges.
Design workshop with Product
Working to a tight deadline, delivered a user-tested design with style guide and prototype for development.
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 users 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.
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 design 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, 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?
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 perspective.
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.
I also created a sample flow in Sketch for marketing and product demo purposes using generic financial institution branding.
Users don't want to be interrupted in their task to learn about a new feature. Put it out there and let the user choose to engage.
Offer the activation opportunity when the user is focused on the bill.
Prefill as much user input as possible
Be clear about any next step or consideration.