Prototyping . . .

. . . because user's CAN'T tell you what they want, but they CAN tell you what they don't like!

Have you ever noticed that it's difficult for users to determine what they want in an application? Even if it's an application automating a process that they do all the time?

You spend months designing and developing an application. You show it to the user and their reaction . . . "but it needs to work like . . ." . . . "that won't work for me" . . . "why doesn't it do . . ." . . . "ok, but what about . . ." . . . Well, you get the idea. Users often don't know they want until they actually SEE something.

Enter prototyping. There needs to be a quick and inexpensive way to show the user something; to let them get their hands on something so they can work through what they do. By extension, something so they can then tell you what they don't like or can't use BEFORE you have spent a great deal of time and a lot of money.

One benefit of prototyping is that users often discover that they do more than they actually think they do while performing their day-to-day process. They remember that decision that they didn't tell you about in design or discover that they actually have more information than they initially told you or determine that the yes/no action actually has a maybe option. By prototyping and giving them something that they can manipulate they realize this early in the development cycle before you have committed to many resources to the effort.

The key to early prototypes is to keep them SIMPLE. Not simple in terms of functionality, necessarily, but simple in terms of development effort. Keep the graphic elements simple, also. This forces the user to concentrate on the important elements of the process rather than the color of the screen or the wording on a button. You want sessions with early prototypes to flush out the major logic and data requirements rather than wasting resources on irrelevant details like colors or type styles. Revise and flush out your prototype until your user is satisfied with the flow of your system. This can save hours of coding -- and recoding -- as you actually develop.