<< Click to Display Table of Contents >>

Navigation:  Editorials > Unclassified >


Peter Vogel          

When I build an application, I need two pieces of information first: a database design and a list of user scenarios. You’re probably pretty clear on what a database design is but may be unfamiliar with what a user scenario is. A user scenario is some activity that’s important to the 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 user interface. I know that I’ve said this before, but here it is again: A user interface isn’t driven by the application’s data design or the application’s object model. A user interface is driven entirely by the way that the users carry out their activities. Only my users can tell me this.

On many occasions, I’ve been tempted to write a UI that reflects the way I think users should do their jobs. I’ve come to recognize that this is a fundamentally stupid thing to do. The users have been doing their jobs for a very long time—it would be the ultimate case of hubris for me to come in, spend a few days or weeks analyzing the application, and assume that I know a better way of doing their jobs. Certainly, I can bring to the table a fresh viewpoint and knowledge of what software can do. This lets me help my users to understand their scenarios. But, in the end, they are the users’ scenarios, not mine. The users have to live with the application; I do not.

With the database design and the user interface design determined, 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 help ensure that I do the right things. It’s only after I’ve nailed down these two constraints that I start to develop other aspects of my application (for example, an object model, a services model, a factoring of functionality, and so forth).

But this is only the beginning: My users’ scenarios control much of what I do. For instance, if my application has a reporting component, those reports are driven by the users’ scenarios. To design an effective report, I have to know how the users will use the information—the users’ scenario for using the report. In many applications, reports seem designed to demonstrate how much data is stored in the system rather than to help the users make a decision. I’ve seen many reports where the only information used by the reader was a total at the end of the report. The usefulness of scenarios crops up in many other places. When I write a user manual, it’s the users’ scenarios that control the structure of that manual. Many unfortunate user manuals are “forms-based.” The author of the manual takes a form and systematically describes every control on the form. The manual’s author seems to believe that the user comes into work thinking, “I wonder what that 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 to the sender?” In other words, the scenario for using a manual is a user looking for a chapter called “Returning Goods to the Sender.” To support that scenario, I use a “scenario-based” approach to writing a user manual. Before the users can ask a question about anything on a form, they have to know what form to use and a formsbased approach doesn’t handle that. When you think about it, any control on any form is only interesting to a user in the way that it supports the user’s scenario.

So take a look at your user manuals. If your users wanted to know how to do something, could they open your manual or Help system and find out how to do it? Or do they have to know “how to do it” before they can find the information that they need?


Maybe You Might Like To Read

Handling Visual Complexity

See all the Editorials   or ALL THE ONLINE ARTICLES