WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Can we prevent "form fatigue"? (Long response. Sorry!)

for

From: Karl Groves
Date: Aug 9, 2007 7:50AM

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 we 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 applying right off the street. We already had
this information in our records though. 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 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 keeps trying
to have 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 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


Karl L. Groves
User-Centered Design, Inc.
Office: 703-729-0998
Mobile: 443-889-8763
E-Mail: <EMAIL REMOVED>
Web: http://www.user-centereddesign.com


>