The double life of forms

What is a form?

A form is a tool for collecting data.

Want to buy a book online? Fill out a form so that the seller knows where to send the book, and how you want to pay. Data has to be collected from one party (the buyer) to enable action from another party (the seller). The form is the tool that enables this.

The term ‘tool’ has been used deliberately here. Forms are tools just like screwdrivers are tools. Both are a means to an end, and it’s often the end we care more about than the means. The homeowner cares about the screwdriver only as far as it allows her to assemble a desk. Once the desk is made, the screwdriver is put away. Similarly once the book has been received, the form-filler doesn’t really care about the purchase form.

But it’s not always this way.

Forms as documentation

In some situations the form is not just a means to an end but also an end in itself.

Think about a safety checklist. (This checklist can be on a mobile, a tablet or a desktop; here, the medium is irrelevant). By definition, a safety checklist is a form because it collects data. This data will show what is needed to keep people safe. Maybe a cable needs to be taped to the floor, or a warning should be placed on a boiler. These are the ‘ends’ for which the safety checklist is a ‘means’.

But the safety checklist may also be an ‘end’. It is a record that someone, at some point in time and place, reviewed safety. Such records are important for compliance, quality assurance and/or auditing purposes. As such, the safety checklist may be kept, even once the actions that it prompted are complete.

In the case of the safety checklist, the form is both a tool for collecting data and a piece of documentation.

Differences between forms and documents

When it comes to the user experience, forms are all about answering questions, filling-in, providing data. The interaction with a document, however, is more passive: reading.

Another way to think about this different usage is that a form is an input mechanism whereas a document is an output mechanism.

These differences have implications for design. If a form has been designed to suit input, it may not be very usable as a document, i.e. as output. Here’s an illustration. Suppose our safety checklist has 24 items. If only two of those items are selected, a reader is going to have to search quite hard to find the data; the completed form is not very usable as a document.

What if the document is just as important as the form? When forms were all paper-based, the only way to get around this was to manually transfer data that had been input on the form to a separate, differently designed, output document. With electronic forms, however, it’s much easier to output data in a different format from the way it was input. If our safety checklist is electronic, we can design the form to make checking off items as easy as possible. Then, we can have a summary screen or page, which shows just the items that were selected.

By designing our form and our document to suit their respective uses and contexts, we can create a much better user experience for both. Some situations where this is done well include:

  • booking a flight (form) being designed differently from the boarding pass (document);
  • registering a business (form) being designed differently from the certificate of registration (document); and
  • applying for a passport (form) being designed differently from the receipt you take with you when proving your identity (document), and the passport that you’re eventually issued (document).

In each case, and in our safety checklist example, the form has to be designed to suit a variety of situations (e.g. different types of businesses or different hazards). In this way the form must be reasonably generic. The document, however, contains just the subset of information that is relevant to the particular instance. That is, the document is specific. Often, what allows this is some sort of unique identifier, which links the document back to the form (e.g. a booking reference or application number).

Figure 1: The key differences between a form and a document. The former is a mechanism for input, is centred on answering questions, and has to be reasonably generic. The latter is focused on reading, is a method of output, and can be made specific.

Forms that look like documents

So far, we’ve been talking about documents that follow the design of the form (i.e. are suited to input but not necessarily output). Sometimes it’s tempting to go the other way around: design the form to follow the document. For example, we could design the passport application form to look like an actual passport, and have people provide data wherever it will appear in the printed booklet. This is a kind of skeuomorphic form design.

Many mad libs forms are examples of forms that look like documents. If you’ve read our post, you’ll see that in the vast majority of cases, we strongly recommend against mad libs forms.

Most of the problems with mad libs forms apply more broadly to any form whose design follows a document:

  • users often have to expend greater effort to read, interpret and answer questions;
  • such forms are harder, and thus slower, to move through;
  • it is easier for users to miss questions altogether and/or lose their position;
  • questions have to be very carefully worded to provide sufficient context and clarity;
  • there isn’t an ideal way to handle multiple choice questions;
  • it’s difficult to suitably incorporate help, tips and other supplementary information; and
  • they are likely to be inaccessible for some users.

So, if you have a form that is also a document, and can’t have two separate designs, design for the form. A document can be used even if its design isn’t ideal. In contrast, if a form is poorly designed, both it and the document are unusable.

Improve overall user experience by designing both forms and documents

Hopefully this article will help you look at forms differently, and see that sometimes they live a double life.

Which forms in your organisation are used not only as forms but also as documents? There is an opportunity here to ensure great user experiences for both form-fillers and document-readers.