When I build an application, I need two pieces ofinformation first: a database design and a list of user scenarios. You’reprobably pretty clear on what a database design is but may be unfamiliar withwhat a user scenario is. A user scenario is some activity that’s important tothe user and that will require the use of my application. A scenario is not“Updating the sales order header”; a scenario is “Creating a sales order.”
Once I have a list of scenarios, I can develop a userinterface. I know that I’ve said this before, but here it is again: A userinterface isn’t driven by the application’s data design or the application’sobject model. A user interface is driven entirely by the way that the userscarry out their activities. Only my users can tell me this.
On many occasions, I’ve been tempted to write a UIthat reflects the way I think users should do their jobs. I’ve come torecognize that this is a fundamentally stupid thing to do. The users have beendoing their jobs for a very long time—it would be the ultimate case of hubrisfor me to come in, spend a few days or weeks analyzing the application, andassume that I know a better way of doing their jobs. Certainly, I can bring tothe table a fresh viewpoint and knowledge of what software can do. This lets mehelp my users to understand their scenarios. But, in the end, they are theusers’ scenarios, not mine. The users have to live with the application; I donot.
With the database design and the user interface designdetermined, I’ve nailed down what I think of as the two ends of my application.These two constraints limit the range of the errors that I can make and helpensure that I do the right things. It’s only after I’ve nailed down these twoconstraints that I start to develop other aspects of my application (forexample, an object model, a services model, a factoring of functionality, andso forth).
But this is only the beginning: My users’ scenarioscontrol much of what I do. For instance, if my application has a reportingcomponent, those reports are driven by the users’ scenarios. To design aneffective report, I have to know how the users will use the information—theusers’ scenario for using the report. In many applications, reports seemdesigned to demonstrate how much data is stored in the system rather than tohelp the users make a decision. I’ve seen many reports where the onlyinformation used by the reader was a total at the end of the report. Theusefulness of scenarios crops up in many other places. When I write a usermanual, it’s the users’ scenarios that control the structure of that manual.Many unfortunate user anuals are “forms-based.” The author of the manual takesa form and systematically describes every control on the form. The manual’sauthor seems to believe that the user comes into work thinking, “I wonder whatthat checkbox in the lower left-hand corner of the Return-To-Sender form does?”As developers, we frequently do ask those kinds of questions. Our users do not.
Users ask questions like, “How do I return goods tothe sender?” In other words, the scenario for using a manual is a user lookingfor a chapter called “Returning Goods to the Sender.” To support that scenario,I use a “scenario- ased” approach to writing a user manual. Before the userscan ask a question about anything on a form, they have to know what form to useand a forms-based approach doesn’t handle that. When you think about it, anycontrol on any form is only interesting to a user in the way that it supportsthe user’s scenario.
So take a look at your user manuals. If your userswanted to know how to do something, could they open your manual or Help systemand find out how to do it? Or do they have to know “how to do it” before theycan find the information that they need?
