Design Thinking

The Multidisciplinarian has a post on 'design thinking'.

It covers a lot of good ground, including having a stab at the 'fadism' that pollutes business discourse. A short time ago...a few years...'design thinking' was the beaut new thing to boost the revenue of consulting firms who are ever eager for solutions to their declining revenue opportunities as the last beaut thing fails to deliver. It often fails to deliver because it fails to deal with the interests of the customer, and prefers to pander to the needs of management, but that's another story.

In the building industry I meet and work with architects and engineers all the time, so encounter 'design thinking' and design talking, as well as design doing also all the time.

There are probably many varieties of 'design thinking' but the factor that I think may connect them all is the discursive use of resources to meet the requirements that will give life to an opportunity.

Note I avoided the word 'problem' and the phrase 'problem-solving'. I doubt that design is fundamentally a problem solving exercise. To characterise it as such is trivial, although architect-instructors at university use it all the time:

Practicing architect: "I'm designing a library."
Academic architect: "What's the problem?"
Librarian: "The problem is that there is no library!"

See? It gets us nowhere.

Rather there's a need and an opportunity.

Design occurs when resources are marshalled to meet the need. It entails meeting a set of criteria that may be changed as they are explored and challenged during the design process. It entails varying the 'power' of criteria as the work proceeds. This might include solving problems by employing tradeoffs and compromises, but that's on the way, not the object. The object is to realise socially useful shelter that meets the need, speaking at the broadest.

As the Multidisciplinarian points out that 'design thinking' is not magic, but usually proceeds when there is no obvious means of meeting a need or taking an opportunity, or realising a return. A parametric envelope is created by user requirements. As the response to the requirement set is developed, the parametric envelope, and the options available close in on a result. At bottom there is probably no strict algorithim to do this, although architects and engineers do have algorithmic-like behaviour as they develop their designs.

That's part of the craft of design in the building industry.