Before You Design the Form

Before you start  designing a form, you should be clear in your mind what the aim of the form is and what you need to find out from the user. There are some useful questions you can ask yourself to help clarify the issues. Having answered these questions, you'll save yourself time in the actual design of the form.

What Is the Form's Purpose?

Here you should be thinking of the general task that you want to perform. For example, is it a search form to allow users to search for something on your site? Is it an order form, allowing users to purchase something online? Is it a test, where users will be marked on their answers? Is it an application for some service? And so on… In our case, it's an online order form for delivery or collection of pizzas.

As we'll see, you may actually end up with more than one form in the finished product, but understanding the aim of the form(s) that you're designing gives focus to the other questions that we'll meet in this section.

What Information Do You Need To Collect?

Exactly what information  do you need from the user? This should be a complete list of the information that the user will be required to offer. You might start with a general list that includes things like addresses. Then, for each item from that list, you would go into the detail of what information makes up these requirements, such as house number, street name, suburb, and postcode in the case of addresses. For example, we need to know the following:

• Which pizzas a user wants.
• Whether they want the order delivered or ready to collect.
• What their name is.
• What their address and phone number are.
• If they want side orders.

We can split this down further, to give the exact information we need:

• Pizza: type, size, quantity, extra toppings.
• Whether they will collect the pizza or want it delivered.
• When they want the pizza.
• Name: first name, last name.
• Address: street, suburb, postcode, additional information for delivery.
• Phone number: area code, phone number.
• What side orders they want, in what quantities.

It's worth remembering that there are often two aspects to information collecting.

First there is the information that you want from a user to get the job done. You can be quite strict on this; for example, do you really need a home phone number, a work phone number, and a mobile phone number? Are you ever going to use that fax number if you ask for it?

Then comes the question of what information you want to capture from your user for the purposes of research and marketing. (As we'll see later in the chapter, you also have to be aware of data protection issues, as most countries have laws governing the collection, storage, and use of customers' data.) When it comes to the second question, it's often tempting to get as much information about the user as possible.

However, the  longer a form is, the less likely the user is to complete it, and indeed there are some answers that users don't like to divulge (such as income or details of possessions). Unless there's a reason for the user giving the data, you should not assume that they'll be happy to give it out. And unless you're sure that you're going to use some data in your research, you should not collect it. If you present a user with a form that requests non-essential data, then the user may be tempted to get the service or product you offer from an alternative source, where it takes less time to fill out the form.

If you really must  collect data that's non-essential to the task in hand, though, consider offering users an incentive to give it, such as entering them in a prize draw or providing them with privileged information. Or, for example, our pizza company could offer free toppings or a second pizza free in return for answering extra questions. The questions that are non-essential should be at the end of the form  and clearly marked as optional (you should be very clear about which data is optional and which is mandatory when you come to designing the form).

Does Some of This Information Fall into Logical Groups?

If there are groups of like  information, put them together. In our case, we might group information
like so:

• Delivery/collection + when they want the pizza
• Name + address + phone number
• Pizza details + side order details

Grouping information will help the user to understand which section of the form they are completing.

Is There a 'Real-Life' Equivalent of the Form That Users Will Have Previous Experience of?

If you're creating an online application form, are there printed versions that the user will have used? If you're creating a web application, is there a software equivalent that the user may have used? Is there a standard way of representing the information that you're collecting that the user will have had experience with?

If the answer to any of these questions is yes, then you should make the form relate to their previous experience. This will help the user to understand the new technology quicker.

For example, you could be creating an online purchasing application, which could relate to the purchase order form that the user previously had to fill in on paper. If you're creating a web-based e-mail application, its design and use could reflect the package that the user is familiar with. If you're collecting address information, ask for it in the same way in which a user would write out the address.

What Information Will You Be Storing in a Database?

Certain information you will only require your users to divulge once. For example, you might only require that they provide their delivery details once. You should decide which items of information you're going to require each time a user visits the site and which you'll be able to retrieve from a database – given some kind of user authentication.

If you are considering  storing credit card details then you should check with local legislation, as many countries impose restrictions on how long you can store such information for. You may also need to be aware of data protection laws regarding divulging information about customers.

If you are going to store information about users, then it's a good idea to have a page that explains what you do with data and how it's stored in layman's terms, in order to address customer concerns. The link to this need not be prominent – you can put a link to it by the first form control that indicates that user data is stored, then it may just appear in the footer of remaining pages.

If your forms are being  processed manually, as opposed to by a script that populates a database, you can be a lot more forgiving about how a user enters the data in the form.

Is There Any Other Information That You Have To Provide On the Form?

You should also consider what other information should appear on the form. This could include legal notices, summary details of a shopping cart, or timers for a test. What you might have to add depends on the topic of the form.

Before You Design the Form – Summary

• Make sure you know what information you need from a user, and group it together.
• Only ask for data that you really need.
• Be clear which information is required and which is optional.
• Look for real-world equivalents of the form that the user will be familiar with.
• Make sure you comply with local legislation for storage of data if you intend to keep it in a database.

Usable Forms for the Web
Usable Forms for the Web
Designing the Form