If you step on board the elevator in the morning and ask it to provide a glass of freshly squeezed orange juice, will you be disappointed if it provides frozen juice? Or will you be delighted if it provides juice at all? If you buy a box of Superchalk and find it doesn't fit in your chalk holder, will you be disappointed? Or will you be delighted its fatter shape makes it easier to grip, and renders the chalk holder superfluous?
As every experienced designer knows, the difference between disappointment and delight is not a matter of delivery, but of how well delivery matches the clients' expectations. If we think of the design process as a way of providing delight and avoiding disappointment, we'll never be successful if we can't control expectations. That's what this chapter is about: first understanding why different expectations arise, and then applying a heuristic for discovering and limiting the clients' expectations. This expectation limitation process is used to explore and clarify users' expectations and is performed for each user constituency.
If all the prior steps have been done properly, the expectation limitation process would be logically redundant. As it is, an additional step is needed to limit expectations because
1. People are not perfect.
2. People are not logical.
3. People perceive things differently.
4. Designers are people, too.
Let's look briefly at each of these factors, as a prologue to explaining the expectation limitation process.
People are not perfect. Based on our experience, we can assure you nobody ever does everything perfectly right up to this point. (We hope this is reassuring, not discouraging.) The expectation limitation process, among other things, acts as a check on the imperfections of earlier stages in the requirements process. Having such a check near the end also serves to demonstrate you don't expect the participants to be perfect. This in itself should limit their expectations in a healthy way
As Star Trek's Mr. Spock always says, "Humans are not logical," and this includes your authors. Some years ago, Jerry clipped a coupon for a free night's stay at any Holiday Inn with one night paid. In order to save the money, he carefully chose a Holiday Inn over a much nicer Ramada, but when he checked in and presented the coupon, the desk clerk wouldn't accept it. "But," Jerry objected, "it says it's valid at all Holiday Inns."
"No it doesn't," said the clerk triumphantly. "It says all participating Holiday Inns. This Holiday Inn isn't participating in this promotion." The Ramada across the street wasn't participating either, but Jerry decided to move there anyway. Still, Don thinks it was unfair of Jerry to punish Holiday Inn because he couldn't read plain English. Even so, Jerry's negative reaction is rather typical of customers who discover upon delivery the true meaning of some "invisible" word in the requirements document. Like Jerry, they will suspect they have been intentionally misled.
Even though we imply the requirements document states all and only what the system will do, people may have unstated expectations about things not mentioned in the documents, or never discussed in the process. We have many examples in everyday life—warranties and insurance policies come immediately to mind. Our reaction to them demonstrates that being logically, or even legally, correct is not the same as satisfying the user.
One of the most interesting systems development projects we ever experienced was the creation of the worldwide space-tracking network for NASA. Each station was designed from the ground up, and, since many tracking sites were in remote and often primitive areas, that literally meant ground up. Many stations had no local power supply adequate to operate the requisite radars and computers, so stand-alone diesel power was provided.
As it turned out, however, the power supplies were designed by experienced radar people because at that time the computer people had little or no experience in this kind of stand-alone power. Once the station went into operation, the computers crashed every time one of the spare diesel generators went on- or off-line. The problem was traced to electrical transients. The computer people pointed haughtily to the requirements document that said, in effect, "There shall be no transients affecting the continuous operation of the electronic equipment."
But the radar people argued the diesel power system they had designed met this requirement. "It doesn't disturb the radars at all," they said. "In fact, we overdesigned it a bit, so it shouldn't cause you any trouble." The problem, of course, arose from the two cultures of radars and computers, each of which used similar language to mean rather different things.
As it was too late to redesign or replace the diesel power, a signaling system was installed so the power engineer could warn the computer operators when a switchover was about to occur. The computers were then shut down and a signal sent back to the power station saying it was okay to switch generators—a clumsy but operable solution.
One day, the computer operators were going out to lunch and decided to shut down the computer equipment in case the power was switched over while they were out. As they left the computer building and started down the hill, the power engineer raced out of his building, screaming, "What the #*©.'*%# are you trying to do! You #*©/*%# nearly cracked one of my flywheels!"
"What do you mean?" the computer operators asked in all innocence. "We didn't do anything."
"Well, somebody cut the load in half," he screamed over the roar of the diesels. "My engines almost tore themselves off their blocks. If that happens again, I could be killed."
Once again, the problem proved to be a misunderstanding between the two cultures. When the radar equipment shut down, its power requirement declined in stages. When the computer system went off, it shut down all at once. As simple an act as shutting off the power was entirely different for the two types of equipment and could have cost someone's life.
This problem was solved with the signaling system, too, but catching and fixing these problems in the requirements process would have been much better. Eventually, all differences in expectations are worked out, one way or another, but it's obviously much easier to use an explicit, up-front process to catch these differences.
In requirements work, you want to express information in limitation form, which is the easiest way for customers to understand special details. It's your job to help the customer understand, in contrast to those whose job it is to write insurance policies, warranties, and phrases like "participating Holiday Inns." These people are trying to protect their own interests—but not trying to have customers notice the exceptional cases. If they were trying to help customers notice, they could write things differently, for example,
Warning: Not all Holiday Inns are participating in this offer. Be sure to check with each Inn at the time you make your reservation.
Designers, of course, have all the above human characteristics, plus some others as well. For instance, designers, even more than ordinary mortals, tend to be enthusiasts for their own ideas and oblivious or resistant to the ideas of others. To balance their enthusiasm, they need a warning system, so when they begin to be carried away by some great idea, they must stop and consider limitations. This extra step acts as a damper on unbridled egoistic enthusiasm.
To counter the effects of these all-too-human factors, we've developed a heuristic for exploring and clarifying user expectations, called the expectation limitation process. It consists of four steps.
Start with a comprehensive list of user expectations, which may be obtained in a face-to-face session of representative users, or by some sort of user survey, or a little of each. For face-to-face work, we like to trigger the users with an open-ended question, such as
• "What are you most looking forward to in this system?"
• "Which part of the new system will be most valuable to you?"
The answers become the expectation list (see Figure 18-1).
Figure 18-1. "What's the thing you're most looking forward to in this product?" From the same piece of Superchalk, some people will want the world. Others will want to save time, to be loved, to get justice, to win friends, to get a raise, to help their country, or to win recognition. And some won't know what they want. In any case, the question will reveal user expectations, and lead to clarifying the product's limitations.
Interviews are essential, because you must listen carefully to uncover general expectations only implied in specific examples. For instance, one user might say, "When I ride the elevator, I can find out the important stuff I haven't had time to read in the newspaper." In order to understand this expectation, we'll have to ask just what he means by "important stuff" in the newspaper. We might be surprised to discover the only parts of the paper he reads are the stock quotes and the fashion pages because he's in the women's clothing business.
The generated list of specific expectations for the Elevator Information Device might include items such as these:
1. "When I ride the elevator, I'll be able to find out the important stuff that I haven't had time to read in the newspaper."
2. "I never have time to take my blood pressure. Riding the elevator is a waste of time, and I'm trapped there so I might as well have my blood pressure taken."
3. "I'll second that, and I want to know what the blood pressure means. I need to know if I have to slow down."
4. "All that stuff is okay, but crime is the big problem in this building. It's going to be harder to get tenants if all this mugging and robbery continues. To me, the most important feature is recognizing criminals and convincing them that they won't get away with anything in our building."
5. "I don't want any more breakdowns. This device has got to give plenty of warning to the superintendent when something's not right with the elevator."
6. "It's got to be quieter than the elevators we have now. I can hear people arguing in the elevator, and it disturbs my patients."
7. "Also, by the time my patients get finished riding up that elevator, they are nervous wrecks. I spend the first twenty minutes just calming them down from the elevator ride. Somehow, I expect this device to keep them calm, or at least distracted."
8. "You know, warning me that the elevator is about to fail is very nice, but my experience is that some of these warning devices break down more often than the elevator itself. Then they give dozens of false alarms. I'm too busy to put up with another failing piece of complex equipment, so this device better not fail. At least not very often."
9. "You're all missing the point. The main thing is that this device has to coordinate elevator usage in peak hours, or else we'll have a revolution by our tenants. I know that we can do a better job of optimizing elevator use. I'm spending half my time answering complaints about the elevators."
10. "Yes, but that's all invisible to the passengers when it works right. I'm looking beyond that, to our image as the most modern office building in the downtown area. We need the artificial intelligence feature, so that people will be amazed that the elevator recognizes them and treats them personally, as if they were really special. That's what will attract the tenants."
11. "But if we start giving special treatment, we can't discriminate against anybody, or we'll have the government on our necks."
12. "And that includes the handicapped—we've got to be sure that everyone can use it, even if they can't see or hear."
13. "I think we're making this much too complicated. There are millions of elevators now in service, and they've been through just about everything. All we need to do is have this device communicate with other elevators in other buildings and learn from their experiences. How will it be done? I don't know. I'm no technician, but they can solve anything with computers these days."
Having obtained the list of specific expectations, our second step is exploring them to discover the full range of what is really expected. As we obtain this information, we revise and generalize the list, eventually producing a list that might include items such as these:
1. Upon request, the device will provide any and all information available through the internet—including at least the latest weather information, stock quotations, sport scores, and news items.
2. The device, also upon request, will provide individuals with simple health-related information such as blood pressure, pulse, and general state of stress and distress.
3. The device will warn individuals of potential health calamities.
4. The device will detect people thinking about committing a crime in the building and try to convince them that crime doesn't pay.
5. The device will diagnose elevator maladies and warn the appropriate people.
6. The device will quiet elevator passengers and controllable elevator sounds whenever the elevator passes quiet floors.
7. The device will soothe passengers experiencing anxiety in the elevator.
8. The device will be self-diagnosing and redundant enough to be completely fault-tolerant. It will replace any failed subsystem without loss of function and notify service personnel of the failed portion to be replaced.
9. The device will provide all current speed, direction, and floor stop command information to a central system which will moderate and coordinate optional commands on all building elevators in such a way as to make "optimal" use of each of the elevators. Optimal is to be determined by individual building managers, and may involve minimizing waiting time, energy consumed, complaints, or other such measures.
10. The device will determine the identity and travel patterns of all individuals who make frequent use of the elevator system, tell the individuals where the system "thinks" they want to go, and deliver them to that location by default. An override will be provided for passengers not wanting to go to the default location, and the system files will be updated. The device continually learns and monitors its own performance in adapting to its environment.
11. The device is capable of interacting effectively with all human beings independent of natural language, intelligence, age, intentions, or degree of physical impairment.
12. All information provided by the device will be available to at least two of the three senses—sight, sound, and touch—depending on the individual receiving the information.
But what shall you do with item 13, which expects to have "this elevator communicate with other elevators"? You should be happy to get a few crackpot ideas, because the generalized expectation list will be a more useful instrument in the design process if it is created in a fantasy mode. This assures that nobody's expectations, no matter how wild, are omitted. We can indulge in this fantasy because we know the expectation limitation process will put rational bounds on the flights of fancy.
As our next step, each item on the generalized expectation list can now be put into one of three broad categories:
P Possibility, to be achieved now
D Deferred, to be achieved in a later version
A Absolute impossibility, to be dropped from consideration
Each different assignment of expectations to categories is likely to produce a substantially different design solution. Once again, the advantage of this process is in making explicit those decisions the designer would otherwise make implicitly. Making decisions explicit will improve the match between expectation and realization of the design, or at least bring conflicts to the surface before too much time and money have been expended.
Sometimes, designers are reluctant to make decisions explicit because they fear conflict will result, but an essential part of design is the ability to communicate and then negotiate about disputed areas. By structuring the process of limiting expectations, we make it easier to deal with potential conflicts in a rational way. For instance, suppose there is a dispute over the first item:
1. Upon request, the device will provide any and all information available through the internet—including at least the latest weather information, stock quotations, sport scores, and news items.
If the designer considers this to be too broad yet the clients consider it too limited according to their expectations, we would need to negotiate the content and rephrase the wording to make the perceived limitation quite explicit. We might finish with a restated expectation:
1. The device will provide, upon request, any and all information available through AP, UPI, Reuters, Dow Jones, CNN, and ESPN wire services. These, along with local building sensors, are to be the only sources of information external to the elevator itself in the initial implementation. To the extent possible, the design will not prevent future extensions to other sources of information.
By the way, AP, UPI, Reuters, Dow Jones, CNN, and ESPN may not be fully available on the internet without special subscriptions. If that is the case, then the previous statement—"all information available through the internet"—would be inadequate. Those subscription services, though expected, would not be fully available. "Limiting" does not always mean "reducing."
Why is limiting expectations so important? Each different assignment to Possible, Deferred, or Absolute produces many unique design solutions. If you don't make the assignment consciously, you will miss many design solutions, even many categories of design solution. If you make the assignment implicitly, you might be consistent with your client's thinking—if you happen to be extremely lucky.
Even if you are lucky, you probably won't know you are until much later in the design process—perhaps not until the final product is revealed. A wealthy lady, Mrs. Smythe, donated $14 million to a city in the Southwest for an art gallery. On the day of the opening, Mrs. Smythe was to cut the ribbon at the front door, but there was no way to reach it in her wheelchair!
The mayor publicly vilified the architects for not making wheelchair ramps an "achieve now" possibility (P). They defended themselves by saying they assumed it was a "deferred feature" (D), to be remedied later—using funds from a second donation promised by Mrs. Smythe. Needless to say, her second donation was also deferred.
Explicitly limiting expectations would have revealed the need for a wheelchair ramp—but that's only part of the story. Suppose it was really impossible to have a wheelchair ramp ready for the grand opening? Millionaires might be different from the rest of us, but most people would rather hear the bad news up front than feel cheated at the end. If you don't believe this, examine your own feelings.
Clients of the Elevator Information Device may not be happy they have to settle for something less than all possible information on opening day. On the other hand, better—and more ethical—to let them experience the disappointment while the system was being designed, rather than surprise them when the system was delivered.
For several reasons, not every expectation will result in a limitation. In rephrasing item 1, we were able to direct the designers explicitly to keep open the possibility of future extensions to the information system.
Sometimes an entire item may be taken as a possibility, perhaps implemented now, or perhaps deferred. For instance, consider this expectation:
2. The device, upon request, will provide individuals with simple health-related information such as blood pressure, pulse, and general state of stress and distress.
Item 2 could be classified as a possibility and stand as written, which expands our thinking about the design problem to include this new dimension.
Of course, as the design proceeds, we may discover item 2 can no longer be implemented because of legal, economic, or medical reasons. In that case, item 2 would be reclassified as an absolute limitation and rephrased to show the source of the limitation:
2. Because the cheapest medical diagnosis system now available costs more than $400,000; the device will provide no health-related information of any kind to elevator passengers.
As we proceed through the entire list of expectations, some new possibilities will be added. At the same time, other possibilities will be transformed into limitations, so both designer and client will be clear and in agreement about just what the system won't do—especially things it might otherwise be expected to do. And why it won't do them.
Change is normal and natural, and this process of revision during the requirements process is no different from the revisions taking place later. But if we give limitations without reasons, the list becomes almost impervious to change. For instance, a few years from now, a new diagnosis system might come on the market for $4,000, rather than the current $400,000. By explicitly showing the source of the limitation, we're paving the way for later modifications as circumstances change.
1. In a way, working out the radar/computer problems was like translating the requirements into different foreign cultures and languages. In those tracking stations where English was not the native language, certain documents did have to be translated. This translation process incidentally did a great job of revealing some additional hidden expectations.
2. When you have a development project to carried out in or for two different cultures, you'll have plenty of problems arising from different cultural expectations. On the other hand, you can use the two cultures to your advantage by making sure both are involved in the requirements process, in the same room at the same time, if at all possible. This may seem clumsy but it's merely doing necessary work otherwise done later at greater expense.
3. Also, if you are going to have to translate requirements, don't wait until the requirements are finished before the translating begins. Have translation done in parallel with the development of the requirements. You'll find the exposure of differing expectations more than pays for the cost of translation.
4. You can learn a lot about how requirements can create improper expectations by reading disclaimers, warranties, and special offers from the "holiday inns" of the world. (If you travel frequently, you'll find this book will more than pay for itself if you follow this suggestion,. If not, you can obtain a full refund at any participating bookstore.)
5. A good exercise for revealing hidden expectations is the Rule of Three:
If you can't think of three reasons your great idea might fail, then you haven't thought enough about it—yet.
For example, many designers wax enthusiastic about the use of color coding in the Elevator Information Device. What effect will color coding have on blind people? What about color-blind people? People wearing coated lenses?
6. Sometimes designers say, 'If the clients knew about this limitation now, they'd kill this project. But after it's built, they'll like the other features so much they won't mind if this one is left out. They probably won't even notice, so let's just keep it to ourselves and not make waves." Our advice: Do not allow yourself to be tempted by this reasoning. It is the first step to losing track of who is the client and will lead to worse things than killing the project. What you can do, however, is pay attention to the process by which you inform the clients of this potentially disappointing limitation. You may be surprised. First of all, you may not understand just what it is the client expects. Or, the client may not care as much as you thought, or may be able to accept a reasonable alternative. Any of these outcomes would prevent the infective strain of secrecy and mistrust. Or, the client may be a bit more clever than you think, and will suggest a way of satisfying expectations you never imagined.
7. Sometimes the limitation process can bog down in its own fantasies. Someone might say, "Yes, but suppose a blind person is standing on his hands, with his head in a bucket of water, and tries to operate the elevator controls with his bare feet. I don't think it will work." And then someone adds, "Yes, and suppose he's diabetic, and is waiting for his trained monkey to give him his insulin shot, but the system recognizes monkeys and won't allow them on the elevator."
8. Of course, you don't want to suppress anybody's ideas, but your reluctance may make it impossible to define any limitations at all on an expectation. Sometimes, you can control this sort of fantasy gone wild by appealing to the Doctrine of Reasonable Use, which says, "We can't imagine all the bizarre things someone might do with this system, but we'll know what is reasonable when we see it. (And what do you think about having your head in a bucket of water?)"
9. The Doctrine of Reasonable Use ultimately derives from the legal system. Questions of liability can be very real inhibitors to design, so if someone truly thinks liability is at stake, you may simply have to invoke legal help. Quite often, merely asking, "Should we bring in an attorney on this issue?" will bring a sense of calm reality to the group—or else you may really have to pay for an attorney.
10. Our colleague Eric Minch comments that the argument, "limitations without reasons ... are impervious to change" can also be applied to functions, attributes, constraints, and all other descriptions of the product. At the same time, another colleague Ken de Lavigne observes that this explicit process of documenting limitations is radically different from what is common practice, which is to throw away all design materials after the code is written or, even worse, to keep them around without updating them. Ken then quotes a "British acquaintance" who remarked, "It's a pity that in many organisations (sic) the only cogent statements of business policy are to be found written in assembler language."
11. It may be unreasonable to expect common practice to change quickly, which is why we've emphasized documenting limitations as a start. Documenting why you're not doing something seems to be more palatable than documenting why you are doing something. Once people taste the usefulness of documenting their reasons, the practice may spread to other descriptions of the product.
12. One method of documenting reasons—recorded video interviews with designers and users—seems more acceptable and useful than anything else we've tried. Many of the questions we've presented can be used, and people seem pleased enough to talk about their reasoning process. The videos can be dated and stored—and most people seem reluctant to throw away videos.
Designers need to be explicit with users about the limitations on their expectations because products and systems are much more readily accepted if the limitations are expressed honestly up front. Conversely, users feel cheated when they discover a limitation after the fact. Also, the process of developing and documenting limitations early in the design process helps to reveal important facts about the product or system.
Raise the question of expectations whenever there is an indication of user dissatisfaction, as from the results of a user satisfaction survey. But even when there is no obvious indication, conduct the expectations cycle as soon as the first round of requirements work seems to be drawing to a close.
To raise and document expectations and limitations, follow this cycle:
1. Generate a list of specific expectations from representative users.
2. Work with the list to understand and generalize each expectation.
3. Negotiate to limit expectations to a reasonable level, leaving open possibilities for future modifications of the system, but definitely ruling out anything that can't reasonably be expected.
4. When setting a limit, be sure to document the source of the limitation, because today's limitation becomes tomorrow's opportunity.
Involve every category of user, in one way or another, so as to provide fuel for the expectation limitation process. When the limitations have been documented, place them in the hands of those users, to complete the cycle.