Convert With the Simple Click of a Button
Retailers with physical stores devote a fair amount of time towards crafting window displays and meticulously shelving products. Similarly, eTailers should strategically design their eCommerce sites with ease-of-use in mind. How easily a shopper can navigate from the product page to the cart to checkout can mean the difference between a successful conversion and an abandoned cart. Do shoppers need to go through multiple pages, or can they get to what they need in one click?
There is nothing more frustrating than a website that is difficult to maneuver. We have all experienced the frustration of not being able to find something that we need. Not only does it deter from the browsing experience, but the frustration also decreases our desire to buy. How do you build a great eCommerce experience that not only improves the browsing process, but also encourages conversions?
The shopper has already shown interest in your product and arrived at the product page. Often the shopper has to make some choices about options (we call them attributes) associated with that product before they can add it to their cart; attributes such as color, size, width, etc. The UI needs to present these attributes so that the shopper can easily interpret the breadth of available choices, but also be able to quickly make a decision. What type of attribute selection method drives more conversions?
Dropdown menus are one option. They are compact and can help de-clutter a busy page. On the other hand, it can be difficult to compare available options with a dropdown and they become clunky when containing a large quantity of options. Radio buttons are another option. They present all available options without having to interact, but the drawback is that they occupy significantly more page space. Regardless of which option you choose, the desired goal is to increase conversion by creating product pages that are easily maneuverable. The less effort a user has to put into a click, the more likely they are to engage.
Building upon this basic UI principle, we set up an experiment that presented all (non-color) attributes as dropdowns on Version A:
And attributes displayed as buttons for Version B:
Dropdown menus don’t visually present all of the available options right away. Instead, users need to interact with the dropdown menu first in order to see what is available. By presenting them as buttons, one click can lead to a decision, eliminating the need to parse through a dropdown menu. Buttons allow the user see all of the options available immediately, enabling them to make decisions quicker and with less effort. Presenting options as buttons is an easier to read and easier to interact with experience, thus a customer would be more inclined to complete the selection process and follow through with the purchase.
The experiment ran for a period of 22 days in which the experiment received 204,156 unique visitors. The audience was limited to desktop users to see how they would react to the new interface, with plans to run additional experiments on tablet and mobile spaces.
The switch from dropdown menu to buttons resulted in the following results on KPIs:
- +1.4% Checkout Page Views
- +3.2% Order Conversion
- +4.1% Total Revenue
We saw increases in all three of the key conversion funnel metrics; checkout page views, order conversion, and total revenue all went up. Also of interest was engagement on the attributes themselves. Presenting the attributes as buttons suppressed attribute engagement by -8.5%. However, this was expected! The Buttons variation presents all available options without requiring any user input; users did not have to investigate what was available by first engaging a dropdown. Less clicks leads to less user effort and more conversion.
With this particular site, the amount of options for each attribute is small, usually somewhere from 2-10 options per attribute. Buttons work well here because of the limited scope of the data set. However, what if an attribute has an extremely large quantity of options? Maybe those options need to be broken up into more than one attribute, or a multi-step selection process needs to be utilized.
The major takeaway from this experiment is a new hypothesis that attribute selection UI should be content-based and designed around the context of the data you are presenting. There should be a correlation between the data structure and the interface design. We plan on re-running this experiment on other sites that have different data sets associated with their attributes.
You don’t know with certainty which implementation will be best for your eCommerce website until you implement it and test it. Be careful when you’re deciding how to design and implement your features.
It sounds like common sense, but it is important to understand that the UI needs to satisfy both the users’ needs and the demands of the underlying site data. It is necessary to advise caution when implementing new features. What may work for one site, in one space, may not necessarily work for you. We cannot emphasize enough the importance of engaging in testing and seeing how performance differs in various spaces.
Thanks Shanann, I'll do just that.
Here's an interesting follow-up to these results.The site we ran it on has separate tablet and mobile sites. This first experiment was focused strictly on desktop experience. We re-ran the experiment on the tablet site. The reuslts were poor! Over a 50 day period and 143K unique visitors, we saw the following results:
- -1.8% Order Conversion
- -8.0% Revenue
We thought for sure it would be a slam dunk for tablet too, but the results surprised us. Thus, we came up with a secondary theory that on a smaller screen space, the attribute buttons were taking up too much visual space and pushing the add-to-cart button too far down the page, possibly being below the fold. We made some modifications to the attribute buttons to more efficiently use the screen space, pull the add-to-cart button higher, modify the appearance of the buttons to be more touch-friendly, and also make the selected options more obvious via text callout:
Then re-ran the experiment a 3rd time over a 15 day period with 36.5K unique visitors. The results were even worse:
- -14.3% Order Conversion
- -15.6% Revenue
Clearly the button display was not working in a tablet environment. We're still formulating theories around why, but the current theory is that users viewing on a touch device simply prefer UI compactness over information availability.
Great idea, however how do you add a button? The article does not mention how to use the tool to implement this and I can't find any step by step instructions on how to create it. Does this require coding or is this an existng feature in the X platform?
Unfortunately there's no way in the visual editor to simply copy elements without using any code.