I asked this question to my network -
How to bring simplicity in to the design of products – take complexity out and not the capabilities?
Here are a couple of interesting answers I got -
David Marshall wrote back -
It should all be driven by a proper elicitation process to define system requirements. This should result in an immediate protoyping session with the users without ever telling them what is technically possible. Find out what they need to be able to do their work effectively. Then build that and only that. Too often, designers build what they want to work on and with. The latest technological gizmos are cool. It is boring to keep reusing the tried and tested code. Except that users want only what makes their work easy. Anything that slows down the system’s performance or clutters up the GUI with redundant options is annoying and demotivating. It is hard enough to manage the transition to a new system. Giving the users the chance to take ownership of the design gives managers the best chance of a smooth transition. Thus, taking the designers out of the design is the best way to achieve simplicity.
Shantanu Sengupta says -
1st step – Forget you’re designing!!! Think you’re solving a problem!
2nd step – Once a solution is found, don’t stop… look for more solutions – at least 5 more!
3rd step – Apply logic and reason to see if these solutions are different and addresses the problem fully
4th step – If yes, see if they’re simple enough for applying in reality

In my experience, complexity is irreducible – problem spaces and solutions spaces both contain a mostly unchangeable amount of complexity. (Like a liquid, they are very resistant to compression).
I agree with the previous comments that the gathering of requirements must be design and technology neutral. Once the requirements are known, the trick of great design is how to empower the user while minimizing their exposure to the total complexity of the solution. This is the act of “partitioning complexity” through design.
Short-term economics, impatience and intellectual laziness tend to produce designs that painfully expose a greater portion of the solution complexity to the user than they should. Great designs expose a minimal amount of underlying complexity (the iPod and Google.com come to mind as obvious examples).
(This challenge is more about design excellence than tools, by the way. Every 5 years or so, a new tool or technique lays claim to really “simplifying” software product design and development. Anyone remember 4GLs and the “end of programming”?)