4.1 Introduction

4.1.1 Successful Designs

New inventions are emerging all the time, but only a few become good enough to be used by the public. The inventions and the business opportunities related to them are immense, but whether they are seized or not depends on whether products are conceived and designed to deliver on the potential. Anyone who has tried unsuccessfully to program a VCR or understand all the functions of a mobile phone has experienced the problem of technology that was designed without considering the user .

Manufacturers are constantly designing feature-rich products to appeal to the widest market possible. This is fine, of course, but problems arise when they don't stop to consider the end-user during the design process. Consider an alarm clock/radio. Its primary function is to activate the buzzer or radio mechanism at the set time. Simple enough, but as more and more features are added to the device, even the most basic task of setting the alarm turns cumbersome. The instructions might look something like this:

Your clock comes equipped with two alarm times, Alarm1 and Alarm2, each containing five different Wake functions that can be combined within one alarm time or both. You may awaken to the buzzer, the radio, the CD, or the personal message mode for Alarm1 and choose a different mode for Alarm2. Or you may choose the same mode for both Alarm1 and Alarm2. You may also choose to use the Gentle Awake feature, which begins at a designated low volume and gradually increases in volume until the designated maximum volume level is reached, easing you into a wakeful state. Again, you may use the Gentle Awake feature for either Alarm1 or Alarm2, or both. To activate the CD mode for Alarm1, press the Alarm1 button twice, then press the Alarm1 and Mode buttons simultaneously . To set the time for Alarm1,...

You get the idea. Without the manual in hand (and even sometimes with the manual in hand), just setting the alarm is enough to give you a headache . This is a classic example of poor design. If you cannot operate the device without simply looking at it, or at least reviewing a short list of recognizable steps, it is not designed with the user in mind. Instead, it was designed with the functionality in mind.

A successful design, on the other hand, is one that most any user can look at and almost immediately understand. It's intuitive because either the user can associate the interface with something familiar, such as the start/stop/play buttons on a VCR, or because the visual design of the thing clearly dictates its operation.

One striking example is the Segway Human Transporter [1] , named from the word "segue" (or moving seamlessly from one mode to another), which is a vehicle that is electrically powered and produces no emissions.

[1] http://www.segway.com/

The device is a gadget from award-winning inventor Dean Kamen, who also developed the first insulin pump, a briefcase- sized dialysis machine, and a wheelchair that can climb stairs. The Segway scooter , shown in Figure 4.1, builds on "dynamic balancing" technologies Kamen used to create his wheelchair.

Figure 4.1. Segway Human Transporter

graphics/04fig01.jpg

Before its official presentation in December 2001, it was one of the most hyped technologies and was known as Ginger. Segway is a selfbalancing, motorized scooter that costs less than 5 cents a day to operate. The machine could replace private cars in crowded city centers and could also prove useful on factory floors. The two-wheeled device uses a complex array of gyroscopes and computers to mimic the human body's sense of balance. People lean forward to move forward, lean back to reverse course, and turn by twisting the handle. The device looks like an old-fashioned push lawn mower, with the handle sticking up in the air and a platform to stand on where the cutting blades would be. Falling over is impossible , and the scooter can handle ice, snow, and stairs with ease. At first sight, it seems like a product that everyone would like to have, but the Segway still has a long road ahead.

Though the product's potential is clear to the inventor and his team, he confronts a lack of imagination and understanding from the world at large, particularly from regulators. Most people think that Kamen's invention is a new form of scooter, instead of understanding the new level of mobility it provides to people. But as soon as people start to use it, they change their mind; it is intuitive and easy-to-use.

For at least ten years after Henry Ford started building cars, people called them horseless carriages. It wasn't obvious to call it a car. They used to call the radio "the wireless." Innovation is much more about changing people, their perceptions, and attitudes and their willingness to accept change than it is about physics and engineering.

Kamen wanted to make an innovation "that has the footprint of a human, that can walk around in a crowd like a human, that can bump into somebody without hurting him." But the world sees a vehicle, and therefore believes it needs to be regulated . In the United States, some states have defined the Segway as a consumer device that is only allowed on pavements; in other states it is considered a vehicle and only allowed on roads . But as Steve Jobs put it, cities need to be built around Segway to make it successful.

So what should R&D managers, marketing managers, and designers be doing to create successful products? They should be looking at places where people could off-load work onto machines, where people complain about and struggle with products and interfaces that seem to defy understanding or just aren't worth the effort to learn, and convert these "problems" into me-centric solutions.

To create me-centric solutions, it is necessary to introduce a new design methodology. This means that the interface becomes the application, which requires a outside-in type of design. The human-centered task-analysis needs to be extended with results from human factors research. This methodology needs to revolve around the ability to have your intent understood and implemented (through delegation) rather than merely populating your environment with more tools or buttons to automate what you already do. Airplane cockpit design, for example, is about making it easier for pilots to get the information they need and reduce the amount of work they need to perform to do their tasks . To become me-centric, cockpit design should include services such as the delegation of route planning, collision avoidance , etc., which are made possible over time by increasing levels of potential automation.

This means that the revolution in design starts from the idea that machines are genies that can do our bidding, but we have to first conjure them up and put them together so they can do it. This design, which we call "Radical Simplicity," goes beyond the hardware form of boxes and reach up into the me-centric ability to tell a bot what to do. By using this methodology, it is easier to hit sweet spots in the market and open up leadership opportunities.

The construction of intelligent appliances with human interfaces is both a matter of design and engineering. These topics are concerned with the methodology and practice of interface design. Other aspects of the development process include the relationship of interface development to the engineering (both software and hardware) of the rest of the system.

4.1.2 Consequences of Bad User Interfaces

On the other hand, bad user interfaces have many consequences, of which a financial failure may be the smallest problem. If a user interface is badly designed, it means that the users need more time for performing their tasks. This can not only cause financial problems, because the tasks get more expensive, but also increase the frustration level of the users over time, because they need so long to perform a task.

As a direct result, users are more likely to commit more errors. To perform more complex and longer tasks, the users also need more time to learn how to use the appliance and need to remember more steps in the process. This means that they will probably concentrate only on core part of the task and will not bother to learn to use the full functionality of the interface, much like our alarm clock example earlier in this chapter.

Good interface design is important for any kind of software and hardware. But it is of utmost importance in systems with high costs of failure (e.g., nuclear power plants), systems with high demands on operators (e.g., rescue coordination centers, combat aircraft, call centers), and mission-critical systems (e.g., space mission control).

Table 4.1. Evaluating Human Factors for User Interface

Human factors are a key element in successful user interfaces. The following measures reflect the quality of the device employed by users in accomplishing their tasks:

  • Speed of Performance How long does it take to carry out the task?

  • Error Rate How many and what kinds of errors do people make in carrying out the tasks?

  • Success Rate How many tasks were successfully completed?

  • Time to Learn How long does it take for users to learn what actions are required to achieve the tasks?

  • Retention over Time How well do users maintain their knowledge and skills over given periods of time?

  • Subjective Satisfaction How much did users like using various aspects of the system?

To make sure that your human interface does not fail, it is important to measure the human factors of every interface (see Table 4.1). Performance speed is one of these factors. A specific implementation of a task should not only measure its performance relative to the users, but also relative to other implementations of the same task to make sure it is at least faster than the average implementation for the average user.

Two more important factors are the interface's error and success rates. It is important to know what kinds of errors are committed when operating the device, as well as what tasks are completed successfully. The error rate can be used to drive efforts to make the system reliable, while the success rate indicates how well your design accomplishes its principal objective. This is closely related to the time required to learn an interface; shorter time obviously indicates a more successful design.

Another important factor is retention over time. If a user gets training for a user interface and does not use it for a year, how likely is it that he still knows how to use it?

Last but not least, subjective satisfaction should be measured and monitored to better understand which aspects of the system the users embraced and which they didn't.

Example of Bad Interface

On December, 20, 1995, American Airlines Flight 965, a Boeing 757, crashed near Cali, Colombia [2] . It hit mountainous terrain while attempting to perform an escape maneuver, about ten miles east of where it was supposed to be on the instrument arrival path to Cali Runway 19. Approaching from the north, the crew had been expecting to use Runway 1, the same asphalt but the opposite direction, which would require flying past the airport and turning back, the usual procedure. They were offered , and accepted, a "straight-in" arrival and approach to Runway 19, giving them less time and therefore requiring an expedited descent.

[2] Thorsten Gerdsmeier, Peter Ladkin, and Karsten Loer (1997), Analysing the Cali Accident With a WB-Graph .

The crew were not familiar with the clearance they were given, became confused , and spent time trying to program the Flight Management System (FMS) to fly the clearance they thought they had been given. A confusion over two navigation beacons in the area with the same identifier and frequency led to the aircraft turning left away from the arrival path, a departure not noticed by the crew for 90 seconds. When they noticed, they chose to fly "inbound heading," that is, parallel to their cleared path. However, they had not arrested the descent and were in mountainous terrain. Continued descent took them into a mountain, and the Ground Proximity Warning System (GPWS) sounded. The escape maneuver was executed imprecisely, which led to the impact.

The aircraft should never have been so far off course or so low. The accident has been of great interest to aviation human factors experts. It was the first fatal accident to a B757 in 13 years of service. The first probable cause of this accident was the flight crew's failure to adequately plan and execute the approach to Runway 19 and their inadequate use of automation. The second failure of the flight crew was to continue the approach into Cali, despite numerous cues alerting them of the inadvisability of continuing the approach. Third, the flight crew lacked situational awareness regarding vertical navigation, proximity to terrain, and the relative location of critical radio aids. Last but not least, the flight crew was not able to revert to basic radio navigation at the time when the FMS-assisted navigation became confusing and demanded an excessive workload in a critical phase of the flight.

Contributing to the cause of the accident were the flight crew's ongoing efforts to expedite their approach and landing in order to avoid potential delays. Also contributing to the crash was the fact that the crew was trying to execute the GPWS escape maneuver while the speedbrakes remained deployed. Another big problem was the fact that the FMS logic dropped all intermediate fixes from the displays in the event of execution of a direct routing, and the FMS-generated navigational information used a different naming convention from that published in navigational charts .

As you can clearly see, the pilots were unable to comprehend and master the situation because they were overloaded with information, and the systems that should support them increased the information overload instead of resolving it. While it is clear that human error was the cause of the accident, you can also see that the technology that was supposed to help the pilots did not work in the way it should work. In emergency situations, the technology should reduce the information output to show only the relevant information, making it easier for the pilots to focus on what needs to be done. Technology should also provide guidelines and processes on how to resolve the situation, and in the worst case, be able to resolve the issues itself. The cockpit should work like an autonomous agent, even though this may be psychologically not a good idea to mention to the passengers (that's also the reason why many trains still have drivers, although it is often not required).

Besides this rather complex scenario, many people have problems using "simple" computer programs. Have a look at Figure 4.2 to see some examples of bad interfaces on PCs.

Figure 4.2. Bad User Interface

graphics/04fig02.jpg

4.1.3 Example Systems

Classic designs serve as extended examples of human interface design. These can be classified into four different groups: command-oriented, graphics-oriented, frame-based , and user-defined combinatorics.

Command-oriented designs include, for example, OS/360 JCL, is based on a batch-oriented command style and provides a baseline for seeing later improvements. MS-DOS is also still known as probably the most-used command-style interface. UNIX shells today still provide only a command-oriented environment, which make them hard for beginners to learn, but they are very powerful and very effective.

Graphics-oriented interfaces include Apple Macintosh's graphical user interface, which provides similar interface over many applications, and Star Office, an office productivity suite that offers a consistent look and feel over a set of applications.

Frame-based systems are not so well known to most people. Zog was the first commercial frame-based system available that provided a user-tailorable, rapid-response system, with a large number of frames . HyperCard was the first mass market frame-oriented system that provided a graphically-oriented frame-based system with a user programming language. Knowledge is split into chunks called frames. These frames are supposed to capture the essence of concepts or stereotypical situations, for example being in a living room or going out for dinner, by clustering all relevant information for these situations together. This includes information about how to use the frame, information about expectations (which may turn out to be wrong), information about what to do if expectations are not confirmed, and so on.

Last but not least, there are interfaces with user-defined combinatorics. UNIX operating systems, for example, have a strong combinatoric architecture, providing a logical infrastructure paired with weak human interface. While being highly structured and very powerful, it is difficult to learn how to use a Unix system, as it does not help you master your tasks, you need to learn a lot of cryptic commands, instead. Closely connected is the text editor Emacs, which is language-oriented and provides a large combinatoric command set. Another example is Nintendo's Super Mario Brothers, which even grade school children can learn without a manual.



Radical Simplicity. Transforming Computers Into Me-centric Appliances
Radical Simplicity: Transforming Computers Into Me-centric Appliances (Hewlett-Packard Press Strategic Books)
ISBN: 0131002910
EAN: 2147483647
Year: 2002
Pages: 88

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net