Which is what makes analysis so important even though it's (usually) so overlooked. Put the right people in a room together with all of their paperwork (actual, not samples) and keep asking questions until everyone agrees THAT's how it works. Feed them if you must, but nobody leaves the room until we all agree. Then go to the office, warehouse, showroom, factory floor, or whereever and verify it.
It doesn't matter how well you can code or how fast you can code if you're not writing the right program.
I think you can have incredibly complex software with an intuitive interface. I don't doubt the author agrees, but I wanted to make that point first.
The clearest visceral experience of that valuable lesson came from playing through the 'commentary' track of Valve's _Portal_. The designers really understood how to teach the user the rules of the game without saying, "Here are the rules of the game in 28 pages of color photos and tiny text." Listening to their commentary made me start asking questions as I design, too.
But shortly thereafter, I came to a more profound realization: Valve's so successful in their design mechanism because they never change the rules of the game. So often, whether in games or in applications, the 'rules' change from one iteration of the software to the next. This creates bad code, bad maintainability, and a bad end-user experience.
(Oh, and: I sometimes wonder if our company began it's $10 million ERP "as an indirect way to force this review [of business processes].")