Overview
Clover, a leading purveyor of point-of-sale and business management systems for SMBs, has historically relied on its sales team and reseller partners to sign up merchants and create software and hardware packages for them. To increase sign-ups on Clover.com, we set out to improve the purchase journey and give merchants more freedom to choose the right system for their needs. I led content design on the project, from concepts through research and all the way through launch. All work was completed over an 8-month period starting in November 2022, and positive results were immediate.
Background
The existing experience was not effective enough in getting users to confidently purchase a Clover system.
Starter, Standard, and Advanced bundles were presented in comparison grids with dozens of rows that required users to evaluate software and hardware at once.
The bundles were not really what people needed. Of new accounts created across all sales channels between June and Sept 2022, only 40% of merchants ended up with combinations featured on Clover.com.
We wanted merchants to feel less confined in their choices and empower them to think through what they really needed in a system.
Concepts
We set out to design a flow in which merchants could build a custom Clover system with their preferred mix of hardware, plan, and accessories. We went mobile-first because more than half of prospective merchants navigate to Clover.com on their phones. Our proposed flow broke plan selection into two steps, positioning our restaurant plans as add-ons to the other plans that were not vertical-specific.
For plan selection, I was challenged to not lean heavily on the names of the plans because some of them are not very descriptive, such as Payments, Essentials, Register. Could we even avoid the word “plan” completely to make it more about them evaluating their needs and picking features to match?
As we explored UI, I explored ways to frame the plans on the plan selection screen. Things I tried on: being explicit that features were additive, recommending based on business type, and playing with voice.
None of these were working, in large part because the plans were not distinct enough to be summed up in a few compelling words. The main differentiator between Payments and Essentials is the ability to create an inventory of items, and the only differentiator between Essentials and Register is the ability to create variations of items. Things got clunky fast.
Research
Once UX and content were locked up (and I finally landed on a direction for the plan selection content that felt natural), we were ready for user testing. I took part in a research question generation session and made sure to include questions about content in the interview protocol.
Primary research questions
Do merchants understand the choices in front of them?
What type and amount of information is needed for merchants to confidently make decisions?
What do merchants expect from specific UI interactions or terms that we use?
What else do they need to know in order to feel ready to make a purchase?
Our researcher carried out moderated, 30-min interviews with two prototypes. We spoke to business owners who are the decision makers across a mix of verticals (retail, services, quick service restaurants), with a mix of years of owning their business and experiences owning a POS system.
The big difference in content between prototypes is the progressive disclosure of plan and device features. One version has no descriptive copy on the plan and device selection screens, and a shortlist of features for each plan when you open the accordion to view more, and the other has a short description of the primary features up front, and the full list of capabilities in the expanded state. We thought that if people were going to open the accordion no matter what to see everything included in the plans, maybe we could keep the unexpanded view really clean.
Here are the two prototypes we tested:
Key findings:
People preferred more information. They liked the descriptive text and grouping the longer list of plan features helped with readability.
People understood that each subsequent plan contained everything from the previous, so I didn’t need language such as “Everything in the previous plan, plus X”.
Without the word “plans” anywhere, users weren’t sure if a device was included in the choices on the first screen. The illustrations may have added to the confusion.
The restaurants screen added friction for people who it did not apply to. It also looked like an upsell. One of the restaurant merchants we interviewed skipped to the next page. Users had already spent energy picking a plan on the previous page, so seeing a new set of features was confusing.
The changes we made to alleviate the pain points were:
Branched the flow from the start to show users the three plans most relevant to their business type. We added “Plans” as the CTA on the branching page, but kept the word “plan” off the selection screen in order to frame the question around their needs.
Without a restaurant add-ons step, we could change the CTA on the plan page to “Devices” to alleviate confusion about whether devices were packaged with plans.
Final flow
We did some refinement of the UI, and added back the plan names as eyebrow text so that they’d be listed properly in the user’s cart at the end of the flow. (It would be confusing to see “Take and track payments” as a line item.) We applied the same treatment to the accessories page, so that all screens contain the same cadence of info: eyebrow, title, description, and accordion with more details. We ultimately reduced the number of features listed under each plan because the containers were getting really long. I worked closely with product marketing to fact-check the content in every element, and QA’ed every screen.
Based on our research, we hypothesized that the system builder will be utilized at the top and bottom of the funnel, as an intro to our offerings that sets the stage for doing more research on POS systems, and the tool merchants use to purchase once they’re ready.
Here’s what the final flow looks like for a restaurants merchant.
Results and future plans
We measured conversion by those who select “Continue” on the cart page, which leads them into a credit application that will determine whether they are eligible to process payments with Clover. Three months after launch, we saw that users are on average seven times more likely to convert after going through the system builder than had they added a preset bundle to their cart.
We noticed more users were using desktop than expected—45%—so we set about optimizing the design for desktop. I led an impact/effort matrix exercise on next steps in which I gathered up the items on our wishlist of small improvements, plus the nice-to-haves that didn’t make it into the v1, and other suggestions that had emerged post-launch. After sorting the list together, we saw that many fit into the low effort/high impact quadrant, and updates got underway.
