Benefits of having a Shopping Cart (as opposed to "straight to checkout")

Question

I have a client whose colleagues are pursuing an eCommerce Out of the Box product that doesn't have a dedicated shopping cart screen. Their product works such that when you want to buy something, it goes straight to a full checkout form.

"How can the user add more items then?" you might ask - the product lets the user go back to the catalog and "add" more things, but there's still no Cart page. Even the menu label they have is "Checkout" (rather than Cart + icon)

My client and I are averse to this solution knowing the psychological comforts and conventions in having the security blanket of a cart, but I'm struggling to find secondary research to demonstrate that not having a cart is bad, and/or there are measurable benefits to specifically having a discrete shopping cart page before checkout commitment.

Answer 1

I've experienced ecommerce sites where after adding an item, a modal pops up that gives me the option to checkout or continue shopping. It's not entirely annoying since I typically don't add a ton of items but can imagine how it could be. Dictating a user's experience for them (i.e., forcing checkout) is a surefire way to get people to abandon.

You could make the CTA more aligned with the action that is going to happen next such as not labeling it as "Add" since you are technically not adding it to a cart or bag, but maybe label it "Buy" instead so it makes it more clear that you may head towards checkout by clicking on a "Buy" button. Additionally, if the client is wanting customers to buy more even though checkout is forced upon them, on the subsequent page, you could have a list of recommended items or "customers also bought" with a quick add button.

When you click on the [Checkout] button, does it show the items first? If so, maybe you could still get away with labeling the checkout button as [Cart]. I'm a proponent of having a dedicated cart, but I also know the hassle of stakeholders not budging or willing to allocate resources to dev so I'm trying to think of how you could create the illusion of a cart to the customer with this out of the box 'solution.'

Lastly, like someone else said, grab a few users and have them go through your store. Try to record their responses through video or audio to show your stakeholders if they can get through the experience without a cart. You could even send out a questionnaire with questions like, "Can you explain step by step what you believe a retail experience should be like?" "Where would you go to change the quantity of an item?" etc.

Answer 2

If it is the cart they oppose, don´t give them one. What you do need tho is a way for the user to see everything they have selected, delete stuff, edit quantities or add stuff. That is in fact a cart, but you don´t have to call it that. Call it pre-checkout, or even just put the functionality in the checkout page.

What you do need is a way for the user to easily know how many items they have selected, via either some sort of small icon or a popover.

Answer 3

I'm not sure I'd agree with the "psychological comforts and conventions in having the security blanket of a cart." Users are used to it as it's the norm when shopping online, and it does have value to confirm all the items before receiving shipping info if that's being calculated on the fly.

I'm more concern with: When a users selects an item to they go right to the checkout page? Or can they select it and stay on their page to continue browsing? Does the checkout page have full features for users to drop items or increase quantity?

It's unlikely that any research about carts will have actual value for your client's site. There's probably more value in doing a trial run with this product and drafting a test plan so in X time you can compare a different tool and see if you can improve results.

Answer 4

How do you get measurable results? Run a usability test and measure the results. That said, I wasn’t positive from the question if it was the development product manager, the client you’re providing the page to, or your development colleagues who were opposed to UX testing. If it’s the paying customer, you do what he or she wants.

One way to steer the direction is to provide mockups early on, and possibly a mock of the UI you’d like to see. They may be thinking you’ll charge them more for two pages, because two pages is more work than one. Another reason might be to split credit payments off on a separate page for PCI DSS compliance; make sure to ask them to check with their QSA.

Also keep in mind that splitting one page into multiple pages should be an easy task. If you deliver it and they don’t like it, it shouldn’t take much to fix it.

Regardless of all of the above, one lesson that’s hard to remember is that you are not the target audience of the page. Things that may be common sense and straightforward to you and I may appear complex and convoluted to other people. Don’t rely on your own judgment to determine which is the “best” UX for your client.