Getting good design input – whether it be for a tangible ‘thing’ such as a PDA or a less tangible ‘thing’ such as a software concept – is very important. We need to think about what that ‘thing’ needs to achieve (the objectives) and what constraints need to be overcome to do that. Design is our way of getting from objective to result. And, in a nutshell, it’s the hardest bit to get right!

I blog about this sort of thing from a mainly software perspective – please do come visit at http://softwareprototyping.net – and it won’t come as much of a surprise from that URL that I am a firm believer in the power of using interactive prototypes to help not only try out different design ideas and concepts, but also to feed back into the requirements gathering process by taking those prototypes as the basis for constructive discussion over whether, in fact, the requirements/objectives were correct in the first place.

It’s a fascinating way of working and its not terribly difficult to reduce the risk of failure dramatically by following a few iterations of a carefully organised prototype:feedback:refine cycle:

Bizarrely enough, despite solid results and easily recovering the costs of working in this way through subsequent savings, it’s strangely over-looked in a majority of software developments – which is a shame, and something my company aims to change (and make a solid business in doing so).

Kind regards,

John

I need to read this book!
:]

Also, I owe you an email. Haven’t forgotten :)

I promise.