E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Cliff Tyllick
Date: Wed, Aug 08 2007 6:00PM
Subject: Can we prevent "form fatigue"?
No previous message | Next message →

I am reviewing an application in development that requires dozens of
fields to be completed. (We have lots of information to gather, so there
is no getting around the sheer number of fields.) We're trying to figure
out where to try to fit between these two extremes:
---an infinite number of one-field pages
---one page with an infinite number of fields

(I exaggerate only slightly.)

Is there good research out there to give a sense of how to balance
"many pages of few fields" and "few pages of many fields"? (Each "page"
will end with a "Done" button or similar interface to check and verify
the data received so far.)


Cliff Tyllick
Web development coordinator
Agency Communications Division
Texas Commission on Environmental Quality
512/239-4516
= EMAIL ADDRESS REMOVED =

From: Gareth Dart
Date: Thu, Aug 09 2007 2:40AM
Subject: Re: Can we prevent "form fatigue"?
← Previous message | Next message →

No reources to suggest, unfortunately, but a little bit of personal
experience...

Having had to design something similar in the past, after I did a few
working examples, I came to the conclusion that it was far better to
have a fewer number of pages, even if they appeared somewhat crowded.
Even having coded the examples myself, I quickly found it tiresome to
have to plough through lots of pages - it was far better to go through
only a few pages of many fields. There was a clear parallel with the
paper world - if you handed someone a form of a hundred pages, with
perhaps only three or four questions on each page, they would think it
very peculiar indeed.

An opinion now: usability isn't about making pages absolutely usable no
matter what, it's about making pages as usable as possible within the
constraints of the function they are expected to carry out.

Another related approach is to have people download and then complete a
blank excel spreadsheet, which they then upload back to the site for
checking. This is a valid alternative in cases where there is a lot of
complex data to be returned.

HTH,

Gareth

From: Tim Beadle
Date: Thu, Aug 09 2007 2:50AM
Subject: Re: Can we prevent "form fatigue"?
← Previous message | Next message →

On 09/08/07, Gareth Dart < = EMAIL ADDRESS REMOVED = > wrote:
> No reources to suggest, unfortunately, but a little bit of personal
> experience...

I would add that it's useful (if there are long form-filling processes
to be conducted) to enable the user to save (or the application to
auto-save) the state of a partially-completed form.

There probably aren't many examples like this (tax returns, perhaps?),
and I hope no-one is making apps where the sessions time out during
these kinds of processes these days. Tabbed browsing means that
people's behaviour has changed - they're not giving your site or app
their 100% attention, and may be switching between several tasks.

Tim

From: Karl Groves
Date: Thu, Aug 09 2007 7:50AM
Subject: Re: Can we prevent "form fatigue"? (Long response. Sorry!)
← Previous message | No next message

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 ADDRESS REMOVED =
Web: http://www.user-centereddesign.com


>