Role
Research, user testing, copy writing, UI design, UX design
Timeline
Mid–late 2017
Collaborated with
Product manager, engineering, user research, customer support
Company
Weebly
The problem
Connecting a payment gateway such as Stripe, Square, or PayPal is how sellers accept payments through their Weebly online store and is a crucial part of getting to ready sell online. However, only about 30% of sellers who visited the payment gateway setup page successfully connected a payment gateway.
The opportunity
Re-examine the checkout setup page & experience of connecting a payment gateway in order to help sellers complete this important step and become ready to sell online. This was also an opportunity to refresh the UI of this page to bring it more in line with the rest of the product and promote a cohesive visual across the Weebly product.
Problems with the existing experience
Existing data
As mentioned, only 30% of sellers who visited the checkout setup page eventually connected a payment gateway. It took them an average of 2-3 sessions to do so, and about 12 hours after first viewing the checkout setup page. Of the payment gateways we offered, Authorize.net was clearly the least used.
Hypotheses
On reviewing the existing checkout setup page, I immediately had a few hypotheses for why sellers either abandoned the page entirely or took so long to connect a payment gateway.
Decision paralysis – We offered 4 different payment processors to choose from: Stripe, Square, Authorize.net, and PayPal, and we gave very little guidance around why a seller would choose one over the other. Were sellers legitimately unable to choose which to connect?
Arduous connection flows – Each of these payment processors had their own connection flows that we had no control over, and they varied in their usability and efficiency. If sellers did finally choose which to connect, was the connection flow for the processor too arduous for them to complete quickly, or at all?
Visual & cognitive clutter – This page also included other tangentially related settings that cluttered the page and obscured its main purpose of connecting a payment gateway. If we removed or hid extraneous settings, would that make it easier for sellers to complete the main task?
Informational interviews
In order to test our hypotheses, my product manager and I conducted four interviews with owners of online stores. We asked them open-ended questions about accepting online payments and had them walk through the existing checkout setup. Our goal was to gain a deeper understanding of how sellers think about accepting payments online, and hopefully pinpoint specific points of confusion within the current setup experience.
What we learned
Confusing language – Much of the terminology we were using on the page—terms like “payment gateway”, “payment processor”, and “digital wallets”—was no better than technobabble to the sellers we spoke to.
Unclear requirements – It was not clear to anyone that they could only connect one of the available credit card processors (Stripe, Square, or Authorize.net), but could connect PayPal in addition to any one of the credit card processors. The sellers we spoke to indicated they would just connect as many as possible in order to give their buyers options and capture as many sales as possible.
Lack of knowledge – Once they understood they needed to choose a credit card processor, they were at a loss as to how to make that choice. No one knew the differences or relative benefits of the three options, and only PayPal had any name recognition at all. They indicated they would need to leave this page to do research on their own.
Overall, it was clear that sellers were quickly confused and overwhelmed by the options on the page, and we were falling extremely short in the guidance and information we were providing. There were obvious opportunities to clarify the language we were using on the page, as well as opportunities to provide more insight & guidance so sellers didn’t need to do their own research.
Explorations
We decided early on to drop support for Authorize.net. It was the least used of the payment gateways we offered, and its connection flow was the most complicated, with arcane requirements and unfriendly UX.
From there, I began exploring different layouts to clarify the relationships between the various options and the actions a seller needed to take. I started with just looking at different ways to lay out the information on the page, but these explorations didn’t push the experience far enough or offer enough additional guidance to the seller.
If we really wanted to guide the seller through making this choice, why not introduce an actual recommendation engine? A seller could answer a few high-level questions about how they want to take payments that would allow us to recommend which payment processor was best for their business.
User testing
We decided to test two prototypes to gather initial impressions—one with the recommender and one without. The main goal was to understand how much incremental user confidence the recommender provided, and if it would be worth the additional engineering effort to build.
We did nine tests over three days, with my product manager and I trading off who was leading the testing. After each day of testing, I quickly modified the prototypes to try to narrow in on what was working.
Version 1 of the prototype had all gateway options on the page, with no recommender
Version 2 had the recommender in its own step
Version 3 had the recommender on the same page as the options, and selecting recommender options dynamically highlighted our recommendation below
Version 4 was the same as version 3 with one distinction: the recommender starts with an option already selected, and a recommendation already highlighted below
What we learned
Users wanted to play with the recommender. Having the recommender in a discrete step, separate from the results it provided, inhibited this and caused sellers to bounce between steps, ultimately making the entire experience more clunky and not in line with sellers’ desires.
Users understood the copy a lot better. The recommender options resonated with sellers, as did the value props for each payment processor.
The differences between Stripe and Square were minor and inconsequential. The recommender is also merely repackaging the same information expressed through each processor’s value props. If we clarified those further, would we be able to achieve the same educational results without the recommender?
Final designs
In the end, after discussing with engineering and reviewing our learnings from user testing, we decided the recommender was not worth the additional effort to build. We were confident we could achieve the same results with a clear layout and copy.
Plus, from existing user data, we already knew how our users typically intended to sell—online only, with as many payment options available to their buyers as possible—meaning we could confidently recommend Stripe to sellers without them needing to use the recommender. Stripe offered the ability for sellers to accept more payment methods with Apple Pay and Google Pay, and Square’s most differentiating feature—the ability to sync their online business with their offline business—was not as compelling to sellers who primary business was online only.
Outcome
We launched the redesigned experience in an A/B test with the existing experience. The results of the test overwhelmingly favored the new experience. New sellers placed in the test group with the redesigned experience had a higher success rate connecting a payment processor than those in the control group.
After launching the new experience to 100% of new sellers, we saw around a 40% increase in payment gateway connections.