There is also another step - define what you want. Targets are important. Preferably, define targets in real (really real) world terms. This is difficult, but

There is also another step - define what you want. Targets are important. Preferably, define targets in real (really real) world terms. This is difficult, but "a user should reasonably be able to complete this macro-process in 5 minutes" is the kind of target. I've seen so many specs that demand "millisecond response time" for the application. Or something ludicrous. (Requirements for business continuity and downtime/etc are usually similarly crazy/unqualified). When one consultancy I know got a similar requirement forced down their throat contractually -- they simply changed the application so that a process that was a few pages, was now dozens. Much shorter delays! The fact is that the user wouldn't even blink at a several-second delay when submitting (it was a big operation, so you'd expect a delay). The whole process was longer and more cumbersome - they'd optimised the wrong thing entirely. It's an extreme example I know -- But the upshot is that the target was wrong -- It's not just the people writing the specs. In a lot of places, it's still rare for developers to sit down with actual users. This always seemed crazy to me (half the time it was because companies are worried that developers will go "hey yeah sure, I can implement that in an hour!" -- which does admittedly sometimes happen). So you're absolutely right! :) Profile, Profile, Profile -- but don't forget to profile your users (imho do this first).