9. User Models—Better Wrong than Vague
An architecture team
Anderson Ross/Getty Images Inc.—Stockbyte
. . . [T]ruth will sooner come out of error than from confusion.
SIR FRANCIS BACON [1620],
THE NEW ORGANON
Explicit User and Use Models
Experienced designers often begin by writing down exactly what they know about the user, the user’s purposes of use, and the modes of use. Wise designers also write down explicitly what they don’t know but assume about the user and uses.
Where there are multiple different applications or multiple different sets of users, they describe each, then define explicitly the weightings among them so as to define the use model.1
The more detailed and particularized these assumptions, the more occasion they offer for early detailed thinking. This thinking would have been required anyway later, as the design proceeds. Doing it early forfends mistakes.2
Really?
Who actually does all that extra work before starting on a design? The answer, of course, is that very few of us do. In my view, we need to define explicit use and user models in many more cases than we do. Doing so will improve design practice.
The need for explicit models of both applications and users follows directly from the peculiar characteristics of modern design: design by teams and the design of complex tools as opposed to simple ones.
Team Design
All designers in fact have user and use models consciously or subconsciously in mind as they work. Team design creates the all-new requirement that the entire team have the same user model, the same use model. This requires explicit models and assumptions.
This exercise is rare because the members of the team usually believe, without anyone saying so, that they share a common set of assumptions. After all, each one heard the enterprise leader charge and challenge the team. Each one has read the goal-defining document. All are expert.
Matters are not so simple. Each of us has in fact had a different experience using similar systems; my experience informs my picture of the typical user. Each of us has been exposed to a different set of applications; my exposure helps me define this application. If the team does not draft a common set of explicit assumptions, each designer will work with a distinct set of implicit ones. Microdecisions too minor ever to be discussed will be made differently, and conceptual integrity will be lost.
Differing use models inevitably yield design inconsistencies in a team design. Operating System/360 (now z/OS), for example, reflects in several parts two quite inconsistent debugging philosophies—one assuming batch use, the other assuming time-shared use from terminals. There was no conscious decision to cater to two use modes; it merely reflected subgroups holding differing use models.3 The result was bloat and incoherence.
Complex Designs
As tool complexity grows, the need for explicit use models increases. Even for a shovel, it is important to be explicit as to whether it is for coal, dirt, grain, snow, or some mix; whether for child, woman, or man; whether for the casual user or the manual laborer. How much greater is the need for explicit use models for a truck, a spreadsheet, an academic building!
Moreover, the more complex the design, the less likely the designers are to be domain experts who could do the users’ jobs. Implicitly assumed models are then much more dangerous.
What If the Facts Are Not Available?
As soon as the designer starts to make explicit use models, trouble strikes: he is rudely confronted with how much he doesn’t know. The very effort forces him to ask questions he might not otherwise have asked until much later. This is an unmitigated good.
Suppose one is designing a program product to route and schedule school buses. Some careful fieldwork with two or three “representative” school systems will yield facts galore: time constraints, number of buses, number of drivers, geographic distribution of pupils. Yet, when one sets out to state a use model for a general routing and scheduling program, these facts just drive more questions.
To what degree are the sampled systems representative? Over the whole intended user set, what are the ranges of all those parameters? Their distributions?
What are the rates of change from scheduling period to scheduling period? What will the ranges be five years from now? Ten years?
As the questions get harder, the answers get vaguer. What is the designer to do if he has committed himself to making explicit use models?
Guess!
I am quite convinced that, once he has moved beyond questions that can be answered by reasonable inquiry, the designer should guess or, if you prefer, postulate a complete set of attributes and values, with guessed frequency distributions, in order to develop complete, explicit, and shared user and use models.
An articulated guess beats an unspoken assumption.
Many benefits flow from this “naive” procedure:
Guessing the values and frequencies forces the designer to think very carefully about the expected user set.
Writing down the values and frequencies exposes them to debate. It is easier to criticize something concrete than to create, so there will be more input from the whole team. The debate will inform all the participants and will surface the differences in user images that the several designers carry. It typically also will surface other unrecognized assumptions.4
Enumerating the values and frequencies explicitly helps everyone realize which decisions depend upon which user set properties.
More important, it raises these crucial questions: Which assumptions matter? How much? Even this sort of horseback sensitivity analysis is valuable. When it develops that important decisions are hinging on some particular guess, it is worth the cost to develop a better estimate.
In the end, however, many assumptions will remain debatable and unverifiable. The chief architect must own—and make known—the set the team goes with.
Better Wrong than Vague!
At this point the reader will object, “How can I know or even assume so much detail about uses and users?” The answer is, “You will in fact make those assumptions anyhow”; that is, each design decision will be guided, consciously or unconsciously, by the designer’s assumptions about uses and users. What this often means in reality is that the vague designer substitutes himself for the user, designing for what he assumes he would want if he were the user. But he isn’t.
Therefore, wrong explicit assumptions are much better than vague ones. Wrong ones will perhaps be questioned; vague ones won’t.
Notes and References
1. A use model is a weighted collection of use cases. Robertson and Robertson [2005], Requirements-Led Project Management, treat use cases in considerable detail.
2. Cockburn [2000], Writing Effective Use Cases, is a thorough treatment.
3. Brooks [1995], The Mythical Man-Month, 56–57.
4. Students in my advanced computer architecture course have been required to do this for their term projects. When it has been done conscientiously, the effect on the designs has been very beneficial.