How to deal with large webforms

When developing/designing business applications you might face long (or large) webforms. You can have tens of fields and it might be a real mess. I know that it's often the client's request (you know, they want the forms to look exactly like paper documents - the famous one), but, whatever the reason, you have to think about user experience.

As you can see on the image above there are too many fields on the form. Imagine how what it's like for users to fill in the form. How 'easy' would it be to figure out validation messages? If you think this is not a common scenario, let me reassure you. I've dealt with tens of such applications in the past several years.

The key is to organize the form a little bit and group the fields into meaningful groups. But this might not be as easy as it sounds. It is not be enough to do ad-hoc regrouping. You would have to understand the business rules and processes that need to be accomplished by filling the form; is it a simple one like signup process or a more complicated one like the process of opening a bank account.

There are several UI patterns that can be used for this purpose, and here are four of them that can help you:

1. Split form accros tabs

This might not be the perfect solution but surely will help reorganize a form. Basically, Tabs pattern is very simple but you have to be careful when grouping fields. As I said before, they have to be grouped according to business rules or user's preferences. If it's possible, try to talk with users who will use the system. That will help you understand how the real process works and how to design the forms. The downside (which is also an advantage) of this approach is that users won't be able to see the entire form at once.

2. Split form to collapsible/expandable regions

This one is similar to tabs. Although collapsible panels pattern is used mainly for navigation, my opinion is that it can be used here as well. The difference between tabs and this pattern is that a user can see the entire form if they expand all the regions.

3. Split the process of filling a form into several steps

If you have business processes that support this, you should definitively use this pattern. You can divide the process of filling a form into several steps. This will not only make filling all the necessary data easier but will also guide the user through the entire process. You can use either Steps Left or a Wizard pattern, depending on business rules.

According to ui-patterns.com, these are the cases when Steps Left pattern can be used:

Use when the user is about to go through a longer process of giving data to the system that is longer than two screens (steps).
Use when the steps of a process is so long that the user might get the impression that it will go on forever without the guidance of steps.
Do not use when there is only 1 or 2 steps in submitting data to the website.
Do not use when the process of filling out data is easy foreseeable.

And these when Wizard pattern can be used:

Use when the user needs to perform a task or a goal that dictates more than one step.
Use when the user needs to perform a complex task consisting of several dependable sub-tasks.
Use when the user needs to input complex data into a system that is easier for the user to comprehend parting the process into multiple steps.
Use when the user needs guidance: the user wants to achieve an overall goal, but may not be familiar in the steps needed to reach the goal.
Use when the steps needed to reach a final goal may vary due to decisions made in previous stages.
Use when the user lacks necessary domain knowledge.
Use when the user must complete steps in a specific sequence.

Recommended readings:

Do you know any other ways to make large forms easier to use?

More articles in Blog archive or elsewhere

Patternhead 18 Feb 2009 #

Great article.

Web forms in general can be a real pain in the ass for designers. Splitting a huge form into multiple steps makes sense. Convincing the client is another story.

Ol.keene 18 Feb 2009 #

collapsible/expandable regions + it validation on each step, so that makes much easy to display an errors

Jon Bergan 18 Feb 2009 #

Loving it!

I'm currently working on some larger web forms at the moment so this gives me something to think about.

For the most part though, I feel that the Steps Left/Wizard pattern is usually the best if the form is a little lengthy. Its just so much more user friendly and does act as a great guide for the end-user.

Great post once again!

Rgds,
JB

Tom Medhurst 18 Feb 2009 #

My favourite way of breaking up large web forms is to style the fields in a semantical way...

Say you need to enter a date.. don't use a plain text-box; instead use css to create something which looks like a calendar.. First name and last name can go on the same line etc..

Another example is an address... Create a section which is styled like an envelope and organise the address input controls in the way you would usually see on an envelope. The person inputting the details will immediately recognise the format and knows what to write where. (Plus it'll look cool!!)

Once you break the appearance of plain textboxes and get each section to look semantical, when visitors look at it, they can easily break up the form in their mind, making it more digestible to them.

Also using radio-buttons, checkboxes, combo-boxes, textboxes with auto-complete wherever possible so the user can complete the form in the quickest possible time and the fewest possible key-strokes.

Davide Espertini 18 Feb 2009 #

Great article.
validation on each step, so that makes much easy to display an errors

Janko 18 Feb 2009 #

Patternhead: Yes, convincing clients is the hardest part

Ol.keene: Validation is absolutely necessary.

Jon Bergan, Davide: Thanks.

Tom: Yes, it's good way to show/group fields semantically. Still, you'd have to enable users to do one task at the time - by breaking form into tabs, steps or whatever.

Anthony Grace 18 Feb 2009 #

If a client insists on something as stupid as this, then I either persuade the client to follow my advice or I walk away (with my half of the deposit). Nobody wants to fill out a form this long online. Plain and simple

pete in atlanta 18 Feb 2009 #

To wizard or not to wizard?
Sometimes this is an easy question and sometimes it’s not. I’m an application designer and live and love forms!
Here’s some of the things that run through my mind that help me make a decision:
1)  What is the purpose of the form? Is this something that is only going to be filled out by a single user once or are they going to be doing this 100 times a day?
2)  What is the users level of knowledge? Is this something that a general internet user is going to be filling out or is this part of a larger application that trained employees / customers are going to be using multiple times a day.
3)  Are there field level dependencies / sequencing that modify the form? Meaning does the answer to a group of questions totally change the remaining fields in the form.

When to wizard:
If the user is not a trained user (meaning they don’t use this form all day, every day).
If the form is a single use type that is pretty long, a wizard is usually the smart choice.  If I don’t use this form every day, I might need additional help / instruction for each section.
If a user makes a mistake on one of the sections, I can display error messaging for that section to help them remedy it and move on.
If the form is dynamic and the answers to questions changes the form farther down the path, this is seamless to the user and easily adjusted for.

Important things to include consider in a wizard:
1)  Set expectations. How long will it take me to fill the form out? What information should I have handy before I begin?
2)  Show steps / progress. A wizard should have clearly defined and visible steps. This helps the user know where they are, what they’ve completed and what they have left.
3)  Depending upon what the form is used for, have a review page that displays all the information they’ve entered before they hit that “Finished” button. Give them a quick way to get back to edit a section if they need to make a change and DON’T make them walk through the additional steps again (like if you have a 4 page wizard and they go back to edit page 1) * unless the change they made on page 1 forces them to change their answer on a different page.
4)  How is the data saved? Can I get half way through the form and come back and finish later?

When not to wizard:
When the form is used by experienced / trained users repeatedly.
Time is money. When we’re after speed, wizards don’t usually work. Experienced users are less efficient in a wizard format than a single page format.
Ya, it’s less glamorous but you can still be very creative in your layout and the tools you provide to users. Action keys, field / label layout, changes and automation play a huge role when it’s a race to save button.

Happy forming,
-P

Janko 19 Feb 2009 #

Anthony: It's not just for online forms. You might be developing an intranet application as well. Applying for the credit, for example, is one of the cases when you just need to fill a lot of data.

pete in atlanta: Very nice observation and addition to the article, thanks

Web Design Manchester 19 Feb 2009 #

Another great article thanks!

I'm actually in the middle of recreating a large application form for a client and was thinking of separating it into steps - I'm just still a little worried about people dropping out halfway through the application process.

I suppose it's unavoidable when trying to get lots of detailed information from a user, and laying out the form in steps is more likely to keep them going than to present them with all the fields in one big chunk.

Anders Toxboe 19 Feb 2009 #

Thank you for the gracious linking!

I'm thinking that a mere grouping of elements into groups of fields that relate to each other is the first step. Adding module tabs or collapsible/expandable functionality will in many cases do more harm than good. In the same way, turning a form into a wizard or breaking it up into steps is also a decision that should be thought out carefully.

Larry 19 Feb 2009 #

Janko until you posted that, I agreed with Anthony 100%. This is some good advice for any Internet applications you are creating for customers. Thanks for the great post.

Web Design Manchester: It really depends on the case. If user, for example, wants to get a credit for a car, they would probably have to fill a bunch of data.

Anders: I agree, all of these decisions have to be thought out carefully, and they depend on business rules, customer requests, users, etc.

Larry: Thanks

Neil 19 Feb 2009 #

That form reminds me of an app I worked on last year, a grid with 60 or 70 text boxes EACH with a JavaScript event to perform some calculations based on values in other text boxes. That was a great day. Unfortunately, I could not use tabs, accordions etc

Clustr 20 Feb 2009 #

Gotta be careful with #3 usability and conversion testing have shown that multiple pages can significantly lower conversion rates and increase bounce outs. One rule I always try to follow is to get as little information on the front side as possible and as much as possible on the backside. Example - A lot of shopping carts ask for account creation, addresses, phone numbers, etc before checkout is even complete. Really what you need a lot of times is the CC number and security number from the card. After checkout you then ask them to provide shipping infos for the order they just placed and encourage them to create an account to make ordering again even easier.

Collect just enough information to satisfy business requirements and then let the user choose when they give you the rest of their information.

Mepho 20 Feb 2009 #

Another solution for large forms is to reduce the labels and even cut out some of the form elements. Most people use half the elements for data collection and only view it once a full blue moon.

Reducing labels will increase room and spacing. What i mean is fill the form in with "Name" and then on focus remove it (done with AJAX).

Nice post~

-justin

Egil Hansen 20 Feb 2009 #

Hi Janko

Its always a pleasure to read your postings. Deciding how big your form is going to be is certainly a very important usability concern.

Currently I am working on an internal web application for tracking work we do with our clients. In that context, I do not want our users to have to move through 2-3 "wizard" steps, since they will know the form and use it daily, and in this case it will just slow them down.

One thing I would love to get your input on (if I may go a bit off topic) is how to probably layout complex forms over different browsers. For some reason it is hard to get form input fields (input, textarea, select dropdowns, etc.) to look and align up the same across browsers. Do you have any tips that you can share with us?

Regards, Egil.

Andrew Brooke 20 Feb 2009 #

Great article. I am currently creating a form that resembles the long "paper form". I have found that hiding as much of the optional form elements as possible and only displaying them when needed helps. I also remove questions that are not relevant based on a previous answers.

Tabs are a great way to avoid scaring the user with a long form and to give the user some indication of the number of steps required to complete the form.

My users are used to filling in the paper form and it is hoped that the new online form will be quicker and will reduce the amount of bad completed forms. I intend to use all the facilities available, tabs, date pickers, validation, show/hide, autocomplete and good styling to make the form a joy to complete.

Janko 20 Feb 2009 #

Neil: Yes, sometimes you have a lot of limitation, unfortunately.

Clustr: Agree, you gave a good example.

Mepho: It really depends from case to case, but I believe you'd probably need labels most of the time

Egil: Thanks ;) I agree that sometimes it's better to leave all the fields on one page. In your case it seems to be a good choice. For the styling, I can only give you some general advice and that is to design for standard compliant browsers and then make a fixes for IE or other.

Andrew: It's always a challenge to move from paper forms to digital. Good luck!

Janko: I completely ignore anything below IE8, but things still look different between Firefox and Chrome. Especially when it comes to the width and height of the form fields, there are small variations of 1-2 px which really irritates the eyes.

Structural Steel Fabricators New York 20 Feb 2009 #

Really it is nice post and thanks for sharing it.

Anthony Grace 22 Feb 2009 #

Janko: Good point about the intended purpose of the form. Very interesting post, love reading your blog

Clustr: I really like your thinking about handling customers on an E-Commerce site.

Janko 23 Feb 2009 #

Egil: Have you tried with custom padding/borders? I guess you have, just to check out.

Anthony: Thanks

Markdvl 25 Feb 2009 #

Really interesting, I make so many form with many fields and the biggest problem is to place it in a sense.

Jason Bartholme 28 Feb 2009 #

Great post! I'm knee deep in a huge registration form that was originally 7 pages printed out. I have been using jQuery with hiding/showing regions based on input, but I need to break it into sections for data that is common to all registrants.

This will give me some guidance.

Julio Flores 14 Apr 2009 #

thx for the usefull information , cheers

Nevin Longardner 23 Sep 2009 #

The business applications I've worked on for the past 20+ years have always had complex screens, and now web forms, at their core.  At our company, there always seems to be a delicate balance between "Too many screens!" vs. "Scrolling is bad!".

Tabs can be problematic for data capture because they put a memory burden on the user to navigate to them.  Certainly putting required information on a second or third tab should be frowned upon because the user could get validation errors for fields he never even saw in the UI.

<fieldset> offers a nice way to label and group a set of related fields.  The Gestalt principle is key for organizing complex forms, IMHO.  Colors, borders and white space can all be used to good effect for presenting groups of input fields and/or data.

While we haven't used wizards per se, the concept of breaking large complex tasks into smaller chunks is at the core of wizards. If a task can be completed in shorter time with more accuracy by breaking up large complex pages into multiple, simpler pages, then I think you have a solid argument for that type of design.

chris nürnberg 19 Oct 2009 #

i use joomla with chronoforms to do the job and i had the same wishes from customers (we want paper looking forms) like described here. Thanx for the post, i will use the splitting in tabs more often in future!