The Invisible Computer

9
Human-Centered Product Development

What is human-centered product development? The answer is simple: It's a process of product development that starts with users and their needs rather than with technology. The goal is a technology that serves the user, where the technology fits the task and the complexity is that of the task, not of the tool. At its core, human-centered product development requires developers who understand people and the tasks they wish to achieve. It means starting by observing and working with users, writing a simple instruction manual--no more than one page long, if possible. It means constructing and evaluating physical and software mock-ups of the device to see how its potential users employ it for its intended activities, allowing all to judge whether the design meets their requirements. Then, after a period of iterative evaluation and redesign, it means building a technology that fits the mock-ups. All of this means completely reversing today's technology-centered process.
Human-centered development is a process. It starts with a multidisciplinary team that includes representatives from marketing, technology, and user experience. The first task is to determine what the product should be. Although this seems obvious, it is the task most often ignored and most often done too quickly, poorly, and superficially. How does one define the product? Study prospective users: Watch them as they go about their daily lives. Understand what role the proposed product will play. Find activities that are as close as possible to the one the product is intended to support. The goal is to understand the users' true needs, what they care about. Then compile, refine, and analyze the observations to determine what the product might be, what role it would play, what actions it should perform. Go beyond the problem that is given to develop solutions that truly meet the customers' needs.
In all of this, take a systems approach. Go beyond the specifics of the product to understand how it is to be used in the full context of a complete activity. How does the work session start, how does it end? How often is it interrupted, and how do the resumptions occur? What other activities are required? Can you support those as well? Should you?
If the product is to be an enhancement of one that already exists, watch how customers use the existing product. Use these observations to drive the new ideas. Test the new ideas through mock-ups and simulations with the existing customers; use their reactions as feedback for further refinement. Are there potential target customers who are not using the existing product? Visit them, watch them. Why are they not using it? Is there something you could do that would benefit them as well? It's always a good idea to improve matters for existing customers, but it's even better if you can also attract new ones.
If this is a new product, make rough, crude prototypes with which to test the original ideas. Use rapid prototyping tools such as paper-and-pencil sketches, software prototyping tools, and foam models. Show them to sample users and get their reactions. Make them use the prototypes in real situations, play-acting the performance of the devices if necessary. Use the feedback from these sessions to refine the early ideas. At this stage these early prototypes and studies are not tests of the design; they are tests of your understanding of the issues, of your ability to put together a system that users feel comfortable with and that they believe will simplify their lives. Keep doing this, continually refining and testing. When the development team and the customers are happy, then it is time to translate the mock-ups into design specifications, time to start building.
These are the basic steps of the development process. But these steps are seldom followed. This method of procedural stages is new to product development. It is not taught in schools, nor is it well documented. Those who advocate these procedures are still in the early phases of developing them. There is not yet much written material available to give guidance. One method that I particularly like is called contextual design,¹ diagrammed in figure 9.1.

Figure 9.1
The flow of development when following contextual design. The tasks start with market definition, the uppermost boxes, continue through strategy definition and requirements engineering, finishing with the bottom right boxes of design adoption. User interface design (UI Design) doesn't start until the fifth box and software and hardware coding and design do not begin until the seventh box, the final and last one in this process. (Diagram from the home page of InContext Enterprises, http://www.incent.com/ (Reprinted with permission.)

In contextual design, the human-centered product team goes through considerable analysis and testing of their conceptual ideas before reaching any of the traditional stages of development. User interface design doesn't start until the fifth stage of the process; software coding and hardware construction don't start until the last, seventh stage of the process. Proponents of this approach argue that although it leads to a longer time from product conception to initial coding and building, the total time to product completion is shorter. User testing of the final product is also faster and easier. The goal at this point is find only minor difficulties, with all the major conceptual and structural issues already having been determined in the initial stages of the process, when it is relatively easy and inexpensive to fix them. My recommendations mirror this process.

Taking Human-Centered Development Seriously
What does a human-centered development team look like? How does it do its job? The answer really depends on the circumstances, on the company, and on the product itself. Will this be a new product, breaking new ground? Is this a continuing sequence, where the current product is an iteration of a previously released line of products? Is the target customer well defined, or is the product aimed at a large, undifferentiated collection of people? Will the same product be sold to millions of people with different backgrounds, cultures, and educational levels? Will it be an international product?
The pitfalls of current products and suggested solutions are well known and well documented. There are numerous books on the subject²; I've written a few of them myself. There are university courses and degrees, lectures, and consultants. There are societies and journals. The interested reader who has not yet been exposed to these topics can readily become knowledgeable. I provide some starting points in the chapter notes, and numerous consultants are ready and eager to help.
Although each company will have its own way of doing things, there are certain immutable principles that should apply to all human-centered development processes.
1. Start with an assessment of user needs, through both traditional marketing methods and customer visits. Watch the users as they perform the activities the new product is intended to assist. Use a structured interaction process, such as the contextual inquiry of the contextual design approach. Do not offer advice to the users if they run into trouble. Your goal is to learn.
2. Study the market. What other products exist? What is the likely customer segment the product is aimed at? If this is a new product, who will the original purchasers be? How do they differ from the eventual target group? What price range can they afford? Where is the product to go? What must it look like? What size constraints exist? Learn, learn, learn.
3. From the results of items 1 and 2, put together a description of the users' needs. Each need should be validated by observations, data, and market surveys.
4. From item 3, the team should create some mock-ups of sample products: physical mock-ups out of foam and other rapid-prototyping tools; paper drawings; mock-ups of electronic displays. Take them back to the customers and get their reactions. Have them play-act, using them like props in real activities. Use the customers as design assistants. Iterate steps 1-4 until satisfied.
5. With the final mock-ups and description of users' needs, write the manual if one is needed. Make it as short and simple as possible. Reward the technical writing team on the smallness of the manual. One page is the goal; five pages are better than ten. Assume the users won't read even a one-page manual.
6. Start the design process, working with the manual, the physical prototypes, and the mock-ups. Ask the technologists to meet the challenge of making the product live up to the manual and fit inside the prototypes.
7. Continually test and revise. Representatives from user experience, marketing and technology attend the tests, watching but not touching. No talking, no aiding. When potential users have difficulties, this is a challenge to the development team, not an indictment of the developers, not a reflection of low intelligence by the users. Challenge the development team.
The resemblance of my list to the suggestions of contextual design (figure 9.1) is not a coincidence. Anyone who has been involved with product development will recognize that both proposals reverse the normal scheme of things. That's deliberate. After all, we are making the shift from technology-centered development to human-centered development. It's only appropriate that the traditional order in which we start with the technology be replaced with the new order in which we start with people.
The goal is a harmonious team consisting of several disciplines, all working smoothly together. If this is done right, after a short time, people forget from which discipline the others come and instead rely on each one's individual expertise. If done wrong, there will be squabbles and jurisdictional fights.

The Six Disciplines of User Experience
User experience (UE) is not a single discipline. At least six skills are needed, and they are almost never found in the same person. There are few places that provide education in this area. In any event, the six skill sets cut across traditional academic disciplines. Here is what it takes:
* Field studies People to observe potential users in their normal settings, the better to determine real user needs. Training for this discipline is most apt to come from anthropology and sociology, where the skills of careful, systematic observation are taught.
* Behavioral designers Those who can create a cohesive conceptual model for the product, a model that is consistent, is easy to learn and understand, and will form the basis for engineering design. The behavioral designers work from a detailed task analysis of typical action sequences that are required for the tasks to be supported. They must ascertain that the solution provides support for the work flow, not just for each isolated action. Behavioral design has to mesh the task requirements with the skills, knowledge, and capabilities of the intended users. Skills in behavioral design are most apt to come from cognitive science and experimental psychology, especially from programs in human-computer interaction.
* Model builders and rapid prototypers Those who can rapidly build product mock-ups, pretend systems that can be tested immediately, even before the real technology is ready. It often takes three people to cover the capabilities required by this task: programming, designing electrical circuits, and building mechanical models. Here the skills typically come from computer programming, electrical and mechanical engineering, and model building of the sort usually taught in schools of architecture and industrial design.
* User-testers People who understand the pitfalls of experimental tests who can do feasibility and usability studies quickly and efficiently with one-day turnaround time. These rapid user-testing studies of the prototypes allow for rapid iteration of designs, the better to meet the real needs of the users. The results will be approximate rather than exact,³ which is usually sufficient, since in industry we are looking for big effects, not the small phenomena of interest to the scientist. These are the skills of experimental psychology, although what is needed in practice has to be much faster, much less labor-intensive than the traditional laboratory experiments.
* Graphical and industrial designers Those who possess the design skills that combine science and a rich body of experience with art and intuition. Here is where "joy" and "pleasure come into the equation: joy of ownership, joy of use. This part of the design must satisfy many constraints. It must merge the conceptual model and behavioral aspects of the product with the various size, power, heat dissipation, and other requirements of the technology, yet produce a device that is aesthetically pleasing ("a joy to own"), cost-efficient, and consistent with the demands of manufacturing. These skills are most frequently taught in schools of art, design, and architecture.
* Technical writers People whose goal should be to show the technologists how to build things that do not require manuals.
Technical writers traditionally have the cleanup job. When all is finished, they are called upon to make it look like the entire design was carefully orchestrated as a systematic whole. They are the cleanup artists, and often they get the least respect of all.
Technical writing is a difficult skill. It requires understanding the audience, understanding what activities the user wants to accomplish, and translating the often idiosyncratic and unplanned design into something that appears to make sense.
To a user-experience architect, the technical writers should be the key to the entire operation. Have them write the simplest, most elegant manual imaginable. Reward them for brevity. (Would you believe that some technical writers are rewarded for the length of the manual, as if a long manual is somehow more valuable than a short one? That is certainly perverse.) Test the manual to make sure people can follow it. Then build the device to fit the manual. The technical writer should be a crucial part of the development team. Indeed, if the technical writer is completely successful, the device will be constructed so well, with such a clear conceptual model, that no instruction manual will be required.

This list leaves out the sacred test method of marketing: the focus group. A focus group is a gathering of typical users to evaluate an existing product or a new concept. They are asked to describe their impressions, express their opinions, and offer suggestions, usually in a discussion-group setting led by an experienced facilitator. I am not a fan of this method of evaluation.
Focus groups are fun. They provide a lot of information. Any interaction with potential customers is always informative. But focus groups can be very misleading. They tend to reveal what is relevant at the moment, not about what might happen in the future. Users have great trouble imagining how they might use new products, and when it comes to entirely new product categories--forget it.
There is a more fundamental problem with focus groups: They tap the conscious, rational part of human behavior, which is not necessarily consistent with actual behavior during the course of a day. It will be difficult to convince you with words alone, for after all, you are reading this as conscious, rational human beings. But students of human behavior know that observations often reveal vast discrepancies between what people say they do and what people actually do. The truth is in the observations.
Much of our skilled behavior is not conscious: we are primarily aware of our acts when they go wrong or when we have difficulty. Moreover, focus groups tend to reveal what people assume they should think rather than true underlying beliefs. Mind you, this is not deliberate; within the setting of the focus group, pleasant interaction is the norm. In psychology this is called a demand characteristic. People respond to these subconscious demand characteristics by behaving in whatever manner is deemed appropriate: polite, formal, respectful. These are all essential to polite society, but not necessarily indicative of what really goes on in the familiar settings of their workplace, school, or home.
People can describe what they are doing and what conscious thoughts are in their minds, but when it comes to explaining the reasons for their own behavior they often make up folk theories. Professional psychologists are apt to be more cautious, more realistic, more accurate. It may seem counterintuitive that an outsider can explain a person's behavior better than the actual person, but this is a common finding in experimental psychology. Experimental and cognitive psychologists can generally do better than the person giving the explanation. After all, this is their field; they know the scientific studies and findings. They often know why people do things and what they need better than the people themselves.
Consider how typical users explain their jobs. They can describe their activities in great detail. The observer carefully writes down the descriptions and checks to ensure they are accurate. But then, if a user is watched on the job setting, lo and behold, the actions are usually not a good match for the description.
"Why did you do that?" asks the observer. "Didn't you say earlier that in these situations, you would do things differently?"
"Oh," says the person, "my original description was correct. This is just a special case."
True, but guess what: Most of the day is made up of special cases. The description is of an ideal that is seldom met.
I'm a fan of observation in actual settings. Don't ask people how they do their work. Watch them. Don't ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated. That's one of the reasons our computer programs have so many confusing features: Every one was requested by a user.
Approximate Methods
Designers need answers in hours, not months. This means that the UE community must learn to do its observations and tests quickly. But UE is a new discipline, one not yet fully established, one that derives from such academic disciplines as the social and behavioral sciences--cognitive science, experimental psychology, anthropology, and sociology--from computer science, and from the design disciplines of graphical and industrial design. None of these disciplines has developed an appropriate methodology for applied observation and testing.
Applied science does not need the precision of the traditional scientific method. In industry, it is good enough to be approximately right. Speed comes before accuracy. When designing a product, designers need to know how to proceed when questions arise. They need answers rapidly. The answers can be estimates, and some of the time they can be wrong. The cost of an occasional wrong answer is small compared to the benefit of many fast answers. Moreover, because we seek big phenomena, a "wrong" answer is usually less effective than the "correct" answer, but still quite usable and reasonable.
Experimental psychology has a well-established, rigorous procedure for answering questions about human behavior by controlled experiments. Following the strict rules of the standard scientific method, the psychologist carefully selects the people to be tested and counterbalances and controls the tests so as to eliminate bias and artifacts of the testing procedure. These techniques are important when the phenomena to be studied are small and delicate. It is obviously important to use when testing experimental products of pharmaceutical and medical companies. But human-centered development is concerned with big, robust phenomena, effects that apply across a wide range of conditions. As a result, careful and laborious experimental methods are not required; big effects can be found with simpler methods.
Ethnography is the branch of anthropology that deals with the scientific description of human cultures. The ethnographer seeks to live among the culture of interest, observing and recording the behavior, the rituals and ceremonies, the symbols, beliefs, and actions of the society. Ethnographers try hard to keep out of the way, to learn through their observations without disturbing the behavior they seek to record. But ethnography also includes long, laborious, detailed studies, sometimes requiring painstaking analysis of video and audio tapes on the frame-by-frame, utterance-by-utterance basis required by the scientific analyses. Ethnography is a specialized skill of the social sciences. However, its basic philosophy supplies what is needed in the applied area of product development.
What human-centered development needs is a variant of traditional ethnography, one that I call rapid ethnography. This is an observational technique for going to the prospective users of a product and observing the activities they perform, their interactions, and the subculture in which they live, work, learn, and play. Rapid ethnography is critical to the invention of new product classes. New product concepts come from observation of the needs of prospective users, devising tools that will simplify and enhance their lives. The goal is to make the people who are being observed become participants in the discovery process of learning just what their real needs are--not the artificial needs proscribed by the way they do things today, but what the goals are, what they are striving for. This is the role of rapid ethnography.
Much progress has been made in the development of methods of estimation that fit the needs of the product development process. A series of methods has been developed, called usability heuristics or cognitive walkthroughs, that speed up the test process. One description of what a rapid ethnography might look like is provided by a special form of rapid observations called contextual inquiry by the proponents of contextual design.⁴
Is a Special Discipline of UE Really Necessary?
Mature technologies are always easier to use than youthful ones. Do we really need a special discipline for ease of use and overall user experience, or will the necessary improvements occur naturally as the technology matures?
Technologies usually start off simply, growing in complexity and difficulty as they age, until they reach some peak of difficulty. From then on, as they mature, they get progressively simpler to use. In the early days of a technology, devices are usually technically simple, but limited in performance. The technical simplicity is often offset by the complexity and skill required for its use. The first airplanes were simple, with few controls, but it took a skilled pilot to fly one safely. The first radios were crystal receivers with few controls but, again, it required skill and dexterity on the part of the user to receive and tune a station. Early devices often require considerable skill to master and to use well.
In the early stages of technologies, difficulty increases with time. New functions are added, along with more controls and adjustments. But eventually, as the technology matures, the difficulty starts to decrease as technologists learn to simplify the mechanisms, improving accuracy and precision so that numerous compensatory controls are no longer required, and automating many of the operations. The difficulty continues to decrease.
Figure 9.2 shows the change in the number of controls in airplane cockpits over time, continually increasing for over 50 years but then starting to decrease with the advent of automated systems. Today's displays and controls are simpler because of the power of sophisticated computers inside the aircraft that automate many of the functions. The numerous independent mechanical meters have become integrated into integrated, cohesive graphical displays. As figure 9.2 shows, the peak of complexity for commercial aviation was the Concorde. Since that time, cockpit automation and advances in instruments have led to much simpler aircraft from the pilot's point of view.

Figure 9.2
The rise and fall of complexity of aviation cockpits. In the early days of aviation, cockpits were pretty simple, with few instruments. As airplanes added multiple engines, radios, and navigation equipment, the cockpits grew in complexity and difficulty of use--reaching a peak with the Concorde. There were so many dials, instruments, and controls on the Concorde that the designers seriously considered eliminating all windows to leave space for the displays. After the Concorde, complexity and difficulty of use started decreasing with the advent of computer-controlled displays and the so-called "glass cockpit," the substitution of a computer display screens for multiple mechanical instruments. Increased automation further reduced the need for so many displays. Today's aircraft have reached the point where even I have flown such advanced airplanes as the Boeing 777 (in simulation at NASA and the Boeing Company), mainly because all that is needed for takeoff and landing is to push the correct button, and sometimes not even that. (Chart reprinted from Wiener and Nagel 1988; middle photograph courtesy of Boeing; bottom photograph courtesy of Air France.)

The early automobile had manual cranking to start the engine, as well as manual spark advance, choke, and transmission. Today, engine starting, spark advance and choke are handled automatically, and the majority of cars have automatic transmissions. In some brands, automation has so much taken over that manual transmission is an extra-cost option. Even the seat controls are automated. Early radios had multiple controls for tuning, sensitivity, and frequency bandwidth; today, the radio can find its own stations, and all that is left for the user is to set the listening level. Television circuits have become increasingly complex, the better to simplify the interactions required by the user. So, too, with all technologies. In all these cases, the simplicity for the user has come at the cost of greater complexity of the device itself.
The usability of all technologies is poor whenever the power and performance of the technology fall below the level required by the users. Here is where the device looks complex, for the user needs numerous controls and adjustments to compensate for the impoverished technical abilities of the device. As the technology matures, however, it can simplify the activity from the users' point of view, even if at a cost in complexity for the technology itself.
The big question today is whether computers will follow this same cycle. Perhaps they are just now reaching their peak in difficulty for the user. Perhaps as software engineers become better able to automate the functions, the difficulty of the actions required by the user will decrease, just as it did for other technologies.
Personally, I am counting on this phenomenon. The success of the information appliance can come only about if the underlying technology is sophisticated enough to work effortlessly, with no need for control or advice from the user. The personal computer can probably never reach this level of simplicity because the attempt to have one device do many tasks guarantees complexity, even if any single task can be made relatively simple. Moreover, any task requires a minimum level of control that is governed by the nature of the task itself.
Look at writing. Writing still requires the writer to fashion the words, in part through trial and error, making multiple corrections. The visual component of writing conveys much of the emotional or information content, and so it will always be necessary to allow a writer control over format, heading, and type font, as well as, of course, wording. Some forms of writing require footnotes and figures, with references, headings, and tables of contents and indexes. Even as they get replaced by live links to text, hyperlinks to other texts, and live documents, the need for human selection of the links, content, and manner of presentation remains, for writing exploits the human ability to manipulate emotions, to describe, to tell stories, to inform and educate. These pose minimum levels of complexity and activity on the part of the writer, thresholds that cannot be decreased.
Aircraft provide an excellent example of the role of automation in simplifying the task. Although the new, integrated instruments that comprise the modern automated "glass" cockpit have dramatically simplified the job of the pilot, the instruments and the automation themselves are the results of many studies by researchers in the field of aviation psychology and human factors. Some of the aviation automation has increased the risk of problems, because it has taken the pilots "out of the loop," so they are not always aware of the state of the airplane. As a result, when things go wrong, pilots may take longer to grasp the situation and respond than had there been no automation, so that they would have continually been engaged with the system. Mindless automation can be more dangerous than no automation, a topic I have explored elsewhere.⁵ Advanced technology and automation can simplify the tasks in dramatic fashion, but the manner in which this is done is enhanced by the expert judgment that a human-centered development process can provide.
Automation has decreased the user's level of difficulty in many technologies. It will--and already has--with the digital computer. But the simplification is made more certain and beneficial if it is done with care and concern for the abilities of the human. Do we really need a special discipline of designers specialized for ease of use? Yes, we do.

Forming the Successful Triad of Technology, Marketing, and User Experience
When products reach the mature cycle of their life where customers are demanding convenience, a high-quality user experience, and other consumer attributes, product development has to become human-centered with three equal supporting components: technology, marketing, and user experience. Good development cannot come about without all three. Moreover, all three legs must rest upon a common foundation: the business case for the product.
Note the complementary role of marketing and user experience. The two should form a strong bond, for they are the ones who understand the customer. Marketing knows what customers are asking for, what drives their behavior at the point of sale, what they will pay for, and what determines their purchasing habits. User experience knows what customers actually do, what makes a product simple or difficult, usable or not, likely to require handholding via expensive telephone calls to the service help lines or not. Alas, marketing and UE are often in conflict, for each likes to think it "owns" the customer, each feels its insights are superior. No component is superior: marketing, technology, and user experience have to work together as a team, like three equal legs of the tripod that supports product success.
User experience consists of designers and observers who know what people actually do, what their real needs are as opposed to their stated needs. UE understands behavioral design, the better to make the product work smoothly and easily. On the other hand, user experience people seldom understand market pressures and what drives sales. This is the expertise of marketing. They are expert at point of sale issues, the kinds of concerns customers bring to bear when they buy. Marketing people seldom are designers, capable of translating the lessons they have learned from customers into a product that works. Together, marketing and UE should make a great team, if only they could bridge the gap of differences in background and language.
In similar fashion, engineers are experts at the technology and at engineering design, both hardware and software. They are not behavioral designers; they are not trained to understand the needs of real users, to understand the psychological principles and science underlying human-centered development. Engineers also often fail to understand market pressures. In turn, neither marketing nor user-experience experts possess the knowledge of engineers. These three disciplines are all essential for the success of the product, but each speaks a different language, comes from a different starting point, and focuses on different things. The challenge is to bring their practitioners together and help them learn how to cooperate as equal members of a team.
Proper development does not come about by accident. Human-centered development requires a focus and commitment to the users of the product. It requires the skills of the appropriate professionals. But most important, it requires the proper organizational structure within the company so that human-centered development permeates everyone's thinking from product conception through manufacture and sales.
It isn't easy to put together a human-centered development team in a company without one. This is especially true in technology-driven companies, where the history and culture emphasize technical excellence, often at the expense of usability and convenience. When a company makes the transition to the world of consumers, when it tries to cross the chasm from early adopters to late, conservative and pragmatic ones, it has to learn to change its development process. Does the company want human-centered development? It may have to reorganize.