“Why bother? Nobody else does. And besides it wouldn’t make that much difference if we did it anyway.”

This is a statement sought out by organisations focused on customer service as it is often an X marked on a treasure map of opportunity to differentiate their offering.There was a time when most online stores had a line of code along the lines of this for a basket summary.

[code lang="actionscript"]summary = 'You have ' + nItems + ' items in your basket.';[/code]

Nice and neat. A single line of code, the smallest piece of additive logic. But it means that when I add a £2500 television, my purchase is summarised with “You have 1 items in your basket.” 1 items? Imagine this in a physical store. I’m about to hand over two and a half grand for a telly and you’re not even taking the time to acknowledge I’m buying one item instead of many. Why not go the whole hog and call me Sir/Madam?

Most online stores have seen the light and use something along the lines of this.

[code lang="actionscript"]summary = 'You have ' + nItems + ' item' + (1 != nItems ? 's') + ' in your basket.';[/code]

But to a programmer this is messier, it lacks the elegance of the original line of code, but an organisation with a user centric approach realises that their customers see the output of the code, not the code itself and their programmers understand graceful code should never come at the cost of user experience, in the same way that beautiful design should never come at the cost of impaired functionality. Yes Apple, I’m looking at you.

The observant of you will be realising I am a pedant

The observant of you will be realising I am a pedant and wondering what difference 1 items really makes. Very little, I suspect, but it’s the little things that make a difference between a good user experience and a great one, and fixing 1 items tells your users that you are paying attention to them and that you care about them.

The best thing about this approach is that the cost is usually negligible in relation to the potential returns. This example of 1 items was prevalent and was very easily fixed as I’ve shown, and I’m convinced that other examples are worth fixing too. ’1 items’ has become the term I use to describe any lazy or inconsiderate bit of coding that impacts on the user experience and although there are few literal examples of 1 items these days, there are plenty of examples of the thinking behind it.

The 1 items that annoys me most exists on every airline website I’ve used recently. I fly a lot, and almost always on my own. I always check in online and always look to improve my seat position. Here’s the system logic behind this process.

  1. User clicks to change seat and is presented a list of passenger on this booking with seat map that highlights currently assigned seats.
  2. User selects a passenger.
  3. User selects a new seat.

I have been doing this regularly for quite some time now but I still forget to click my name in the list of passengers and go straight to click on the new seat only to presented with an error asking me to select a passenger first.

why do I need to click first to dismiss the error and then scroll back up to click my name, only to scroll back down to try and find that new seat with extra legroom at the exit

Hold on. It’s just me here, do you see anyone else? Nope, there’s the list of passengers – I can see you know it’s just me, so why do I need to click first to dismiss the error and then scroll back up to click my name, only to scroll back down to try and find that new seat with extra legroom at the exit.

This is a system considered from the system’s perspective. It is logical and probably runs from short, neat code. Sure it’s not optimal for the user, and although we could optimise it, why bother? Nobody else does. And besides it wouldn’t make that much difference if we did it anyway. After all users that get it wrong are just being stupid – we even have step by step instructions at the top of the page.

Well maybe I am being stupid, but N.E.R.T.F.M. and why wouldn’t you want your system work the way my mind works instead of expecting the instructions to modify my minds process to match the process you created for your system.

At the risk of stating the obvious, here’s how your users naturally approach the seat allocation process.

  1. Hmmm. I wonder if there is a better seat available. I’ll click the button and check.
  2. Look! There’s a great seat near the front of the plane where it will be quieter than sitting behind those big engines. Give it to me!

If I have 1 items in my basket then the system knows that I want me to sit on the newly selected seat. It won’t take a lot of code for your system to work it out and I then won’t be hassled unnecessarily – just return me to the page with the option to print my boarding card, confirming that 3C is my new seat.

The beauty of taking a user centric approach to designing your systems is that you start to discover other opportunities to improve the experience. I started writing this article with the goal of fixing the 1 items problem in seat allocation, but by considering the user’s logic I now see that I can improve the experience for that couple flying to Paris for a dirty weekend.

I started writing this article with the goal of fixing the 1 items problem in seat allocation, but by considering the user’s logic I now see that I can improve the experience for that couple flying to Paris for a dirty weekend.

Their logic is the same as mine, despite having 2 items in their basket. They look for better seats and when they see the two available seats in row 5 they click the seat to begin the process. You can’t know for sure which of them intend to move to this new seat, but instead of displaying an error, why not just provide a prompt with the list of passengers asking for who’s to move and then continue as if they’d done it the other way round – the ‘logical’ way. It might even be worth assuming it’s the first person in the list of passengers as it was them that booked the flight so there’s a good chance it’s them doing the online check in, but it would be important to make it easy and obvious to the user how to change which passenger was just moved.

So who’s going to be first to reconsider seat allocation from a user’s perspective? It’s a simple fix that’s all about logic – and a little extra code. It’s not going to save me any significant time in checking online but it will prevent the tinge of alienation I get when you ignore the fact that we can both see that I have only 1 item.