Reading
|
PanelSoft User Interfaces and Usability for Embedded Systems |
Feedback to "Interfacing the User"- Murphy's Law, January 2002Read the original artilce at Interfacing the User Rob Withoff (Infrared Solutions) makes a number of interesting points: I must take umbrage with your column on UI design, "Interfacing the User". While you bring up some very valid points, you focus on the concept that users would rather prefer a few canned options than the ability to run the gamut of all available options, and you specifically detail the ability for the user to configure their own options as the designer "abdicating their responsibility" in good UI design. By taking this tack, you make the assumption that the end users are a bunch of morons, or that the design should reflect the lowest common denominator so that the maximum amount of people can get the most use out of your design. This is exactly the same kind of thinking that dominated network television sitcoms for decades, and brought us the pablum that we watched (or refused to watch) in our formative years. The truth is that UI design should flow from the functionality of the device being designed *before* the back-end design takes place. Too often the user interface is an afterthought, constrained by the physical or cost requirements of the design (we need to have text entry capability, but we can only afford two buttons and an LCD). There are some general rules for good UI design that work well in both physical and graphical UIs: 1.) One control, one function. The most user-friendly designs follow the one-function-per-control rule. This is also the most expensive and impractial for most embedded designs, so this is modified into a guideline: minimize the overloading of controls. Can you imagine trying to dial a cell phone if you had to enter numbers through a menu (press SELECT, scroll through options to NUMBER, select 0-9 from the list)? The corollary to this is "fewer buttons don't mean a simpler interface". 2.) If you must overload controls (i.e. menus), generate the heirarchy from user functionality rather than the software architecture. 3.) If your menu heirarchy goes more than 3 levels deep, you need to look seriously at redesigning your menus. 4.) Often used controls should be easily accessible, and preferably limited to a single function. Don't make the user hunt for the GO button. 5.) Controls should be consistent. If buttons are used in different modes, their operation should be similar (i.e. up/down buttons shouldn't change to down/up when you enter a different mode). 6.) Follow conventions. If your device has a numeric keypad, make it look like a telephone keypad. A different layout will confuse the user and cause them to make errors. Don't be afraid to *add* a useful function: one of the best designs I ever saw for a digital clock had a 'back' button, so if you overshot your time when setting the clock, you didn't have to cycle through 24 hours to get it. 7.) Feedback is important. A click when a key is pressed or highlighing a menu selection makes all the difference in user confidence. The more *useful* information that the user has, the more comfortable they will be using the device (useless information would be something like having a voice say "a key has been pressed" every time a key is pressed). If your design will be handheld/portable, add tactile features (bumps on buttons, clicks on rotary controls, etc.) to make it easier to operate without having to look at the unit. Consider that someone will be operating your device while driving. 8.) Just because your device *can* have a feature doesn't mean it *should* have that feature. Providing canned options for your device is a sound principle, but not at the expense of versatility. Recognize that some of the users of your device will be power users, and will want/need to fiddle with your available options. Give them a method to do this, or your competitors will. I have to agree with you, though-- the best way to get a design that your end-users will like is to listen to the end-user and design to their needs. Don Vollrath writes: Read your Interfacing the User article in Jan '02 issue of ESP...Right ON! Too many features = Too much training required to use it = Too many chances of screwing it up. The problem with embedded software is that it IS complicated. Making special software for every possible purpose is not feasible. The reason is as you propose...No one in Marketing is willing (or knows how) to limit the scope or say 'do it this way' with any assurance that that is what the customer wants. And they don't take the time to find out. So we end up with bits and pieces of some-else's version of a function glued into yet-another application, with yet another way to select what you want it to do. The overall operating system, like ms-windows, ends up having countless numbers of possible combinations in an attempt to let everyone please themselves. I can't find the help I need in the 'Help' file to learn how to get some application programs to remember where I keep my data files. The basic needs are lost in the forest of possibilities. Your example of the automobile radio with many feature pushbuttons is perfect. I don't change the station and drive on the freeway at the same time because I can't find the right button by feel. Defining the needs and desires of the end user is important - early in the product design process. Table top discussions and demo I/O scenarios are good tools to work with. So when my wall phone w/ memory says 'Batt' on the display, does it mean that it is using the battery? or that the battery is OK? or that the battery needs to be replaced? The instruction book is about as clear as mud. The correct answer is #2. Keep up the good work, DonV Mr. Murphy; I would like to thank you for your article "Interfacing the User". As a biomedical engineer with several years of working with medical equipment end users, the frustrations of a too complex user interface and the occaisional negative effect on patient care is frustrating, to say the least. Recently, one of our hospitals (US Veterans Hospital system), reported to me that they had a 'close call' with a quadraplegic patient on a ventilator. The nurse had come in to the room flipped the switch just below 'Power' on the panel to turn on the ventilator, and left to check on her next patient. Unfortunately, that button actually switched the device to an external battery, which the vent did not have. Consequently, the patient was unable to breath and required resuscitation. Luckily, he fully recovered, but it was too close. When the hospital's Risk Manager investigated with the head of Respiratory Therapy, the the head of RT made the same mistake! My suggestion is to make medical device controls simple, intuitive and obvious (OK, all controls). Controls that don't influence the most common functions of the device should not be mixed in with those that do. A little thing like moving the internal/external button away from the 'power label' would prevent this type of thing from happening. Well, enough dumping. Again, thanks for your article. Warmest Regards Paul Sherman Biomedical
Engineer Hello Niall, I just read your article "Interfacing the user". It was interesting. While reading it, my reflection was that designers are guessing what the end user wants. It seems as if the designers neither get requirements nor talk to customers. It may also be so that usability requirements are never documented because they are difficult to formulate and often untestable. These problems may also arise from the hierarcic structure of companies. Designers are kept away from customers. It is the project managers that meet. They are more worried about time plans, than anything else. Being a tester, I have seen a lot of embroidery that certainly does not come from requirements. So I guess that those must be blamed on happy designers. Regards, you are right about the designers not meeting the customers. I have written about that exact problem. See http://www.panelsoft.com/articles.htm, "What does the customer really want?". regards, Here, here - another instance of using Microsoft as a bad example would be my own favorite rule, "similar operations in different modules should be performed in similar ways." For example, even though the Office suite is supposed to be an integrated software package, the setup for each one is slightly different. Setting up the default directory is sometimes an easy option to find (Word), sometimes difficult (getting Outlook to change the location of the "Personal Folders" directory, and sometimes impossible (Outlook attachments, Project, Notepad). Clay Olmstead Applications
Engineer |
|
|