One lesson that I have learned working "in the industry", and am still learning it seems, is never to take the user literally. Very often we, as programmers, hear, either directly from the users or indirectly through designers and/or salesmen, what the users want, and well we should. There is, however, a fountain of evil in taking all of their statements at face value and implementing them directly into the software. In my own travels, for example, I had built a tracking system for a client. Included in this tracking system was user management and the client asked for a way to delete users from the system. Now, like any half-way civilized system, the user IDs were used to track the user's activities through the system, not the name so doing as the user technically asked (deleting out the users) would have been ruinous on the archived data, which still needed to work properly. Lest someone think me completely insane, users could be deactivated from the system in the original design. Once deactivated, the name would still show up under user management (so that it could be enabled once again, if need be), but would not be available for anything else (ie. new activities could not be performed under that name).
An explanation of the design decision did not suffice. So, I slapped a button up with the word "delete" on it, removed "deactivation", and made it so that "disabled" users did not show up under user management. After this was done, the user was satisfied. Bear in mind, all that really changed was adding a magic button that said "delete" on it, but the action performed was the same. Yet the customer was happy. The moral here is not that the user is stupid for not noticing or that the user should care about how the changes are implemented, but that you don't implement what the user wants in the literal sense. Rather, you give them the appearance of what they want.
To some, this may not exactly seem like a ground-breaking revelation. However, I have seen many systems, including some of those where I work now, in which the user's word was taken at face value and implemented as stated under the hood. The easiest example I can give, without really giving details, is one where the users said they wanted two systems that were completely separate. Yet, their requirements made it clear that these two things were not meant to be entirely separate at all. The coders who implemented the design followed the users' demands literally, under the hood. Meanwhile, as we continue to extend and maintain, life is being made increasingly difficult because of a technical decision based on the users' "wisdom".
A "real-world" caveat is in order here: implement the appearance, but not the technically correct, of what the user wants, but don't tell them that the decision was ever made, let alone that you didn't do it their way. The reactions to such news will vary, from chewing your ear off with an explanation of why they are absolutely correct to an outburst of anger, but it will never be pleasant.
Just some advice from someone who has hit this and seen it hit a few times. Frankly, I think it is more polemic a problem in either contract work or developing software for use within a company where the users get a more direct say in the process. In some ways, this is a good thing, as the potential is greater for the users to get what they genuinely need, but when unqualified personnel start dictating technical decisions, you get a classic Dilbert scenario.