Elements of User-Friendly Windows Program Design

by Andrew Bernhardt

INTRODUCTION

Most custom interactive business applications do not have enough attention given to the user interface. The end result are programs that may meet the original design specifications, but are difficult to use and create significantly more work and stress for the user than they should. Many times the "front-end" of an interactive software application is what makes or breaks the program.

This document describes techniques that I have found through over 20 years of experience in interactive applications that make software very user friendly. Comments, suggestions, and corrections are welcome.

DETERMINE THE USER

When it comes to designing user-friendly, interactive software, we must first determine who is going to use the software. To be truly user-friendly, a program must operate the user's way, not force the user to operate the programmer's way.

In terms of user interface design, interactive software comes in two varieties: that used primarily by novices, and that used primarily by experts. This distinction is important, because user-friendliness to an expert has a different meaning than to a novice:

A novice...	An expert...
...uses the program occasionally, or only to do a limited number of simple tasks.	...uses the program regularly to do various complicated tasks.
...tells the program what to in generalities, and expects the program to handle the specifics.	...tells the program specifically what to do and how to do it.
...expects to be walked through a process (ala, a "wizard"), with plenty of help provided along the way.	...expects the program to be flexible enough to follow the processes defined by the user.
...treats the program like a skilled carpenter hired to build a house, or a taxi driver hired to drive to a destination.	...treats the program like a tool used to build a house (the user is the carpenter), or a personally driven car.
...is generally limited to only "safe" actions. Possibly dangerous actions are more difficult or impossible to access.	...can easily do actions that are considered dangerous for novice users.
...should have easy access to common tasks, but less common tasks are harder to access.	...should have easy access to most tasks, common or uncommon.
...operates slower because he does not understand the details of what he is doing. He needs to read the instructions.	...requires the program to keep up with him because he already understands how the program operates. He has a job he needs to accomplish, maybe in a limited amount of time, and wants to avoid anything that slows him down.

While it is pretty obvious that software designed for experts can be difficult for novices to use, the opposite is also true: many times software designed for novices can be more difficult for an expert to use.

For example, there are various brands of photo-editing software on the market. Some use a menu or wizard approach: the user selects what he wants to do and the program walks him through it. This method is hostile to the expert user. Adobe Photoshop is an example of a program designed for expert users. Even though it is more difficult to use for novices, it is very easy for experts to use. This is one of the main reasons Photoshop has been number one with professionals for years.

Despite these differences, it is usually possible to make a program that is user-friendly for both novice and expert - it just requires greater thought in designing the software's front-end. (If there is a conflict between these two types of users that can't be resolved, the software needs to cater to the type of user that will be using it most.)

When designing new software, it is tempting to think of users as novices because they have never used the software before. But remember that anyone who uses a program frequently will become an expert user in a relatively short amount of time. Novices become experts, but experts never become novices. If users are going to be regularly using the program, design it for experts.

TIPS FOR ALL PROGRAMS

The following tips apply to all types of interactive Windows software, regardless of who it is written for. Many of these are just common sense, and are already pretty well known. Not all apply to every program:

HELP AND ERROR MESSAGES:

Include context sensitive help for all controls. Short (one or two sentence) control-tips can be used as simplified instructions.
In general, help and error messages should make sense to the user, using terminology that the user is familiar with. Avoid technical and programming terms. If an error makes sense only to the programmer (i.e. an internal error), include some sort of contact information so that the user can contact the programmer.
Messages should communicate as if talking directly to the user (i.e. "Please enter a date in the future.", not "Invalid date entered by user."). Communicate using second-person pronouns, not third person pronouns.
Error messages should include either instructions on how to correct the error, or a reference or URL link to the same.
When an internal error occurs, a nice option is to provide an easy way for the user to send debugging information to the programmer. It is really nice for the debugging information to include a log of all keystrokes and mouse clicks detected by the program so that the problem can be more easily duplicated.
When the user must enter data in a multi-field form that is submitted all at one time, avoid displaying a dialog box error message immediately after an invalid entry is made. Fields with bad data can be highlighted and errors messages can be displayed unobtrusively on a status line, but only when the form data is submitted should error dialog boxes be displayed.

DATA INPUT:

The program should respond to user input as quickly as possible. For delays any longer than about a second, display an hourglass icon or some other "busy" indicator.
Avoid pauses in data entry. Try to move all slow processing of data to before and/or after all data entry. The program should not require the user to make some input, then have the user wait before entering more data.
For database applications, most or all data in the database should support viewing, adding, changing (editing), deleting, and searching.
Expert users can benefit from the use of advanced search options, including the use of wildcards in search strings, searching by any displayed field, and searching multiple fields. Perhaps even allow the user to type in an SQL WHERE, and save the searches for later reuse.
Allow multiple levels of undo. At a minimum, the user should be able to undo the last action, and all previous actions for the current session.
For input fields, don't just use typical default values. Use appropriate default values based on previously entered data, calculated if necessary. The user may benefit by the use of combo boxes instead textboxes, where the user can select from previously entered values (like Microsoft Internet Explorer's URL address bar).
Just because there is a control available for a particular type of input doesn't mean it is a good idea to use it. Some date and time controls are awkward to use. They require pressing TAB or a cursor key to move between the year, month and day, or between the hour and minutes. It may be easier to use plain textboxes for date and time entry and also allow the data to be entered in any format that Windows recognizes - the software automatically detecting the format when possible.

OTHER:

The program needs to do all of the hard work, including relieving the burden of repetitive or unnecessary keystrokes, calculating appropriate default values, reducing (as much as possible) the potential for user error, and yet not restricting the user unless absolutely necessary.
The user-interface should have some influence over the design of the rest of the program. In the earliest stages of development, list all data inputs that the program requires and group related items together in a logical order. Many times this provides helpful input not only into the designed of the user interface, but also the design of the database. Design the user interface so that most, if not all, keys relate directly to providing input to the program, avoiding program navigation keys. Especially for expert users, avoid requiring the use of nested menu items and wizards for common functions. (Wizards can be used, but the user should not be required to use a wizard to accomplish a task.)

Ease of use is quantifiable! For data-entry type programs, minimize keystrokes and mouse movements. Use a point system to calculate how easy the program is to use to accomplish each task it is capable of. Here is a sample point system:

Unshifted keystroke	= 1 point
SHIFT'ed keystroke	= 2 points
CTRL'ed or ALT'ed keystroke	= 3 points
Mouse movement (positioning)	= 4 points
Mouse left click or double click	= 2 points
Mouse right click or double click	= 4 points
Switching between keyboard and mouse	= 4 points

For each function that the software is capable of, go through all of the keystrokes and mouse clicks required and add up their point value. Look for ways to reduce the total points to a minimum.

While all tasks should be as easy to accomplish as possible, ensure that the most common tasks are the easiest.

For data-entry and program navigation, avoid using the mouse because it is more difficult to use than the keyboard, especially for expert users. The keyboard is faster because the user rapidly learns to do repetitive keyboard tasks automatically: the user trains himself to press the same sequence of keystrokes without having to think about it. The user cannot be trained to use the mouse this way because positioning the mouse accurately always requires conscious effort. (This is why I gave mouse functions higher point values in the above table.)

Avoid useless keystrokes. For example, if an ATM machine only allows a customer to withdraw money in $20 increments, don't require the user to enter the cents portion of the value - those are two extra key presses that are always the same. The user is thinking in terms of dollars, not cents, anyway. (However, do require entry of the unit-dollar digit because it is common sense to the customer to type 2 0 for twenty dollars instead of just 2.)
When combo boxes or list boxes contain data items that can easily be specified by typing it in, allow the user to do so, rather than forcing the user to use the mouse to choose an item in the list. (For this reason, it may be better to use a combo box in place of a list box.)
Make the user-interface consistent. Don't force the user to do similar things in different ways. For example, in Microsoft Internet Explorer's options window, you can delete temporary files as well as clear the history. Although these are both very similar operations (both basically just delete files), each uses a different method. To clear the history, all the user has to do is click the YES button. However, to delete temporary files, the user must click a checkbox and then click OK... this is inconsistent and takes one extra mouse click. Deleting temporary files should be done the same way as clearing the history.
Avoid hard-wiring settings (work directory paths, etc). Allow the user to configure these.
Avoid modal dialog boxes for general data input or status display.
Eliminate or reduce the possibility for the user to make easy or dangerous mistakes, but keep the software flexible enough so that the user can still do the unusual. Don't assume that the user will only need to do common tasks. The software should be smart enough to detect possible erroneous inputs, but not so smart that it will not let the user submit those inputs (i.e. the program should not assume it knows better than the user). This may take a lot of thought but it can usually be done.
When upgrading existing software, strive to make the new version easier to use, or at least no harder to use than the previous program. This means there should be no more keystrokes or mouse movements/click to accomplish a given task as there was previously (unless there are some significant advantages to the new method).
Expert users like to enter database records in an editable grid, which allows for very easy cell navigation, and viewing of multiple records at the same time. Calculated fields can be done so automatically as data is entered (either upon every keystroke, or when focus changes to a different cell). Column widths should not only be adjustable, but should be remembered across sessions.
Plan for the future. Try to give the user more than the minimum asked for. Allow the user to customize the application enough to support future requirements. For example, allow the user to specify what information appears on reports and how it appears.

The overall first-impression that a user has of a software product should be that it is easy to use, with a simple, uncluttered front-end. Then, as the user gets familiar with the program, its power and flexibility should become apparent, and yet still be seen as easy to use. The user should be able to focus on the job at hand and not struggle with the software itself.