Usability Bites

The Numbers Game- How we oversell the wrong properties and usability suffers

2008-11-01T10:19:00.004Z

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.

When Good Text Goes Bad

2008-09-24T20:45:00.008+01:00

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.

Stalemate - Providing Helpful Help

2008-08-06T04:42:00.003+01:00

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 …

Wrong Number

2008-06-28T20:49:00.003+01:00

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

How many jobs can one button have

2008-04-05T20:02:00.001+01:00

Sometimes it makes a lot of sense for a button to do more than one thing. An on/off button turns a device on if it is off, and turns it off if it is on. Obviously there is no need to have both possibilities available at the same time. The on/off button is a toggle button. A ‘select screen’ button could allow the user to iterate through each available screen, so each press of the button brings the user to a different screen on a GUI. When the last screen is reached, pressing the button again brings you back to the first screen.

An idempotent operation is one which has the property that if the operation is repeated then the result is the same. Pressing the number 1 button on my car radio is idempotent. Pressing it once brings me to channel 1. Pressing it again will bring me to channel 1 again, which changes nothing ( we will ignore the fact that some radios might change to channel 11). So idempotence is almost the opposite property to that of a multifunction button.

So when do multifunction buttons get us into trouble. Let’s look at a few specific examples. Many slide projectors have bulbs that take several seconds to warm up. If you turn the projector on, and then look at the screen, you may wonder if the device has turned on - maybe you did not press the on/off key hard enough. A natural reaction is to press the button again. If the on/off key is a toggle (i.e. a multifunction button), you have now turned off the projector, and will possibly start to think that the device is not working.

If this projector had a separate on and off key, then the on key would be idempotent and pressing it a second time would have no effect.

The stereo in my bedroom has a ‘function’ key which changes mode from FM tuner to CD player to tape deck and to Auxiliary input. Each time the button is pressed the small dark LCD displays the name of the current function. Unless you remember the order of the functions, you will not know what function you are about to get when you press this button. That is not a big deal, since you can press the button until you arrive at the function that you want. If the user presses the button once too often, and they go past the desired function then they have to go all the way around again. This is annoying, but is not the crux of the problem that we want to address here.

Consider the case where you can not see the LCD – it might be at a bad viewing angle from your armchair, or you may be listening to music in the dark. Now there is no reliable way of selecting the function. You could press the button and then listen, and hearing a talk-show host would obviously mean that you were at the FM tuner function, but that is not very satisfactory. Had the designers placed one button per function on the remote control then each of those buttons would have been idempotent and the user would have had a quicker, more reliable interface.

My cordless phone has a toggle button which allows it to go on-hook or off-hook. Such a simple toggle should cause little confusion, but it does. When I pick the phone up I often think “well I have picked the phone up, so I just have to talk, since that is how I answer a corded phone”. On this phone the call has not been answered by lifting it from its cradle – the on-hook/off-hook state is controlled only from the toggle button. Since this differs from the majority of old-fashioned corded phones, I pause to remember that I have to press the button. During that pause I think to myself “if the phone is off-hook now, then pressing the button will hang up, and I lose the call, and probably cause marital strife”. So I wait for the phone to give another ring before I am sure that it is on-hook before pressing the button. A good interface should not leave me so hesitant to press a button. Two separate idempotent on-hook and off-hook buttons would resolve this – many phone code these keys as red and green. With a dedicated off-hook button, I could press it, and if I was already off hook then no harm would occur.

Multi-function and toggle buttons do save space, but be aware of the drawbacks, and sometimes the right call is to use several buttons instead.

Kiss: Keep It Simple Stupid

2008-03-01T20:30:00.002Z

In one of my articles, available at http://www.embedded.com/story/OEG20011220S0060 I discussed how engineers like to present lots of data on the user interface, so that they user can derive further information for themselves. This is a slant that people of less technical professions might not appreciate. Typical users do not want to be blinded by lots of data, no matter how well presented. They want the data to be pared down to the minimum amount that they need to make their next decision

Always presenting lots of details does not suit all users and I came across an example of this recently. The system being analyzed was an ambulance tracking system that stored the locations of a number of ambulances which transmitted their positions to a central server. Third party mapping applications make it straightforward to display the position of all of the vehicles on a map which is displayed via a browser. This is obviously a far better way of presenting location information than simply providing longitude and latitude. Of course this looks fairly cool too. But a little further investigation showed that the better solution for many users was far simpler. At the hospital, they are only concerned with when the next patient is arriving, so they can ensure the people and resources are ready to treat him or her. So the only bit of information they want is the number of minutes before arrival. Again third party mapping applications can provide this data based on the current position. The challenge of the user interface, from the developers and from the users point of view has been greatly reduced, since now they have a simple number of minutes to display instead of integrating a mapping system into the application. The lesson here is always listen to the customer's needs carefully to ensure that you chase the simplest solution, rather than getting lured into making things that look flashy but may make it harder to interpret the really useful information, which in this case was time to arrival.

Very often you end up implementing the flashy stuff as well, because that is needed for the sales demo that gets you in the door. But that is very different from what is useful to the end user.

Making fun of Usability Specialists

2008-02-24T12:38:00.002Z

I recently encountered http://www.usabilitymustdie.com/ which is a site that satires some of the feedback that might come from dilbert-esque usability specialists. While most of it is over-the-top and can not be taken too seriously, it is a good thing that there is someone who who will call into question the value of, sometimes expensive, usability reviews by outside consultants. And the site is also a good laugh too.

While I was reading it, it set me to thinking about the real value of advice given by outside reviewers. One thing that occurred to me is that specific improvements to a single design are often of little value, especially if, as the design matures, that specific piece of the design vanishes. It is of far more value to teach the client how to recognize problems for themselves. If you can teach the reason for a specific improvement then the client can do many similar improvements for themselves. Looking at it from the other side, if you are the client, and improvements have been suggested, you should always ask 'Why?', if the consultant has not already provided the reason. Getting at the motivation for the change which will allow you to learn more.

Ironically teaching clients how to do usability for themselves could be doing yourself out of a job, but, hey, if you are adding real value then there should be no problem finding more clients.

Integrating the GUI and Off-screen Controls: Camera Example

2008-01-06T10:00:00.001Z

Quite often the GUI on an embedded device is driven by the software team while the off screen controls are designed by the mechanical or electronic designers. Sometimes this leads to a system were these two parts of the same device are not well integrated. I have seen cases were icons or names used on the GUI are not consistent with those used on the housing.

On the other hand some devices do a beautiful job of marrying the two types of input. On my Sony camera, there is a dial which allows the user to choose the mode. The dial contains small icons. When you turn the dial you get to see the full name and a description of the new mode. This vanishes after a few seconds, so the extra information does not clutter the image of the picture to be taken.

By also showing a rounded outline around the icons being selected, the on-screen image looks like an extension of the physical dial. In other words, rotating the off-screen dial also rotates a disk that is displayed on the GUI. While this is tricky to describe the brief video below makes the idea clear.

While many other cameras only repeat the icon on the GUI, Sony make this feature far better in two ways. One is that the extra text means that the user can learn the meaning of the icons without resorting to the user manual. The second aspect is the smooth integration of the on-screen and off-screen controls makes this device feel like a single user interface, rather than two distinct interfaces to two different parts of the device.

Tradeoff: Easy on the Eye or Easy to Use

2008-01-01T22:32:00.000Z

Traveling with work I spend plenty of time in hotels. I noticed that the more expensive the hotel, the more expensive the bathroom fittings. However the more elegant and eye-pleasing the taps and faucets, the harder it is to see which is the hot tap and which is the cold. Some designers focus on form and not function. That sometimes hides the information the user needs. Large red and blue plastic moldings take away from the ascetics of the design, but they do tell the person which tap is hot and which is cold.
The same principle applies to many embedded systems - there is a trade-off between pretty and easy-to-understand. That is why kids toys have big buttons in primary colors. Easy to see and manipulate but not so pretty to look at. Think about that the next time the mechanical designer on the team is trying to make the buttons small an discrete to avoid interfering with the smooth outline of your next product.

Lying to the User: An Ounce of Inaccuracy is Worth a Pound of Explanation

2007-12-24T10:00:00.001Z

Truth and honesty are much overrated. If user interface designers decide that users should always be given all relevant information that is available then we will probably flood them with data that they can not decipher.

Engineers like precision. They go to great lengths to select the most accurate sensors and then design calibration systems to iron out any inaccuracy introduced by manufacturing variability. They sometimes expect the user to appreciate that precision too.

I have seen many cases where a system at rest displays a measurement of 0.01, which leaves the user baffled when a reading of 0.0 would have made perfect sense. Users do not want a precise reading. They want to be reassured that the device is working normally. Sometimes a gentle lie is the easiest way to give that reassurance. The interface could display any reading below 0.05 as 0.00. An alternative would be to reduce the resolution to one decimal place, but there may be reasons for showing both decimal places at larger values.

Constantly changing signals can also be difficult to interpret. One of our designs had a lightbar made of LEDs that showed the pressure being controlled in a pneumatic system.

Because we had more LEDs than the product’s predecessor, the bar could show a variation of 0.5cmH2O, while previous systems only had a resolution of 1.0cmH2O. We received complaints that our system was not as good at controlling pressure than the older alternatives. We investigated and found that while our pressure control was just as good as the older devices, small variations in pressure were reflected in the bar. These variations are not visible with a lower resolution bar. So the older system was not more stable, but it looked more stable because small variations were not visible on the lightbar.

It was too late in the design to reduce the resolution of the bar. Instead we filtered the pressure signal to make it look more stable than it actually was. By hiding some of the true picture from the user, we made them more comfortable with the system, and this avoided having to spend time during training explaining to the customer the principles of our control system in order to explain the small variations in pressure. If the target users had been engineers then providing that accuracy on the ledbar, and providing an accurate explanation might have been appreciated by the users, but with less technical users, an ounce of inaccuracy is often worth a pound of explanation.

One of my client’s designed software for specialized mobile phones. They have a small market and designing the complete phone is not feasible. They buy in sub-assemblies but run their own software these phones. One of their customers complained that a competitor got a far better signal, for a specific distance from the cell tower. This surprised my client since they were using exactly the same electronic components, bought from the same suppliers. It turned out that the customer’s measurement of signal strength was based on the number of bars appearing on the LCD. My client's software reflected the signal strength by lighting up the bars on the LCD in proportion to signal strength. The competitor was lighting up more bars for the same signal. My client resolved the matter by using an algorithm that did not light up the bars in proportion to the signal, but weighted it to always light more than its fair share of bars. The engineer would have assumed that the amount of the bar that was illuminated should be proportional the signal available, but the customer was happier to be given an indication that was as optimistic as the competitor’s indicator. In this case it could be claimed that both competitors ended up lying to the user in equal amounts.

Welcome to Usability Bites

2007-12-24T09:25:00.000Z

Welcome to the Usability Bites blog. I will be posting occasional thoughts on the topic of user interfaces for embedded systems. If you want more meaty coverage there is full list of the articles I have written at http://www.panelsoft.com/murphyslaw. Most of these articles appeared in Embedded Systems Design, where I used to write the Murphy's Law column.

In this blog, the postings will be more brief and casual, but hopefully thought provoking.