Users are crappy designers

This title is of course a bit abrupt on purpose.
What I mean is users are very often crappy "web applications" designers... still abrupt, but scoped ;). Though I'm not sure they would be good designers for any other type of application, but they are definitely used to using them a lot more.

Let's illustrate that.

In I.T. brand new projects are quite rare, therefore implying lots of rewriting from existing applications. As of brand new projects, they are often inspired by existing ones developed for the same system, or from a previous product built by the integrator.
A user, or "core-business" worker, has a tendency (and we all share this burden) not to change his habits. And former application is part of these habits, along with massive paper usage, attachments to emails, client-server applications (even though this last point is not really directly relevant to the user, its side-effects cripple today's web applications, as we'll see further in this post).

Gathering requirements

A real effort of will is necessary when gathering requirements to avoid asking any questions to the user about how he thinks the UI should look like. This will most likely not help you design your application in any way.

False approach to novelty

Adding a new face on an existing fat-client application by building a copy-cat web application is really a bad idea.
It may look cleaner (though this depends on taste, but web applications are a lot easier to style and to adapt visually than fat clients) though is not bringing any functional novelty, and often opposite to the all-powerful user's habits (keyboard shortcuts for example) without improving the tool in the aspects of the work the user has to do.

Real knowledge of the work flow

Still the user has his hands on the treasure of treasures: the definite requirements a.k.a. the work flow a.k.a. the part that is almost never in the requirements.
Of course I'm insisting on "almost", as in fact I've seen a lot of projects where it's almost too much detailed, to the point that it's really hard, for anybody trying to build a use-able tool out of it, not to get confused or to discuss for pointless hours about it.
Because, face it, users, or even somebody talking for them, are hard beasts to tame, and even harder to have around. In most cases they are your legendary beast, you'll only read about them in the magic books of basic requirements. In Software Eden (the one advocated by Agile practices) the user is always at hand and grants you with insightful help all the time.
Hey! Stop that dream for now! 'not talking about ideal situations there!

Real lies about the work flow

Users really know what they have to do and how, and at some point you may have a good grasp on it.
This is the time, you know, this time just the day before the official release, that it hits you abruptly on the forehead: Users' lies about his work flow.
In the requirements, during the demo, you'll face a real user or a simili-user that will act like a theoretically perfect user.
Let's face it though: Users are not perfect, and often will leave out things that are crucial in applications design, like timing, context, concurrent use of other applications...etc
These "lies" are not intentional, this is what people often call omissions, though when users are omitting things like the coffee break that makes it necessary to save forms before they are submitted in order to be able to work on them later on, or the fact that they will often have to work on behalf of some other user, or working offline, accessing the application through a PDA, being notified of anything important immediatly (with a very relative sense of immediatly standing from 1 sec. to 1/2 hour, to the infamously unprecise ASAP...).
All these questions should be brought up front, though are usually not part of the "noble" requirements.
One may argue that they should be and I cannot agree more.
Just keep in mind that users will have bad ideas on how it should be done, and which technology to use. They just know about their agenda, how to do their core-business, and have habits (which may include technology bits...).

So where do we go from here

Do never forget to ask the users about their habits.
In order to build on them for better functionalities, better tools.
In order to replace bad habits with better functionalities, better tools + training ;)

Do never forget to ask the users about their timing.
Because their minute-to-minute agenda will have a very important impact on the outcome.
Because you need to taylor the system to their agenda, even if they don't already know how.