In the book, we talk about 'forms as a conversation' - thinking about a form as a series of questions asked by your organisation and answered by the user, and how those questions and answers flow better if they are constructed as a good conversation.
Define your terms - and offer help
Sometimes what seems like a perfectly straightforward question really isn't easy when you get to it.
Example: here's an academic trying to fill in a grant request form:
"Ah, now I have to list my current teaching. Fair enough. Make a list of current lecture courses. "Hours per week?" And what on earth does that mean? Official contact hours? Contact hours plus preparation time? Contact hours plus preparation time plus time going to grad seminars that aren't exactly duties but it would be a Very Bad Thing if no lecturers turned up to? Contact hours plus preparation time plus grad seminar time and background reading to be able to talk informally to various grads? Where do "teaching" hours stop? Who is to say? I press "Help". Which doesn't give any clue at all". Peter Smith on Logic Matters: Fools, damned fools, and the designers of online forms.
Use familiar words in familiar ways
The Local Government Association in the UK recently published a list of jargon words to be avoided - and their translations into more familiar langauge.
Controlled languages can be a useful, if drastic, way of restricting the vocabulary and grammar of your questions and instructions to a sub-set that is more widely understood than 'natural' lanuage. Uwe Muegge writes regularly on controlled languages .
David Hamill's post Preventing issues on web forms is really about the language of the form, avoiding technical terms like 'mandatory' and instead using everyday language like 'required'.
In Norwegian: Språkrådet, the Norwegian Ministry of Culture's Language Council, has a free online book Klarspråk til web (pdf) that explains how to write in plain Norwegian and includes a chapter on forms.
Look at the details of the flow
Users who are happily working through a form don't look ahead; they deal with each question, one at a time.
David Hamill's article How does your web form flow? looks at the specifics of how a failure to consider the flow can create difficulties for your users.