Questions about forms

This selection of questions and answers about forms first appeared on the website to accompany my book (with Gerry Gaffney) Forms That Work: designing web forms for usability . We’d thought of calling the section “Frequently Asked Questions” but we thought we ought to be accurate: it was a collection of things people asked us about from time to time. It has been updated for the move to this Effortmark website.

What do you think about progressive disclosure: valid or sneaky?

Gianpiero (@gpiero on Twitter) asked: “What do you feel about Progressive Disclosure in forms. Valid or sneaky (considering you’re probably hiding the a lot of fields)?”

I’m a huge fan of progressive disclosure, provided it’s used in an honest way.

Let me explain by talking about relationship and conversation.

Relationship: because you’re clearly already, and correctly, thinking about how your form will create or undermine trust between your organisation and the people filling in the form. Yes, you can use progressive disclosure sneakily. Lure people into the form with a simple question, then as they gradually commit more time and effort to answering you can lure them into feeling that they’ve put in so much already that they may as well continue.

But you can also use progressive disclosure in an entirely valid way, to hide complications from people who don’t need to know about them yet – or maybe, ever. In my specialist area of government forms there are always 80/20 rules; 80% of the people filling in the form will only need to know about 20% of the possibilities.

Which brings me to conversation: the sequence of words, questions, and flow through the form. Finding the appropriate balance between being honest with people but without overwhelming them, that isn’t easy. It takes careful attention to your content design, and lots and lots of iterations of usability testing and improvements.

How can I deal with international address formats?

The Universal Postal Union website is the authoritative source of postal authorities’ preferred addressing formats. If you want to make sure that post you send conforms to the postal authorities’ needs, then this is the place to go. You can check individual countries’ preferences on the website, or purchase a CD-ROM that lists all of them. If your main aim is to satisfy the postal authorities, you’re done.

But if you want to get good data from your users, you still have a lot to think about. For example:

The official view of addresses may not be acceptable to the particular user. For example, many countries have areas that are disputed in some way. In my own country, the United Kingdom, we have problems in Northern Ireland where some parts of the community have extremely strong preferences for one name and there are equally strong preferences for another name for the same town. Using the ‘authority’ version could be deeply offensive to the other group.
There are also parts of addresses that are not required by the postal authorities but that are required by companies that make deliveries. For example, in my own address the county name is not required by the postal authority but is helpful to delivery companies.
In some countries people have completely different street addresses and postal addresses. For example, in Australia it is quite common for the postal address to be in a different place, such as a nearby town, if the street address is is a rural area.
Most people are very familiar with typing in their own address. Although you will often see drop-downs listing over 100 countries, and drop-downs listing 50 states (or more if the designer has considered Australian states and Canadian provinces), I am frequently told by usability people in the USA that these drop-downs do not test well at all. People much prefer to type in their state, often using the two-letter acronym.

As Graham Rhind points out in his free ebook Better data quality from your web form book, you really need to think in terms of name and address forms (multiple) rather than a single form. Having multiple forms will allow you to:

Identify the preferred language and country for your user
Ask for the name and address in the way that is familiar to and appropriate for those users
Use facilities such as postal code look-up that may be available in the particular country (e.g. in the UK).

From the user point of view, it is usually better to ask for an ‘unsplit’ address – one that offers a type-in area without imposing any formatting on the user. This is also likely to be culturally acceptable in many countries. Unfortunately, I have heard reports that it doesn’t test too well in the USA.

If is is essential to split the addresses for some reason that clearly helps the users, then at the moment I am recommending that you look at your top three to ten countries. Allow the user to choose from this much shorter list, and then for all other countries ask the user to type in an unsplit address. You will find that three to ten countries are very likely to account for over 80% of your target user population.

Do not force any field to be compulsory in an address. It is alienating to many users if they have to ‘invent’ part of their address simply because a form requires it. It is acceptable to politely ask the user if they meant to omit part of the address, and accept their answer.

How can I help a user choose from a very large list?

In some cases, it is necessary for users to select a precise entry from a very large list. For example, one enquirer described the need (for compliance purposes) to have users choose an ‘Occupation’ code from a list of almost 1000. How could she make that long list into something that’s usable?

Although the occupation code has to go on the form, it should not be necessary for the user to pick from such a large list. The designer should try to present the user with some way of filtering to reduce the size of the list.

Consider the following approaches:

Find out what the common categories are, and offer them first
Allow the user to enter plain text, and then try to match with valid list entries (listing the 10 closest matches)
If the occupation codes are in a logical grouping, offer the grouping so that users can choose the group first, and then narrow down to the specific occupation.

In any case, you should certainly conduct some category testing with your users to ensure that what you offer them aligns with categories they expect.

See Caroline’s article on Should I use a drop down: four steps for choosing form elements on the web.

How can I manage the ‘Back’ button in web-based forms?

Developers are often concerned about what will happen in web-based forms when people use the ‘Back’ button. For example, users may fill in part of a form, then click ‘Back’, not realising they may lose the data they have just typed. Since usage of the ‘Back’ button is ubiquitous, should this be a concern for forms designers?

To answer this question, I ask myself why the users are using ‘Back’.

Maybe they want to lose the data. For example, a user may complete parts of a form, but then be confronted by a question they prefer not to answer (at least not in the context of their current relationship with the organisation or website). In such a case, use of the ‘Back’ button does not result in accidental loss of data (although if many users were abandoning your form at this point, you might want to re-consider the questions you are asking or the point in the form at which they occur).

Another reason for hitting ‘Back’ is see-sawing, where the user goes back to review previous entries or information in order to tackle questions on the current page, then goes forward again to return to this page. See-sawing implies that you have failed to achieve ‘unity of topic’. Each page should be self-contained and self-sufficient, so that the user does not need to go back to find previous information.

A third reason is that the user thinks they are finished entering the data and hits ‘Back’ to navigate elsewhere. For example, many users will return to the Home page on a site to navigate from there to another point. You can also see this behaviour when people use search engines.

If this is happening, then you have failed to show users that they have not finished the task. This could be an appearance problem (lack of an obvious ‘Submit’ button) or a conversational problem (users consider that the relevant questions have been dealt with). If you are experiencing this problem, further investigation is required to find out what users are thinking when they hit ‘Back’. Refer to the post ‘Designing usable forms: the three-layer model of the form . Note that all these problems arise from poor User Interface design.

A final reason could be that the user has decided to do something else, and leaves your form with the intention of returning later, not realising that the data enterered will be lost. Offering a ‘Save’ function may be a way to get around this issue.

Overall, my recommendation is to design the form so that the user completes it page by page without feeling the urge to abandon a page part-way through.

If each page is on a sensible topic, then users are likely to prefer to finish the page prior to moving elsewhere on the site.

Can I use an asterix to indicate optional fields?

“Our form has many required fields and few optional fields. We think that we should use an asterisk to indicate the optional fields. Do you agree?”

It makes sense but it is also a bad idea.

The problem is that most users spend most of their time on websites other than yours, and on forms other than yours. Their experience on other websites habituates them to the idea that an asterisk means a field is required.

If you then change that convention and try to make an asterisk mean that a field is not required then you are asking your users to learn a new convention purely to interact with your site.

I can envisage circumstances where this might be acceptable (for example, a small-population intranet where users are highly trained in that particular site), but my strong recommendation for all standard circumstances is that you should use the asterisk to indicate required fields rather than ask your users to learn the opposite convention for the relatively short time they spend with your site.

How can I improve a complex form?

If you have a long, complicated form then here are some things that you can do to help users through it:

Find out which parts of it are truly necessary. Can you simplify it at all, or perhaps delay some parts of it until later in the relationship?
Try to arrange the fields into groups. Janko Jovanovic has some ideas for patterns to help with complex forms.
Use a summary menu to help users keep track of where they are going in the form. A progress indicator is another possibility, but doesn’t work as well if the users might need to collect information from elsewhere and therefore jump about in the form.

For more tips on designing complex forms, try these presentations (different tips in each one):

Will you be creating a second edition of Forms that work?

No. Writing a second edition would be very timeconsuming, and we’d rather spend our writing time publishing short articles in a more timely manner.

If you’re mostly interested in interaction design and the appearance of forms, then we recommend Jessica Enders’s book “Designing UX: Forms” (2017). She’s done a great job of covering what’s happened since our book came out.

If you’re mostly interested in service design and the relationship of forms, or in content design and the conversation of forms, then we think that our book will be fine for you.

#forms #formsthatwork