Methods in innovation design research: Developing the product

In this chapter, philosophical considerations will be used to investigate how each product development in some way is unique and yet a typology can be developed to get grips on the variation of design situations. It will be argued that different situations call for different methods and that the (often implicit) assumptions underlying each method largely determine where a method can be useful and where it will hamper by hiding relevant aspects of the situation rather than doing justice to them. Many textbooks on product development treat methods as standard cookbook recipes that can be applied in almost any situation. In this chapter, a more nuanced picture of methods will be presented.

Introduction

In design methodology, initially there was optimism in identifying general design methods that would work for each and every design process (Cross 1993). Still, textbooks for design education have flowcharts of design processes with a prescriptive nature and of a generic character. Design processes, however, appeared to be more product-and context-specific than had been anticipated, perhaps because of the fact that design methodology emerged from the practitioners’ experiences more than from philosophical reflections on the nature of design (De Vries 1993). Of course, the practical experiences are of great value for determining what works and what does not work in design and the management of design. But philosophical reflections have shown to be a very useful complement for those practical experiences. Such reflections point out that all these flowcharts for design processes always present a reduced and simplified version of reality. Reality is always more complex than any flowchart suggests. This complexity can be

Methods in innovation design research 35 seen as problematic, but it can also be seen as a richness that one can exploit. Each process offers its own possibilities to lead to a successful outcome. But problems can easily emerge if we ignore the differences between the flowcharts as a model of reality and reality itself. Models are useful but limited. As long as the limitations are taken into account, they serve a useful role. In this chapter, we will show how different product development processes can differ due to different contexts that require adaptions of the model-like handbook schemes and flowcharts.

So due to this philosophical input, more attention was paid to the differences between different design processes. This also applies to the design research projects that are done to acquire the knowledge that is needed to come to a successful product. Most literature only describes the developmental part of product development processes, but there is also a research part. For that part, too, there is no standard procedure and each research project has its own specific goals and methods. This has led to two new ideas. The first idea is that a typology, taxonomy or classification of product development research processes is needed as there are different processes for different designs. The second idea is that these differences are related to the assumption about what knowledge is available that is inherent for the design methods. In one context, the knowledge assumption underlying a design method may be fulfilled and the method will work, but in other contexts, at least some of the assumptions may not be fulfilled, which means that the method will have to be adapted to these different contexts. These two ideas will be elaborated in this chapter.

A classification of product development processes

Zwart and De Vries, based on an analysis of master’s projects at a university of technology, have developed a classification for innovative design projects. This classification consists of six project types that form the building blocks of an overall product development project. Different product development projects will contain different building blocks projects. These building block projects will now be described one by one.

Descriptive knowledge projects

This type of project is what most people will think of intuitively when the term ‘research’ is mentioned. It resembles most closely the research that is done in natural sciences. In such research, description of an existing state-of-affairs is the aim. The aim is not (yet) to assess that state-of-affairs. The physicist studies electrons and if (s) he finds one of which the behavior deviates from what an electron normally does, the researcher will not conclude that the electron is malfunctioning or broken, but that apparently it is not an electron. The aim of studying electrons is to describe their behavior and properties and not to assess that behavior by comparing with a standard for electrons. This is contrary to an engineer who studies a drilling machine and who does have an opinion on that machine. While the physicist does not talk about good or bad electron, the engineer does talk about good and bad drilling machines. For descriptive knowledge projects, no standards for the object of study need to be set. Standards for the way knowledge is gained do need to be stated. Therefore, in natural sciences, the so-called ‘empirical cycle’ has been developed in which new knowledge is acquired in a cycle of hypothesis development and testing these hypotheses. The hypothesis that stands against all tests will eventually become a theory and a theory that survives for a very long time eventually becomes a paradigm. The criterion for rejecting or accepting a hypothesis is ‘truth’, a rather complicated notion that is usually taken as ‘in accordance with the observations’. Natural science hypotheses, even when they have gained the status of a theory, are still tested over and over, because there is always the possibility that a new observation will cast doubt over the truth of the theory. After all, even classical mechanics was falsified although it had survived for more than two centuries. In product development, however, a more pragmatic approach is used. The purpose of product development is not to contribute to science by delivering knowledge that will survive even in the most bizarre testing conditions, but it only needs to be valid in normal circumstances, namely those under which the product will function. The extreme generalization that is aimed for in natural sciences is not an aim here. So even though this first type of project closely resembles the empirical cycle in natural sciences, there is an important difference. Finding ‘truth’ is not the ultimate aim; rather, the aim is finding knowledge that functions under those circumstances under which the product will be used. Particularly in large corporate laboratories, researchers can be tempted to behave like natural scientists. The history of the Philips Research Laboratories, to mention just one example, is full of such cases. Good project management will ensure that researchers in the corporate laboratory will not fall into the trap of striving for too robust a theory.

 
Source
< Prev   CONTENTS   Source   Next >