Decide if your form is really necessary
People don't like form. Just showing them a form can be a turnoff.
Are you sure you really need a form? Can you get the data some other way, use data that you already have, or find some other work-around?
Luke Wroblewski's article Killing sign-up forms gives some examples of how to avoid one type of form.
Design your form to reflect your users' goals
Nearly all forms exist because a user wants to do something, and needs to supply data to achieve that. Tom Mollerus has a great summary checklist on usable forms that focuses on designing your form so that you help your users to meet their goals.
In her piece on Search Engine Land, Web site usability for improving online forms, Kim Krause Smith explains how forms work better if they reflect what users want to do - and also, if you're really careful about thinking through what you want to achieve. Her article is full of really useful tips, such as this one:
"15. Offer a choice for means of contact. Don’t require both an email and phone number. This is an abandonment issue. Ask “how would you like us to contact you?” and let them decide. If you must require a phone number, ask “when would be a good time to call you?”"
Think about how your form fits into the overall flow
What was your user doing before getting to your form, and what will happen next? It's worth thinking about that both screen-by-screen (or document-by-document for a paper form) and also task-by-task.
For example, Harry Brignull reviewed Flattr's sign-up process. Flattr is meant to be a way of showing your appreciation for good content on the web by making small donations. If you look at each page in their sign-up process on its own, they aren't fabulous but they're not horrible either. But if you think about the succession of actions, the design emphasis placed on those actions, and the mismatches between them and the users' goals task-by-task, then you can see that there are all sorts of problems that might explain why Flattr hadn't really taken off by January 2011 when Harry wrote this piece. Example: there are far more readers than writers, but the first page in the process empahises the writers' task over the readers' task.
Another example: Gerry McGovern, writing about Effective web lead generation, quotes a case study that generated 5 times as many completed forms by asking for sign-up after delivering some valuable web content rather than before.
Show trust by making fields optional
In the book, we talk a lot about Dillman's 'Social Exchange Theory'. We interpret this as a balance between trust, effort and reward: people are more likely to answer if they trust you, and they balance the amount of effort the form is likely to take against the perceived reward that it offers.
One way that you can show trust is to make your questions optional. That shows that you trust the users to provide sensible information. An example from Anne Holland's "Which Test One": Required vs. All-optinal form fields.
Do you still need those answers?
Many times, a question is put on a form to fulfil a current need. Then time passes, the need passes, but the question stays there.
Example: an 11-question web contact form that asked for unnecessary details such as street address and fax number. Reducing the form to the four most important questions resulted in sharply increased conversion.
You can lose a customer over a detail
Some forms are a mere detail in an overall process. For example, think about the 'unsubscribe' form on a typical marketing list. Chances are that this hasn't been the main focus of your development effort - and nor should it be, because if that bit works well and the rest is rubbish, then so what?
Only - it is a detail that is worth getting right. And in some jurisdictions, it may be illegal to send marketing emails without an appropriate unsubscribe process.
Each extra question adds burden to the form
It may seem like just another innocuous question, but each extra question lengthens your form and makes it less appealing to fill out. Bored, annoyed users are less willing to finish the form, and less likely to take time to think of accurate answers.
For example, the question How did you hear about us? is often seen on registration and other forms. But it annoys users because often they can't remember how they heard about your organisation, especially if you're a well-known brand.
Even a seemingly innocuous question such as asking for a title ("Mr, Mrs, Ms, Ms") can create a distracting internal dialogue in the user's head. Some people can't understand why you need a title. Others might have feminist critique about the need for women to declare something about themselves, as in Deborah Tannen's article Wears Jump Suit. Sensible Shoes. Uses Husband's Last Name. If you need to translate the form, then you'll run into difficulties in languages that don't have a direct translation for the different titles.
Those 'small detail' extra fields can also really hurt your overall conversions. One innocuous field on a signup form lowered conversions by 17%.
Use a question protocol to decide whether your form fields are necessary
In the book, we talk about investigating how your organisation will use the answers you gather. One suggestion is to use a 'question protocol'.
Caroline wrote about question protocols and some suggestions for how to use them in this piece on UXmatters.com: The question protocol: How to make sure every form field is necessary.