What's the Problem er... uh... Product?

"What sort of Products do you design?"

About three years ago I joined both of the Design Thinking groups on LinkedIn and began to participate in the conversations. It was very obvious from the outset that their conceptual frameworks were *very* different and that there was a large gap in perception about what Design Thinking is. That was a surprise as my context for DT was firmly rooted in what I'd been taught in the undergraduate Product Design Program at Stanford many years ago, before Dave Kelley even began calling the method design thinking.

I knew from my own experience that Product Designers were a bit of an odd duck in the highly silo'd American job market. I had struggled for many years with being neither fish nor fowl to the EE's ME's, CE's and CS graduates competing with me in the workplace. Even today, Product Design is viewed in many companies as pertaining to whatever product the company sells. Obviously, a Product Designer at Procter and Gamble does something different that a Product Designer at Apple. Or do they? Recently, Systems Engineering has been a more welcome partner as the deeper question of how to make extremely complex systems fit together has become more important.

So, it was with great interest that I recently came across the Masters Thesis of Jonathan Holmes which made reference to a review of a book by Gerhard Pahl and Wolfgang Beitz written in 1977.

In the third paragraph it states:

Wallace and Blessing lend some perspective to systematic design by noting two contrasting ways in which design can be approached. The systematic generation of solutions set out by Pahl and Beitz is a problem-orientated approach which is favored in central Europe. In contrast, in the UK and the USA, a more product-oriented approach is evident in which an initial product idea is continually elaborated during the design process.

I was already familiar with the writings of L. Bruce Archer an Harold vanDoren, which all but defined the fields of Industrial Design as taught in the 50's and 60's at least in England, so I was aware of this difference which manifested so strongly in the DT groups on LinkedIn.

Over the past two years there has been a significant increase in awareness of DT in industry. Once other colleges and universities besides Stanford began to offer courses and big names (IBM, P&G) began to advertise their adoption of DT methods, things really began to take off. I was still wondering if the current DT framework had become broad enough to overcome this product-problem dilemma.

Offenders for the Words

Wallace and Blessing explained that one of the problems had been translating Pahl and Beitz's book Konstruktionslehre, from German to English.  Konstruktion was translated as Design, but there was difficulty with the name of the second phase of the design process Entwerfen which was translated as Embodiment until an author named French suggested Embodiment of Schemes was a more accurate term.

A web search on Embodiment of Schemes turned up a definition of Embodiment Design:

The embodiment process is the bridge between the conceptual stage of the design process and the detail design stage. A more detailed analysis of the selected concepts is undertaken in the embodiment stage of the design process. Most recently, here in the US, I have seen the terms Concept, Preliminary and Detail used.

The main goal of the preliminary design phase is to refine concept sketches as a distinct stage in the design process by identifying the steps and rules employed. The input to the embodiment stage is often little more than an outline sketch and associated project controlling documentation such as Preliminary Design Specifications or design requirements. The output is a definitive scheme/drawing accompanied by documentation, such as calculations, required dimension and tolerances and suggested materials and manufacturing processes. 

 (Note: The author also wrote that the output from Embodiment Design includes appearance, shape, style and size, but materials and process details are not included in this stage.) 

"Embodiment design is not solely the achieving of technical solutions but also creating useful products, which satisfy and appeal to the users."

That reference to creating things which were useful and appealing to the users finally rung the bell although leaving the underlying issue of whether a "product" existed when the design process was begun unresolved.

Put another way, as a Design Thinker are you a problem solver or product designer. Is there even a difference?  The answer to that has its roots in part in where you were trained - which impacted how broadly you define product.

At the d.school Design Thinking has always been framed as a problem identification and resolution method which is embodiment agnostic - the solution may be a physical product or a process - but openly shifting DT's framework up a level by asking the question; What is/are the unfulfilled needs of the customer? by starting with Empathic Inquiry has been pivotal in the story.  

The idea that central Europe has a problem oriented approach and the US does products is interesting. If it is true, does that imply a difference in the cultural rational/emotional balance of the two methods? Do Central European designers more typically ask What is the problem? while Americans say; Here is a product!

Or like Alice's conversation with Humpty Dumpty, is there something altogether different going on in the background?