User-Driven Design

Larry is a writer just finishing his first book. In a moment of inspiration, he decides to switch the order of two middle chapters. Using his word processor, his tool of choice, Larry grabs one chapter and drags it beyond the next. Suddenly his computer freezes, and Larry can't get it to thaw. He has to reboot it, and then re-open his work. To his horror, he discovers that his precious book has been mangled beyond recognition.

What happened to Larry can be traced back to when his word processor was designed. The designers didn't consider the Larry's of the world-that is, book writers-to be important users of the word processor. They put some functionality in it to support moving text, but not chapters, and the code which handled those transactions was very fragile. Unfortunately for Larry, the designers' concept of who the end users would be leaves his word processor prone to file corruption when manipulating large chunks of text.

We often fail to properly consider all of the users during design. Is this something you might be doing? How can you tell? Why should you care?

You may be designing the wrong product! Our different views about users are a major source of design risk.

Managing Design Risk
Before looking at user modeling, take a look at design risk itself. While risk comes in many forms, two important design risks are:

1. the risk of delivering the wrong product (the wrong design problem has been solved), and 
2. the risk of delivering the product at the wrong time, usually too late.

When managed properly, these two risks are effectively balanced against one another. Too much effort on product definition increases the risk of late product delivery, while too much emphasis on schedules increases the risk of delivering the wrong product.

Two important user constituencies in any design activity are the designerand the client.

Designer   transform the design requirements (problem statement or context) into the final product (problem solution or form). The designer's efforts are devoted primarily to resolving the "how" issues.

Client   Clients control the design process by allocating resources. The client hires and fires the designers and has final say in time and budget constraints. The client has ultimate responsibility, as exercised by funding control, over the "what" issues.

Figure 1 depicts a new set of design risks as related to client expectations. This is a visualization of what Perry and Rice in Surviving the Challenges of Software Testing refer to as the "expectation gap." The client bases her expectations on what she knows-the top row of the diagram. The designer bases the design on what he knows-the left-hand column. Each of the four quadrants leads to a qualitatively different form of risk.

Nature's Last Laugh    This is the area in which neither of the key players in the design process has access to or knowledge of critical information. Nature is hiding her cards from us. State-of-the-art projects are laden with this risk, as much of the relevant information has yet to be developed and may, in fact, not reveal itself until the final product is put into service.

Lost Opportunity    The opportunity is lost because the designer did not obtain relevant information from the client. This is a major source of disappointment to the client in the delivered product, as it forms part of the client's expectations.

Surprise   The client is surprised by features and functions that are introduced in the product based on information known to the designer but not to the client. Some of these surprises are pleasant, while others are not so pleasant. This