[Skip To Content]

Clients

Past Work
Join Our Mailing List

Web Access Strategies

How Can We Prevent Form Fatique?

I think the first step is to really evaluate whether all the fields are truly necessary. I've found that in most instances, a client will request things on a form that really aren't necessary. They need to understand that there's a very real risk that users will look at a long form and just refuse to fill it out. Or, they may fill the form out but bounce when something they've entered fails validation and they think to themselves "I've already filled this stupid thing out once, I'm not doing it again".

Here's a case-in-point: I used to be E-Commerce Manager at a Credit Union in the DC area. As credit unions go, this was one of the biggest in the country, but still only about the size of a large community bank. Because it was a credit union, the only people they would lend money to were members of the credit union. Still, upper management insisted on using a loan application form which asked members their SSN, full name, full address, employer, etc. as if they were a walk-in customer applying right off the street. My problem with this approach was that we already had this information in our records. They were wasting roughly 5 minutes of a member's time asking information we already knew. A better approach would have been to eliminate some questions that would never change (i.e. SSN, DOB, name), eliminate other things already knew (because we also pulled their credit reports every month) and pre-populate some items that may have changed (address, employer) so that the fresh information needed was very little.

In another example, a dog rescue organization I volunteer for has a few members that want more questions added to their adoption application. One question recently suggested was to ask whether the applicant was over 18 or not. It seems like a sensible question, except that in the 6 years I've volunteered for them, I can count on one hand (out of the 90 applications per month) the number of instances that someone under 18 tried to adopt one of their dogs. They want to add this question to avoid the .06% of applicants who may be under 18 years old. It makes no sense.

I think the first step, then, is to really get to the bottom of what is truly necessary for that form. In most cases, I find that the longer the form, the less necessary some of the questions are.

Still, sometimes long forms can't be avoided. IMO, separating a long form into multiple pages is a good idea on the surface, but overall unnecessary and fraught with other problems. I think of multi-page forms the same way I do frames: they're a great idea and do have some benefits, but the same benefits can be had without the problems that come along with them. The major problem with multi-page forms is that it takes control away from the user and it leaves the user blind in terms of knowing where they are in the process and what else is ahead.

In terms of taking control away from the user, this is actually more of a big deal than it seems. Psychologically, this sort of "wizard-like" interaction switches the computer from being the tool of the user to the user being the tool of the computer and generally people don't like it.

Bigger than that is, as I've said, not knowing where they are in the process. It is vitally important, if you use a multi-page form, that you give users a very real and accurate idea of where they are in the process, where they have been, and what is left ahead for them. I remember seeing a loan application once that had these attractive icons at the top of each page: (1) (2) (3) (4), which would change color as the user progressed. And so when the user arrived there at the first page, they thought they were on page 1 of 4, but that wasn't the case. The form was actually about 10 pages separated into the following sections - (1) Introduction & Directions, (2) Personal Information, (3) Financial Information, (4) Review & Submit. As users progressed through the application, they got more and more frustrated by the length of it and adding to that frustration was the fact that as they progressed through the form the positional feedback didn't match. When they went to the 3rd page, they expected the "3" to change color. (It was kind of weird, because "1" matched the first page, and "2" matched the second page, but "3" was actually page 7 or so).

In addition to good positional feedback, a multi-page form means you need to do a lot more complicated programming to try to maintain state. Users expect that in a multi-page form they can not only move forward in the form but backward as well. You will need to be able to repopulate fields they've already filled in when they go back a page.

Validation is another concern. You will need to validate on a page-by-page basis. Do not attempt to validate a field on page 4 that the user filled in on page 2.

All-in-all, I say multi-page forms are a bad idea. There is a lot one can do to eliminate form fatigue on a long single page form through proper layout, effective feedback, and good visual design.

Here is a good article on form design: http://www.lukew.com/resources/articles/web_forms.html and a longer presentation from the same person: http://www.lukew.com/resources/articles/WebForms_LukeW.pdf (PDF).

Comments:

None.

Back to blog index

Add Your Comments:

Fields marked with * are required.
 

Contact Us to see how Web Access Strategies can help your organization.