When Web Developers Dont Consider Usability

It should come as no surprise that many ecommerce sites suffer from poor usability because technical decisions are made like this email thread from a newsgroup that found it’s way to the Internet:

Hi all,

Quick question. I want to implement a shopping cart. I know this has
been done a million times in a million open source projects however I
have a few questions, and seeing as everyone in here seems so
knowledgeable.

What I’d like:

1) User can add to shopping cart without having to check in. (checkout
requires login).

2) User can leave the site and un-checked out shopping cart data will
remain.

The options I have to implement the shopping cart:

a) Cookies – satisfies 1 and 2, but assumes user doesn’t turn off
cookies
b) HttpSession object – satisfies 1, but not 2
c) Database shopping cart object – satisfies 2, but not 1.

I’d like to know,

a) am I basically correct with these assumptions.
b) What would people recommend based on their experience.
c) any struts open source project that might have this?

Thanks very much,
Brian

Essentially Brian asks what is the best way to save the contents of a shopping cart so if a customer leaves the site, the customer can pick up where he/she left off without requiring registration to add products or access the cart (otherwise known as a “persistent shopping cart.”)

Since today we’re more enlightened about the perils of required registration before checkout – namely its impact on conversion, the first response to Brian’s question should shock and disturb you:

I think you’d make your life easier if your required login.
.V

When web developers are more concerned about how to make their own life easier, rather than provide the best customer experience, you get advice like this.

The second response also lacks consideration / understanding of the end user:

I haven’t any tech input, but I’ve an idea how I’d stagger the
development.I’d forget about cookies and db’s at first, save them for a
later stage.

1. Store your cart in session, and when that all works. For everyone.
Gets to the checkout and funds are exchanged.

2. Create a login where clever stuff like saving your objects to db’s
goes on.

3. Then once you’ve a logged in user start thinking about when to save
the cart.

None of what I’ve said is ground breaking, but It does avoid messing
with cookies, up to this stage. When the user logs in s/he gets his/her
cart back.

4. I guess the final stage could be to do the cookie stuff, so users
are logged in as soon as they get to the site. And thus the retrieval
of the cart also, as its already in place integration would be smooth.

Don’t know who useful this is, but there’s nothing to offer in terms of
the actual mechanisms in play. But by getting folks paying asap, the
extras don’t become show stoppers.

Cheers Mark

It’s clear the developer is not thinking like a customer. He assumes that customers either proceed to checkout in one session (as per his advice not to worry about cookies), and that customers will inevitably create an account (“When the user logs in s/he gets his/her cart back.) Problem solved, right? Brian thought so…

Hi Mark,

Actually this is EXACTLY what I was thinking of doing.
The one problem that I had with this idea is that I was
a bit worried about filling up the session object with
lots of stuff.

Is this not really a problem?

Cheers,
Brian

It is a problem, customers don’t behave this way. Customers don’t understand why the contents of their carts disappear when they close their browser. They don’t know they can magically get it back if they create an account (and really, they can’t if they’ve registered in a new session). And they hate registering! These “extras” are showstoppers!

Brian seemed pleased with the recommendation. His concern about “filling up the session object with lots of stuff” is warranted – this could cause performance problems which also affect user experience. But the Brians of the world need to understand current web usability best practices when considering the optimal solutions for an online store requirements.


Related Articles

© 2014 Get Elastic Ecommerce Blog. All rights reserved. Site Admin · Entries RSS · Comments RSS
The opinions expressed here are of the individuals and do not necessarily reflect the views of Elastic Path.