Good software engineers don't always make good interface designers. Sometimes they trust the user too much.
This month, I will investigate some of the reasons why software engineers do not always make good interface designers. It is not that they cannot design good interfaces, but that they sometimes fall into some common traps. They fall because an engineering background can lead a designer to prefer certain properties in an interface that may not be as desirable to the population at large.
Before I endeavor to help return the interface to the user, I'd like to address some of the feedback from the usability column I wrote in October 2001(“So This Button Must…“).
Many readers related tales of frustration with their automobiles (and their ex-automobiles!). Ford was mentioned more than once. While the critisicms were valid, I have to say a short piece in defence of Ford. A few years ago, Ford noticed that the number of drivers over retirement age was increasing. They started to make some of their controls larger and simpler. If we are going to have some of the less-nimble-fingered generation driving around, then I, for one, am in favor of putting them in automobiles where they are less likely to confuse the air-conditioning and the hand brake.
If you look at the radio in some of the modern Fords, you will see a small number of simple buttons. The radio lacks some of the sophisticated features that are common in modern car stereos. The features that remain, however, are far easier to use. Simplicity one; featuritis nil.
Ford still has room for improvement. They chose a horizontally aligned button to control their cars' electric windows (in one model at least). The button has two arrows, one pointing forwards and one back. One means Up and one means Down. My method of opening this window is to press one arrow and if nothing happens, then try the other. Maybe the designers thought that the slight slope on the button was enough to consider one of the arrows to be pointing down, but I am afraid they were depending on a subtlety that was lost on me, and, I fear, on most users.
This is another example where using English text would have been simple and unambiguous. The words Up and Down would easily fit on the buttons.
A second recurring comment in the reader feedback was in response to my frustration at not being able to cut and paste text from error dialogs in Windows into an e-mail or text file. A number of readers pointed out that I could do a screen capture and mail the bitmap image generated. While this does solve the problem of getting the message to another user, it does not vindicate the design flaw. A system that allows text output and text input should allow any piece of output to be used as input. Capturing the text as a bitmap fundamentally changes the form of the information, and makes it far less useful. I cannot plug it into a bug database, or do a text search on it.
GUI design is not API design
I have worked on a number of projects where it has been possible to graph sensor data. As well as graphing a parameter against time, it is sometimes useful to combine two parameters on one graph, or graph one parameter against another without a timeline, such as a pressure vs. temperature graph.
The engineering-driven design would suggest that I have two types of graph: time graphs and non-time graphs. If the user picks a time graph, he should be presented with a list of all possible parameters and be allowed to select which parameters appear on a plot against time. The second type of graph is a non-time graph where the user picks any two parameters to be graphed against each other.
This approach seems like an ordered orthogonal solution that covers all possibilities. This is its great failure; the user does not want to cover all possibilities. The user wants a few canned solutions. In a particular application domain, a given number of graphs are useful to the user; those graphs are the ones that should be available.
In one case, the graphs were generated by a lung ventilator. Respiratory therapists learn how to read a certain set of graphs from textbooks. Allowing combinations that they have never seen before is confusing and troublesome. The engineer thought that the greatest flexibility would allow the user to experiment, but most users do not want to experiment. They prefer a more restrictive environment that keeps them in familiar territory. The user should be offered a simple set of canned graphs, not a configuration screen worthy of the space shuttle.
So what has this got to do with application programmer interface (API) design? In this context, I use the term API in its most general sense. I mean a set of related functions used to call a library or a sub-system within your program. While an API should be general and expansive and encourage imaginative use, a user interface should be restrictive. Give the users what they need. Do not give them the possibility to do all things, and hope that they will pick out the options they require.
The engineer may be seduced by how easy it is to provide the user with the most general solution, just as he would when providing an API, but users do not want to be presented with the tools to do the job, the user wants to be presented with a list of solutions.
The engineer will design for the optimum compatability between operations, and the maximum flexibility. The way in which commands in the Unix shell can be combined with pipes and redirection is a perfect example of the engineer's design perspective. It is a powerful interface, but it is not user friendly, and, therefore, not a model that we should follow for the end user of our embedded devices.
A similar lesson applies to graphing trend data over long periods. Do users want the graph over days, weeks, or months? Maybe we could do it weekly and let the user decide on what day the week begins. Maybe they want a trend where the unit of time is a set number of days. If we have the raw data, all possibilities are easily generated, and the engineers will want to offer those options.
Again, the user will thank you for a few canned reports. If the user can choose exact start and end dates, he may view three months of data on one occasion and three and a half months on another occasion. The graphs are not readily comparable since the scales will be slightly different. By making the trend graphs too configurable, it becomes more difficult to compare like with like. Try to restrict the user to a small set of time periods; even if they do not always match the exact period of interest, at least the user will have the opportunity to get used to observing data at a specific scale.
Users who truly want to experiment should be able to download the raw data into a spreadsheet application and do further analysis there. Your embedded system is not a data mining tool.
AND and/or OR
Just to illustrate how far engineers have drifted from the rest of the general population, let's examine one area where the meaning we attach to some simple words is completely different from the norm. Assume I want to allow a user to select events from a historical log. Perhaps I want to select all of the alarms and user changes. If I can restrict the events I select to alarms or user adjustments, I will be presented with the list I desire. It is a logical OR operation on the set of events with the desired properties.
This is not the way a normal person would describe it. They would say that they want to see all of the alarms AND all of the user adjustments. This may not be semantically precise, but it is the way many non-engineers talk and sometimes think. Do not assume that the boolean logic in your interface will be understood by the end user.
Too many configuration options
On too many occasions, I've heard engineers say, “If we give the user all the options, then they can choose the one they prefer themselves,” or when it's debated whether method A or B is better, one engineer suggests that both are implemented and the user can use either route, or maybe select a configuration option to choose their preferred default. When you hear this in your office, the alarm bells should start ringing.
By letting the user choose, the designer is abdicating his responsibility to design an acceptable system. All design decisions should be made before the product is launched, not after the customer has received it, and spent hours poring over all of the configuration options, and battling with the same dilemmas that the designers faced.
Users do not want to design their own products. When they do, they tend to make some awful decisions. They have enough to learn about a new product without being asked to learn two different modes of use, just so they can decide which they prefer.
Even if the user makes the effort to fully understand all ways of using the device, he may not choose the method most suitable for him. In experiments, users have indicated which path through an interface they considered to be the quickest, when the stopwatch gave a different answer. I imagine the user will be similarly off the mark in many other usability metrics.
Embedded products are not always tied to a single person; a desktop computer can be personalized to a particular user via log-in. An embedded device may be used by a range of people and you may not want to have one of those users force their preferences on to the others.
Again, a function call to a programming library is an apt comparison. It is reasonable to offer all options and let the user of the programming library decide which to use, but that is because the programmer wants a powerful interface and is likely to be prepared to invest the effort in learning all of the features of the library. Engineers see learning as a valuable activity which will pay off in the long term. Users are more likely to see learning as drudgery.
I use the term surface area to describe the amount of contact between the user and the device. A device with a very small number of buttons, each of which has exactly one function, has a small surface area. A more complex device requires more surface area to allow all features to be accessed.
Say I am designing a set of function calls as an API. Now, think of the number of functions and the number of parameters as the library's surface area. When I see a library with a large surface area, it reassures me that this library has enough flexibility to accomodate all of the tasks I may require.
For a user interface, however, a large surface area may be off-putting. When I was a teenager the successful video games were Scrambler and Defender. These games had so many button controls that you needed independent control of several fingers. It was like learning to play the guitar. Pac-man appeared and it out sold all of the other games at the time. I believe that one of its major appeals was that it only required a joystick for control. The input was very limited, so the physical and mental dexterity required to have an enjoyable game was minimal. This simplicity went against the trends of the time, but won over many people who were intimidated by games that were more difficult to master.
Physical dexterity is only part of the problem when a device has greater surface area (more buttons). The mental process of choosing the next action from a large set is also involved.
The lesson here is that if you are in a business where featuritis is leading to devices with larger surface area, it's likely that a market opportunity exists for a competing product with a minimal interface.
Engineers like precision. They go to great lengths to select the most accurate sensors and then design calibration systems to iron out any excess inaccuracy. They sometimes expect the user to appreciate that precision too. It doesn't happen.
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 0.5%. They want to be reassured that the device is working normally.
One of my clients designs 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. One of their customers complained that a competitor got a far better signal, at the same 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 user'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.
Sometimes, lying to the user is doing them a favor. In many cases an ounce of inaccuracy is worth a pound of explanation.
Engage the user
Being trained as an engineer can lead to great powers of analysis. But sometimes the most logical analysis is defied by users. Get yourselves away from the keyboards for a while and listen to real users-you may be surprised by what you hear.
Niall Murphy has been writing software for user interfaces and medical systems for ten years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy's training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at . Reader feedback to this column can be found at .