I looked back over some of my older writing and realized that I had written about form design in three separate posts. These posts, while similar, contained different ideas and recommendations. Thus, I have decided to combine them here.
Keep things on a “need to know” basis
What information do you need to have the user enter? Let me restate that: What is the LEAST amount of information you need from a user? Keep in mind the different business cases and situations are a huge factor: You’ll need to ask a lot more questions from a user who is opening a bank account online than you would somebody who is buying a DVD from an electronic storefront. Even still, ask only what is necessary – and don’t add irrelevant questions that could frustrate the customer.
It’s not a paper form
This is an obvious point, but worth mentioning – a web form is NOT a paper form. Users have a lot more patience filling out a paper form than an on-line form, even if the goal of the application is exactly the same. I’ve done A/B user testing with paper vs. online forms and that lack of patience surfaced time and time again… even if the online form took a lot less time to fill out, people still expressed frustration. So don’t make the web form “look” like a paper form.
Split and chunk!
Split out any long form to multiple pages, and clearly label each form. “Chunk” like information (example: if you are asking a lot of personal information, put all those questions on one page and label it “personal information.”)
How to do this? Take all the form values you need to capture and group “like” elements through an affinity exercise, using sticky notes. If you can, have two or three different groups do it to provide different perspectives. Any fields that don’t naturally “fit” become candidates should be considered candidates for removal.
Tell the user how long it will take (and what you will be asking)
Tell the user before they start filling out the form how long it will take and what the information is used for (both points reduce abandon rates when used). Provide a subnav for a multi-screen form/process.
Identify what the information will be used for
One of the first things I would do is get a better understanding of is usage. What is the information entered going to be used for? A good sense of what is important and what is not will quickly come from that. This will help you take your first cut with all the data fields you are adding to the form.
What is the business and user goals?
What is the business driver behind the form? Is it to let users signup quickly? Is it to ensure that the right information is being captured? Is it to have as little “abandonment” as possible? Clarity around what the business AND the users wants is key to balance both groups’ needs.
Do you need a form at all?
Twitter, LinkedIn, Facebook, and Google (and many others) have open APIs that allows for “single sign on” – instead of filling out a form to open an account, you simply connect with one of these services. It allows for quick access and removes the need for a conventional “sign-up” form
Stagger the input
Finally, consider asking only the bare minimum, and “staggering” the user input to ask the information ONLY when it is needed in the full experience. Amazon does a great job with this technique, baby-stepping users through a potentially complicate process. Another idea: “pre-filling” fields with “intelligent default” values so that people can edit the information if it’s wrong instead of entering it from scratch.
Redesigning existing (and potentially long) forms
Often we are not designing a form, we are redesigning one that already exists. The first thing I would do, when looking at that, is question why it was long in the first place. Do you really NEED to ask all the questions that you are presenting? Is there any way you can remove several of the questions to simplify and streamline the form? Sometimes business rules and legal constraints may mean you HAVE to ask certain questions (such as the aforementioned online bank application form) but it’s always worth questioning and trying to reduce and simplify.
After you have reviewed and (hopefully) streamlined the form fields mock up the restructured data entry page in a way that you can test it, and take it to users – if you are redesigning a form that a company may be using internally, take the proposed redesign to the people at the company who used the old form. Having them actually USE a new version of a form will prompt a much different and frequently more specific feedback than looking at the information in an abstract way.