thoughtfulCooper's solution is "interaction design". This uses "personas"--fictional users designed to represent the customers--to drive design choices. The designers concentrate on minimizing "cognitive friction" so using the software can become an effortless step in reaching the user's goals. For example, Cooper designed an airline entertainment system to have an iPod-like wheel so non-techie users could quickly intuit how to pick a movie. This predates the iPod, which illustrates a problem with the book--many of the ideas in it are already being put into practice. Cooper devotes one rant to how email software doesn't group related messages into threads. Possibly it inspired the developers of Gmail, which does exactly that.
His biggest point is one that applies to more than software development. A full top-level design must be completed before detailed coding starts or it'll be impossible to go back and fix any problems that are discovered (sure, the project manager could throw out all the work done to date and start over, if he didn't want to work again). This requires giving a small team the time to work through all the issues involved before starting the full development process. In the aerospace world this is often called the "system architecture" and is done as a separate contract, with full production not being approved until the architecture has been rigorously reviewed.
As an example of why that's needed, the startup I once worked at had arranged for a major aerospace firm to do the detail design of its rocketplane concept. $10,000,000 later they'd have a set of blueprints they could use to manufacture the vehicle. This fell through, which was a damn good thing. The concept was flawed. The "2.0" rocketplane design had a vertical-center-of-gravity issue which made it uncontrollable during ascent. The company would have raised a pile of money and wasted it on a worthless design, or worse, gotten even more to produce worthless hardware. Instead we kept working on the architecture until we had a concept worth taking to the next level. (Then the customer went bankrupt. So it goes.)
Doing architecture before details is a hard concept for some people to grasp. I was once talking to a venture capitalist who thought the up front work didn't matter since it was "only a fraction of the total technical effort." He's not alone. Most technical projects have pressure on them to produce quick results and ramping up to the full team producing detail work is the easiest way to answer that. The problem is you can't modify your way out of a completely broken architecture, and once you've spent your money it's too late to start over.
I've been pushing this book on software people whenever I've had the chance.
rlseiver decided it was such an accurate take that he promptly retired, which wasn't the result I was looking for, but I'm happy that the kiddies get to see more of him. Some Lockheed IT people drafted me for usability testing of an updated internal website. I told them they'd be insane to focus their design on me rather than one of the computer-shy union guys. And most recently I've offered a copy to the LJ development team. So here's hoping for some more progress toward good software for us all. 