Engineers are always trying to improve the numbers that define our products, whether it be the number of pixels for a camera, or the pages-per-minute for a printer, or the resolution of an oscilloscope.

Marketing will always seek to trump the competition by having a number that outstrips their rival, regardless of whether that number has any meaning to the end user. Customer surveys constantly find that ‘ease-of-use’ is much more important than quantative measurements like picture resolution or sound quality, but it is far more difficult for a marketing campaign to state and prove that the user experience with one product is superior to another – it is a more subtle message and require more marketing nuance. It is often a reputation that has to be earned over time.

Be careful that seeking better numbers lets you lose sight of what the user really cares about, which is a better overall user experience. When the world transitioned from records and tapes to CDs, the marketing people were telling us all about the improved quality of sound from digital media. To be honest, I think few customers cared. CDs allowed instant access to a specific song. They are smaller and easier to store than either of the other media, and less easily damaged. So ease of use was more important than sound quality. My proof for this thesis comes when you look at the next transition. People were more than happy to allow the sound quality to be reduced when transitioning to MP3s because that allowed for miniature MP3 players, no media to cart around, and easy access to extra information such as song title, artist etc. Users will follow a better user experience, and quality will not be an issue except for a few audiophiles, who only make up a tiny percentage of the market.

So what does this tell us about the future of other products? Blu-ray disks are having trouble gaining traction in the market, even after seeing off the rival HD format. Why? Well the user experience is the same as a DVD. We have not given the customer a compelling reason to upgrade their hardware. We have not made anything easier or better for the user, so they are not going to bite just for the sake of a few extra pixels. Blu-ray will limp along while the real user experience enhancement will come from video-on-demand and downloadable rental movies. Not driving to the video rental shop is a real user-win, and that will trump high definition every time. Most users will choose a faster download and less wait time.

Another example of dodging the numbers game is the Wii success storey. The designers did not follow the path of the Xbox 360 and PS3 which easily trump the Wii based on the screen resolution and graphics processing power, but the Wii won out on sales because they revolutionised the user’s means of controlling the game.

Camera manufactures blindly followed the herd as they increase the picture resolution. My camera takes 7 megapixel pictures, but I always keep it set at 5 megapixels so the pictures are smaller – I keep more pictures on the camera, and use less disk space to store them on my PC. Increasing the picture quality was actually damaging my user experience because the camera was full more often, and other operations such as e-mailing the pictures was more difficult.

Bear this in mind the next time you want to revamp your product to get more of what you already have. Do you want your 60 page-per-minute printer to do 70 pages-per-minute, or should you investigate why it sometimes takes the user ten minutes to resolve a paper jam (maybe they could be given better indication of exactly where the problem is when it happens). Saving the user time this way more than compensates for printing a little slower than the competition. But it is hard fro marketing to sell that message. They fall into the Gillette trap – think of a bunch of marketing guys sitting around saying that they have a razor with 3 blades, “What will we do next?”. It takes less imagination to simply give the customer more of what they already have – a fourth blade. But many customers will go ‘So what!’.

Apple regularly outsell higher spec products because their customers know that the experience with an Apple product will be better, and that is why they will buy an iPod that might have less memory than another player at the same price point.

So try to think outside the box of numbers, and come up with products that change the game.

Using text wisely in a graphical user interface can make the difference between an interface that flows well, and one that resembles a game show riddle. The first rule to remember is that the more text you put on the display, the less the user will read. Always assume your user is busy. If you put a paragraph of text in front of them, they will likely decide that they do not have time and continue using the interface without reading it. They usually figure that they can come back and read it later if their actions do not work out.

Short blunt messages like “Check Tyre Pressure” will work far better than “Tyre pressure is approaching the low threshold, and confirming pressure in all four tyres against recommended levels is recommended”.

The first message does appear to be ruder and it is not good to be rude to the user, but in this case it is the lesser of two evils.

Text as a Band-Aid
The second rule is that text should not be used as a BandAid. In some cases a design leads users to make a specific mistake. When this is seen in trials, the navigation of the interface should be fixed to make the mistake less likely. The less pleasant alternative is to add a text message that says “Warning: do not press red button while attached to patient”.

In my home town they built a roundabout with 5 entrances and exits. Each had multiple lanes. It did not work very well and led to traffic chaos. Instead of simplifying the junction, the planners added more complexity by installing traffic lights at some (but not all) of the entrances, and two sets of traffic lights halting traffic that was already in the roundabout.

Because drivers were not used to lights in a roundabout, many, many cars simply sailed through the lights oblivious to the fact that they were running a red – there were also so many sets of lights visible that you could sometimes see multiple red and multiple green lights and it was hard to be certain which ones applied to your lane.

The next step should again have been to consider simplifying the junction to something that drivers could use effectively. That of course was an expensive option. Instead the Band-Aid was to put up a sign telling the drivers what they should have already known: “Stop when Red”. This sign fails, partly because drivers (and users) read almost nothing and secondly any driver that has already been confused to the point where they ignore a red light, will likely ignore this sign also.

The lesson here is that if your interface is so difficult to use that you have to add text telling the user things that they already know then the interface is causing counter-intuitive behaviour, and the interface should be fixed rather than expecting the user to read instructions.

There are lots more rules for effective text use in my article “Wordsmith” available at http://www.panelsoft.com/articles.htm.

I am sitting on a plane, and decided to have a game of chess with the on-board entertainment system. The player is required to first select the piece to move, and then the set of possible destinations for that piece are highlighted. The player then selects one of the destinations. At some point I selected a piece by accident. I now wanted to cancel that selection and move another piece. After some fumbling I did discover that it is possible to unselect the selected piece. It is performed by selecting the current location of the selected piece. This is not particularly intuitive, but it is easy to do once you know how.

During this fumbling period I decided to consult the games built-in help facility. I was disappointed. The help feature contained a lot of information on the rules of chess and even some interesting suggestions on tactics. However it failed to tell me how to use this particular implementation of the game. Most people who choose to play a game of chess against a computer probably already know what the legal moves are. Had I wanted to learn openings from the grand masters, I would have bought a book in the airport. However, no amount of chess expertise will tell me how to unselect the selected piece. When authoring the help they should have focused on the application specific knowledge first. The domain knowledge should be considered an optional extra. There are many places where the player can get information on how to play chess, but the built-in help is the only place that can tell the player which buttons do what in this game.

I have also seen this problem on a lung ventilator. The machine used an on-screen icon that I could not decipher. When I consulted the help, which was quite lengthy, I found medical definitions of the breathing patterns that the machine used. This is information carried in many medical text books. The meaning of the mysterious icon was not defined, and again, that is not something I could have learned on another machine, or investigated with a web search.
So when you are building help, focus on the things that will be new to your user, especially if your device or application does it differently to applications already familiar to the user population.

The second thing to bear in mind when authoring help documentation is that the more text you put on the screen, the less likely it is that someone will read it. Try to be brief, and focus on the areas where the user is actually likely to need help. Some help systems try to be complete, and in the process include paragraphs describing every button and option in the system. If a large percentage of these are easy to use, then there is a danger that the really useful help is lost in a sea of text about things that are already obvious to the user.

Now back to that Zukertort opening …

So some guy answered and I realized I had dialed the wrong number. I apologized and hung up. Unfortunately I was left with a dilemma. Was the number on the piece of paper in my hand the incorrect number, or had I accidentally mis-dialed one of the digits. The call was over and I had no way of knowing what number I had actually dialed, so I could not check the piece of paper against the number I dialed. If I dialed the number on the paper again then I might end up talking to the same guy, which would be embarrassing, and it is a bit rude to disturb the same stranger twice.

If I had been using a phone with a call-log, the screen might show me the last dialed number and I could check, but most simple land-line phones lack such a feature.

Bear this dilemma in mind when designing screens that tell the user that they have done something wrong. If you are telling someone ‘Invalid ZIP code’ or ‘Too many digits in account number’, make sure that the data that your interface is complaining about is still visible. Too often, especially on the small UI available to many embedded systems, the error message hides the data that the user just input, leaving the user wondering what exactly they did enter. The user may know what they intended to enter, but after the fact, they may be unsure. This often leads to the user entering exactly the same data a second time, because they assumed that they made some kind of a slip the first time.

Once you reach the point where you tell the user that they input the wrong data, it is often nicer to have the option of correcting the previously entered data rather than starting over. If I got the ZIP code wrong, I may just want to fix one digit, rather than starting all over. For a string as short as a ZIP code, starting over is a minor inconvenience. As the data they enter gets larger the price of restarting the data entry gets higher. So try to find a way to save the user’s work so they can reuse the majority of it.

Handing user errors is a challenging area. Read more about it in an old article of mine in Embedded Systems Programming magazine called To Err is Human