Form

Examples:

Tax forms
Job application forms
Ordering merchandise through a catalog
Ordering a pizza over the phone

Context: The user has to provide preformatted information, usually short (non-narrative) answers to questions.

Problem: How should the artifact indicate what kind of information should be supplied, and the extent of it?

Forces:

The user needs to know what kind of information to provide.
It should be clear what the user is supposed to read, and what to fill in.
The user needs to know what is required, and what is optional.
Users almost never read directions.
Users generally do not enjoy supplying information this way, and are satisfied by efficiency, clarity, and a lack of mistakes.

Solution: Provide appropriate "blanks" to be filled in, which clearly and correctly indicate what information should be provided. Visually indicate those editable blanks consistently, such as with subtle changes in background color, so that a user can see at a glance what needs to be filled in. Label them with clear, short labels that use terminology familiar to the user; place the labels as close to the blanks as is reasonable. Arrange them all in an order that makes sense semantically, rather than simply grouping things by visual appearance.

Visually, arrange the blanks and labels according to a spatial grid; align the edges of the stronger graphic elements, like boxes, where you can. Give them a neat look and a good visual rhythm, but don't let a strong geometry overwhelm the meaning of what is written or provided -- big arrays of edit fields (or whatever) look scary! If there are a lot of them, at least separate them into subgroups (Small Groups of Related Things); again, do this according to the meaning of the information, not just what looks good.

Provide reasonable default values wherever possible, to lessen the amount of work that the user has to do (Good Defaults). If the user provides information that makes some parts of the form irrelevant, disable them (Disabled Irrelevant Things). Likewise, if the user provides some clue which enables a software-based form to predict what information will be filled in elsewhere, then have the software do it for them. For example, if a user is providing their address and phone number, the town they provide might only have one area code in it -- so fill in their area code for them. But don't do it wrong; that's worse than not doing it at all, because the user then has to both notice the error and correct the form.

Be forgiving about the format of what the user provides, as much as is possible (Forgiving Text Entry). But if the required information simply must follow a certain format, then an empty, featureless text field is the worst possible thing to have to fill in. You never know if you're doing it right. Always offer a clue about what is expected by constraining the user's input in a reasonable way (see Structured Text Entry for one example), and don't resort to validating afterwards, giving the user a nasty message about how wrong their input was. Giving an example right there on the form is a better idea, but still not as good as a visual constraint.

(Sometimes, cultural factors make visual constraints unnecessary. A login screen, for instance, usually just has fields for "User name" and "Password" -- the possible input strings are constrained, of course, but 99.9% of its users will understand exactly what is expected, and constraints or extra information will be more trouble than it's worth. See Don Norman's The Design of Everyday Things for lengthy discussions of physical and cultural constraints.)

Resulting Context: You must pick controls for each of the pieces of information to be supplied. These may include:

Choice from a Small Set, if the user should pick one or more from a set of 10 or fewer choices (give or take).
Choice from a Large Set, if there are more than 10 choices.
Editable Collection, if the user should construct a list of items.
Sliding Scale, if the possible values vary linearly between an upper and lower bound.
Forgiving Text Entry, if the recipient of the information is capable of parsing whatever text the user provides, which could vary widely.
Structured Text Entry, if the recipient needs the information in a very specific format and cannot parse a potentially wide variety of responses.

Notes: No one ever fills in forms for fun. They do it because they want something (as with a catalog order), or because they are compelled to do it (taxes), or because it's their job (data entry). It's pointless to be cute or clever, and if you make the user have to read extra instructions, or go back to redo something they misunderstood the first time around, or jump around the form to fill in things "out of order," they will be irritated.

If you can find a non-contrived way to use something other than a form, do so. For instance, why ask someone to laboriously fill in a day, month, and year when you can just have them pick a day from a calendar? [Use three pictorial examples here: a date as a Forgiving Text Entry, a date as a Structured Text Entry, and a date as a calendar widget.]

Comments to: jtidwell@alum.mit.edu
Last modified May 17, 1999