>I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usab

>I find we get a much better result when building requirements based off the customer's pain rather than just giving them what they want. It helps maintain usability by avoiding confusion over additional features and functions. Exactly. The starting question that you ask the customer shouldn't be "What do you want?". That is far too open ended, and the end result is that you'll get a solution to a perceived problem instead of an actual, workable solution. It's not the client's job to solve their problems. It's your job, otherwise they wouldn't be contracting you to do it. The proper question is, basically, "What problems do you want us to solve right now?". You want to start with the problems that the client actually has, instead of the problems that they are anticipating. This helps keep the client focused on their current issues, rather than problems that either don't exist, or may exist in the future(but don't right now).