This same effect can be used in design. Here in the UK, or at least near where I live, pedestrian road crossings are being replaced with a new generation that exploits this principle. It’s going to save lives.

The old generation had a button on the pole to start the crossing timer, then you looked across to the other side of the road to above head height where the green/red man (Walk/Don’t Walk) display was located:

Press the button on the pole...

...then look away from the traffic

The new generation have the green/red man located on the pole, but crucially, your attention is directed so you are forced to look in the direction of the oncoming traffic:

New control has the wait signal in line of sight of the oncoming traffic

You can apply this same principle when designing software interfaces:

• Spend time thinking about what parts of your interface will have your users attention then carefully position these so that other events can occur within the same field of vision
• Progress indicators guide a users eyes from left to right as the percentage complete increases. Use this to direct a user’s gaze to the next element they will interact with – e.g. the ‘next’ button that will become enabled or a region that will fill with content
• Group conceptually related elements. When laying out your interface if related controls are grouped together, your software will feel more fluid. People will look near related controls first and they’ll be happy if they consistently find things where they expect them to be.
• If you need to lead someone’s eyes to an element that is not currently visible … make sure that you scroll it in to view!

When a seat is reserved it says, for example:

“10 Sheffield to Leeds” (referring to ‘Seat Number’, ‘Reserved From’ and ‘Reserved To’ respectively)

If it is free it says:

“This seat is not reserved”

The problem is that the screens aren’t large enough to display the whole message, so it has to scroll – and it scrolls quite slowly. So when you are trying to find a seat you have to stand and wait to read the slowly scrolling message before you know if it is available. However, this just isn’t possible when there are a lot of people pushing to get on to the train. This situation could be improved:

The unreserved seat problem scrolling problem is trivial so solve. We simply change the message to say what the seat is rather than what it isn’t: “This seat is not reserved” becomes “Available”. Or, if you want to really spell it out “Seat Available”. This is much better – you don’t need to perform the logical deduction of ‘the seat is not reserved therefore it is available’, or as Jakob Nielsen puts it “Usability increases when users need fewer mental transformations to convert a sentence into actionable understanding”. Also, as it is much shorter the display doesn’t need to scroll and you can tell at a glance that it is available.

There isn’t much we can do with the wording on the Reserved seats, but we could make life a little better. As far as I can tell, the notices are put up at the start of the journey and left until the end. This means when I read the notices I am expected to have knowledge of the route – as an occasional train user I don’t know the order of the stops. Major cities I can guess at but I haven’t a clue about the smaller village stations! Have we gone past them? If I take this seat will someone ask me to move in a few stops time? I have no idea! The train knows where we are on the route (there’s another display above the doors showing the next stop) so why not tap into this status and automatically change the seats to “Available” when the stops they refer to have been passed? Granted, this doesn’t tell us if the duration the seat is reserved for is after the point where we want to get off but it is certainly an improvement!

I guess if you catch the train regularly you can quickly spot the available seats; but you are used to an imperfect system rather than it being well designed!

When writing information displays:

• Say what it is (use positive statements)
• Use an active voice
• Your objective is to communicate fact – make every word count (it really doesn’t come across as terse!)
• Consider the environment they will be seen in and cater for any handicaps this introduces.

The Virgin set top box has a common look and feel throughout the user interface which makes the system feel nice and unified. However, the BBC decided that they should have a completely different appearance for the iPlayer; the layout, the colour scheme, the button placements etc. are all different. This immediately removes the user’s sense of familiarity with the system. Given that the cable box already has the controls necessary for implementing this kind of interface it seems a little unnecessary. Having said that, the BBC will be wanting to establish a strong brand around the iPlayer so it’s at least understandable.

Changing the appearance is one thing, but what is unforgivable is how they have disregarded the interaction conventions that were already established on the platform. The major means of interaction with the box is through the remote control; a directional pad for selecting items plus the 4 coloured buttons for short cuts. Throughout the whole system, whether you are buying a play on demand movie or just using the basic TV guide, the red button on the remote is “Page Down” and the green button is “Page Up”. The BBC decided to ignore this and have red for “Home”, blue for “Page Up and the yellow button for “Page Down”!

By doing this they have introduced what are known as ‘Interference Effects’; in this case an example of ‘Proactive Interference’. This is where existing memories interfere with learning. The user is so accustomed to red being page down that they instinctively press it and are then surprised when it takes them back to the home page. On one level this makes the user feel stupid – “I know it goes back to the home page, it says so on the screen!” and you should never make your users feel this way by doing unexpected things. They aren’t stupid, they are just assuming the system will be consistent.

The BBC really should have followed the conventions set out elsewhere in the system in this case; it just makes their application unnecessarily frustrating – would it have been so bad to make the yellow button go to the home page?!

Conventions are a powerful aid to improving the learnability of a system, so whenever possible they should be used. That isn’t to say you can never ignore them; sometimes there is a compelling reason to. Just be aware that you are probably going to trip people up so your reasons need to be good!

“How do I know to do that?”

It’s a good question, and it follows on quite neatly from my last post. It’s quite possible that someone could never find that feature. I knew about it because I -

• Watched the keynote when the iPhone was announced (no it’s not sad!)
• Have read about it in the news
• Have seen the adverts
• Have spent hours drooling over it on the Apple web site before deciding I needed one!

Most people will not have done any of those – so how are they supposed to know? Once you have discovered it, it’s the most natural way of doing this; but nowhere on the device itself does it tell you that this can be done! Nor is it a particularly intuitive feature – in the web browser it makes sense to rotate the device to get a better view of the information, but it’s not as instinctive to rotate a list of artist or song names.

Discovery vs. Direction

When designing new products we should strive to make things as usable as possible. However, this becomes harder as products become increasingly complex with more and more features. The iPhone has this doubly bad because it’s a new paradigm for interaction – you can’t assume that users will have any knowledge of how things are supposed to work through using similar devices. They need to be told about it somehow.

Apple do a great series of video tutorials, but the old computer in the corner with the videos on just isn’t as exciting as the new shiny toy in their hands! Other products come with a thick multi-language manual. If the videos on the computer in the corner are ignored the manual doesn’t stand a chance!

People are curious and like to experiment, they won’t put down their new toy to go read a manual. There is a certain joy in discovering new features which should never be removed, so we must hold a new user’s hand and encourage their experimentation. We need to just make sure we are there to help them when they get lost.

Now, I imagine that it is a rare case that someone would invest in an iPhone without being aware of its features (there are cheaper phones and contracts out there!) but making assumptions of knowledge on a brand new idea is never good. I would have added the following:

• When you turn on the iPhone for the 1st time, it should play a very short video introducing the key modes of interaction; pinch, touch, device rotation etc. and then encourage the user to try them out with each of the applications. It just sets the scene.
• Have the video tutorials pre-installed on the device within the iPod (so they can be easily removed using iTunes to reclaim the disk space). These could be referenced in the 1st boot video.
• Include help pages! I’m not sure if Apple see it as a failure if people need help with their products, but there really should be a consistent and obvious way to show help on a per application basis. It doesn’t even need to be detailed – just explain the basics and give pointers for more detailed information!

Having said that, there’s no doubting, of all the phones I have ever owned, the iPhone is certainly the one with the least need for instructions! But that isn’t a reason to not help out when someone gets lost!

NB. This post is my entry to the killer titles contest fun over at ProBlogger!

Picture of iPod Classic

Edit:Many people seem to be ending up on this page when searching for a solution to their iPod pausing randomly. I’ve put some of the common solutions to this problem in the comments below. Hope this helps!

I love my iPod. I’ve owned 3 different ones (5 if you count my 1st and 2nd generation iPhones!). There’s a great feature that you may have not even noticed exists – when listening to a song if you accidentally pull your headphones out, the iPod recognises this and automatically pauses the track!

There isn’t much point continuing playing when you can’t hear anything so it makes sense to pause. This is especially good if you are listening to an audio book as it saves all the messing around rewinding to try and find out where you were up to.

This feature is using a design principle called Forgiveness. Forgiving designs do what they can to prevent mistakes but when they occur they minimise the consequences. Here, the consequences of interrupted playback are minimised by pausing the track until you are ready to resume.

A way you can incorporate forgiveness in to your designs is to think of your product as a finite state machine and then consider what you can do automatically when the state is changed. Here there are two relevant states: “with headphones plugged in” and “without headphones plugged in”. Changing between the two states has been gracefully handled and the most logical action taken.

It’s an unfortunate truth that these kinds of features are often overlooked, but when you do notice them you realise that the team that put the product together has put in a lot of effort. So, try and take the time to think about the different states your product can exist in and then think about how you can make your users lives easier by automating things during the transition between the states.

There are many things they could do to improve, but the one I want to look at today is the 2nd step – entering my PIN number.

Some bank’s cash machines are bad at this. I walk over; insert my card and enter my PIN. The machine stares at me blankly; almost sinister. I stare back. The machine is daring me… it’s thinking ‘just one more number and I’ll eat your card’. I look around nervously… then spot some tiny text hidden away on the dimly lit screen to: “Enter your PIN then press Enter”. I hate those machines.

Why do you make me press enter?!

Everyone’s PIN is EXACTLY 4 digits long. Passwords on a computer or a website can be any length so you need a way of saying you’ve finished typing, but here they are always 4, this is common knowledge – the step isn’t necessary.

So, why do they make you press enter? It’s a confirmation step so you have chance to go back if you made a mistake whist entering your number. But that’s not really an excuse to add friction to the process – the confirmation is only of any value to the last number you enter! It doesn’t make a difference to the first 3 numbers – you can go back and correct these before the confirmation even comes in to play!

Pick a number between 0 and 9

In practice, this step only saves you if you type in the last number incorrectly. Cash machine keys are pretty large so I’d imagine the chance of mistyping is pretty slim in the first place! Even then, the consequences of getting it wrong are minimal – you get 3 attempts – so even if the first attempt is wrong you get another 2 shots. Human nature is such that if you get it wrong the first time you’ll pay more attention the second.

If mistyping is a frequent problem, I’d still remove the step (the 4 asterisks on the display don’t exactly help here!). I’d accept the 4th key as confirmation, but then insert a pause whilst displaying a way to cancel the confirmation before the validation actually takes place. The user would perceive this time as part of the validation process. You could even display an advert for another service whilst you have their attention.

Wherever possible you should try and reduce the number of steps and interactions you make your users go through to achieve their aim. Ask them to participate only for the essentials. If you can reliably guess what they will do, don’t make them do it!