Sounds nicely politically correct, however, what do you do when the users themselves don't know quite what they want? I run into this a lot - they have a vague idea of what they'd like to achieve, but very little in the way of concrete plans. At some point, pre-production meetings with the users start becoming a rehash of previously stated positions, and no further progress is made in understanding anything. I then create my best guess of what they hope for, and let them start using it. No matter how carefully I follow any plans, there's always loads of things that nobody realized up front, or weren't able to articulate in any comprehensible fashion. If I were to try this method, I would wind up doing much more pointless work, because my documentation of the (yet) unseen interface wouldn't fit the end product anyway.

Creating the app first at least lets me write the documentation only once, and often not at all, because in the process of tuning it, I can build in enough pop-up hints, help screens, tooltips and descriptive captions, based on the users' reactions, that I often don't have to write anything - the end-result app is clear and intuitive enough that new users can start to be effective in it with only a minimum of instruction from a colleague.

Doing it the way recommended in this post would lead to a lot of wasted time and effort, creating documentation that would not only never get read, but of something that never even existed, and never will. I can think of much better uses for my time.