User Interface

It's a good idea to prepare a draft user interface document to discuss with the client before you go too far into the user interface designs discussed in the remainder of this book. For small systems, however, a draft might unnecessarily delay the design process.

Even when you don't intend to perform a formal user interface design, it's often useful to dummy up some sample screens marked "DRAFT" or "SAMPLE." Sample screen layouts such as these can help users visualize the proposed system. You need to be careful, though. No matter how often you indicate that screen shots are only samples and subject to change in the release system, they inevitably set user expectations. If the released system looks too different, all your good intentions might have only muddied the waters.

Setting user expectations is usually a problem only if the functionality for which you've provided a sample screen gets dropped from the scope of the project later. I have had users expect all the screens shown in the initial requirements, even though they'd seen and approved a later interface specification that excluded them. In these situations, I've learned to include the dropped screens in a section called "Functionality No Longer Included" or words to that effect. A brief description of the functionality being excluded and the reasoning behind the decision are extra insurance that everyone knows where they are.

Once you have defined the user interface, you need to communicate it to the users. There are two primary mechanisms for doing this: a prototype and an interface specification. I almost always prepare both, if for no other reason than building a nonfunctional prototype is the easiest way for me to prepare the illustrations around which I structure the specification.

Interface Prototyping

The best tool I've found for communicating the interface for a new system is the interface prototype. Many users, particularly those without a lot of experience with computers, have trouble making the leap from seeing a set of screens on paper to imagining what the system will look like and how it will operate. Giving them an interface prototype means they don't have to make the leap.

Prototypes come in all shapes and sizes, and they can be used for any number of purposes. One of the simplest is just dummy screens and menus tied together to model the flow of the release system. The only code in an interface prototype is that required to link the screens together. All the controls are in place, but they are not tied to data or otherwise functional. Likewise, the only menu commands that do anything are those that display a dialog box. (Well, that's not quite true. I usually give the other menus secondary windows that say, "This command will do such and so. This functionality has not been implemented in the prototype.")

The only exception to the "no-code zone" rule is when the physical display is determined by the data. For example, say you've designed a screen for entering and editing customer details, but the screen details depend on whether the customer is an individual or a company. You might decide to have the visibility of controls dependent on the choice a user makes in an option box. You'll need to implement this in the prototype.

I usually build the interface prototype using whatever front-end tool I expect to use in the final system. Because I work in several different development environments, this technique eliminates the "ah, hell, I forgot that you can't do multi-column combo boxes in VB" syndrome.

But using the development environment is dangerous. You're building a prototype here, not a system, and so it's appropriate to take all kinds of shortcuts that would never be acceptable in production code. But it's hard to resist the temptation to use the prototype as the basis for the release system.

After all, all those screens and menus are already built, and it's a waste of time not to use them, right? Wrong. Those screens and menus are prototyped, not built. If you use the interface prototype as the basis for the release system, you run the risk of perpetuating the shortcuts you took, and they will come back to haunt you.

Because of this danger, some designers recommend that your interface design be done using a drawing tool rather than using a programming tool. Visio, for example, provides some limited support for designing interfaces.

You should use whatever tool suits you best. For me, that means the programming tools I use every day. For you, it might be a drawing tool or even a presentation tool such as Microsoft PowerPoint. (I have one client who religiously takes screen shots of my prototypes and transfers them to PowerPoint for his internal presentations. He doesn't add anything to the screen, he just likes PowerPoint.) The important thing is to be clear about what you're doingyou're documenting a design, not building a system.

Interface Specification

Although an interface prototype is a wonderful tool for giving users a sense of how the system will operate, it has intentionally limited functionality. For this reason, it cannot replace an interface specification. (The reverse of this is not true, however. A careful interface specification can eliminate the need for a prototype.)

Like the documentation of the data model, the user interface specification must include technical information that can't be entirely avoided by the client. The same recommendations applykeep the technical terminology to a minimum, and wherever possible separate any really technical stuff that can be conveniently ignored by the client from the main body of the document.

If you've built an interface prototype, preparing the interface specification is straightforward. I include a bitmap of each screen, a narrative description of its purpose and any processing it implements, and a table listing each control and the control's data source (if any). If you haven't built a prototype, you'll want to describe the layout in some other way, but the remaining information is the same.

In most systems, it's useful to include an overview of the system flow. If the system will support a number of distinct work processes, you might want to provide a model of the screen flow for each process. It's simple enough to do this by annotating the work process diagrams.