Don’t try this at home kids
13 April 2010
I’ve recently completed a review of a prototype e-commerce site for a corporate client. Every time I do a job like this I learn something new about the silly stuff web developers do because they think about system and interface design more than they do about user needs.
This time I picked up a couple of classics which I’d like to share with you, because they establish some key rules of user centred design. Things you don’t want to try at home with your own shiny new site.
Number one – where should you put the user registration page?
Now this one sounds totally obvious, but so I don’t sound like a total smarty who’s never locked his keys in the car, I should point out I’d had about six sessions evaluating the site before I twigged to this issue.
One of the key tasks of this site is the user log-in. Retailers seeking to order from the site need to log-in to access the e-commerce functions. Now there were some problems with the design and location of the Retailer log-in link, which I duly dealt with. Then I suddenly thought – what if you don’t have a log-in, how do you apply for one?
I had a look round, and realised I couldn’t see an application form anywhere – but I was darn sure I had seen one at some point. So I checked every pixel of the Homepage and the Contact us page – nothing at all. I checked a few other possible but less likely spots. Grrrrr! Nothing. Then I had an idea – I clicked the Retailer log-in link, which took me to a page where I could enter my log-in to open a shopping cart. And there was the application form. I knew I’d seen it somewhere, and here it was – in the last place in the site that I thought to look…
Go on, you do the maths.
It’s an invitation to register as a user, and it’s in the last place I (a representative user) had looked. Not the second place, or the third… the last place. So it’s a serious usability issue. It made me feel stupid… and web users really hate that.
Why did I feel stupid? Because the registration form was behind the link you click to log in. Who clicks that? Only users with log-ins, actually. So the very people who have no reason to click this link (users who don’t yet have a log-in) are the very ones who must somehow guess that this is the thing they must do. Furthermore – it’s accessible only by that one link in the top navigation. It’s a page you’ll never get to from any other page, or from a text link, or by using the search function (read on to find why you can’t search for it).
So take a deep breath and repeat after me: “if you want users to register for a log-in, make the link really obvious”.
The Homepage is a good spot for this, because lots of folks go there; and so is Contact us, because it makes sense on a semantic level – requesting a log-in is a kind of contact initiated by your users. So that’s where they’ll look.
Number two – when is a search box not a search box?
This is another classic that shows how web designers can get tricked by their knowledge of a site’s back end. Users never make decisions based on back end knowledge, because many of them don’t know where the back end is, they just see graphic interfaces, and to them that’s what sites are.
It’s not dumb, it’s human. We understand what we see in the light of our experience – our mental schema. If users’ experience doesn’t include how interfaces and databases interact, then as far as users are concerned, that interaction doesn’t happen.
This is illustrated by what happened when I tried to use the Search box on the B2B site I’m talking about. I was looking of that pesky log-in registration form, and I tried searching for a few key words, such as ‘registration’ and ‘log-in’ (all the different spellings, actually: login, log in, log-in…). I was mystified, no results at all, did this darn thing even work? Now that’s a usability issue of sorts, if the thing’s actually busted… But then I had an idea, and I searched for a key product category, and – bingo!
This search box was a blank text box, with the heading ‘Search’ written on the left side, and a nice clear button on the left labelled ‘Go’ (I personally prefer omitting that heading and putting ‘Search’ on the button: but whatever, I was just trying to start the engine on the pesky heap by this point, I didn’t care so much what kind of tyres she had).
But what I’d realised was indeed a usability issue, and it was related to that heading by the box.
This one wasn’t a real search box at all, not one that used a search engine to interrogate the text contents of the web pages. No, this was a ‘Product search’ box, one that only interrogates the database of products that sits behind the site and underpins all the e-commerce functionality.
Calling it ‘Search’ tricked me into thinking I could use it to look for page content like annual reports, or directors’ names. The developers all knew it was actually a database search, because they built the blasted thing – so from their perspective, it didn’t need an explanatory label – ‘everyone’ knew what it was.
Wrong, wrong, wrong!
The site’s users absolutely needed to be told this, so they could use the search to achieve their goals quickly and easily. Otherwise they were going to waste time like I did, and either eventually realise their ‘mistake’, and feel like a bunch of Homer Simpsons told to take their pick in a roomful of shovels – or they were going to ring or email customer support (perhaps in their hundreds, if all went well with the site launch) and report that the Search was broken.
And that will cost money, and then it won’t be the customers whacking their foreheads and grunting ‘Doh!’ It’ll be the web developers who are doing that – the ones who knew what kind of search it was in the first place.