Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

9.1 Introduction

The aim of this chapter is to use a presentation of the Domain Theory [1, 2] for discussing the nature of a theory, the models and methods related hereto, the various concepts which go into the theory and the phenomenon the theory is describing. Topics such as the rigour, validity and productivity of a theory will also be discussed.

The Domain Theory is an application of Systems Theory, Chestnut [3], Hall [4], aiming at understanding artefacts in an analytical and synthesising way. Very simplified, the basic idea is illustrated in Fig. 9.1, showing the three domains, where the activity, organ and part views lead to three system models. The three views are what we rhetorically call the answer to the question: ‘How to spell a product’?, namely to spell how the product is used, how it functions and how it is built up. The result of the spelling is seen as the synthesis result; a full definition. The quality of the spelling should be precise semantics and syntax. By ‘domain’, the authors refer to a taxonomic subdivision of the theory for the purpose of understanding the artefact from perspectives of design; it is reflected in the differences of concepts and phenomena explanations of the domains.

Fig. 9.1
figure 1

Popular illustration of the Domain Theory’s three views upon a product and its use activity, [5]

In the following, we will explain the foundation for the theory, its foreseen and present role and its explanation that concerns basic concepts. The theory’s main roles are the support of function and property reasoning, which we treat in sections about state changes and functions, and a section on the application of the theory for product modelling which open for wide applications in modularisation, development of product families and platform thinking.

The Domain Theory is one of many theories Gero and Kannengiesser [5], Chap. 13 in this book, Suh [6], Hubka and Eder [7], Weber [8], Chap. 16 in this book, Lindemann [9], Chap. 6 in this book showing similarity especially concerning the system theory as foundation. We call it a ‘model-based theory’ for underlining that the core of the theory is a modelling of artefacts based upon a selection of concepts and mental constructs. The Domain Theory can’t be proved or falsified. Many ‘model-based theories’ are proposed in the literature and they are all ‘true’ at the same time each with their own explanations and vocabulary. They differ in the quality dimensions, range and productivity. We will come back to these two dimensions below.

9.2 The Theory’s Background

One of the early theories in the design area is the Theory of technical Systems by Hubka, published in German 1973 and in English together with Eder as co-author, Hubka and Eder [7]. Hubka’s theory articulates a general systems theory on the nature of artefacts and activities and their design. A distinction is made between a product’s system elements being organs, i.e. the structural elements carrying functionalities, or being parts, i.e. the structural elements which are the result of the product’s materialisation and decisions about assembling.

Discussions with Hubka gave inspirations and foundation for the creation of what we see as a school of designing, first of all articulated in Tjalve’ book ‘Systematic design of industrial products’(1976), which the English publisher insisted upon calling ‘A Short Course in Industrial Design’ [10], and later in Andreasen’s thesis [1], which contained the ideas for the Domain Theory.

An early application of the Domain Theory was to utilise the pattern for a data structure in a so-called Designer’s Workbench, a research project from around the early 1990s, (Andreasen [11]). It was recognised that such a design support system should contain or be based upon:

  • Design language, i.e. a vocabulary for thinking, reasoning, conceptualisation and specifying solutions in the three domains, based upon semantics and syntax, and equally fitting for human reasoning and computer operations.

  • Design models, i.e. models able to articulate activity, organ and parts structure in a specifying form. To these entities may be added formalised requirements and statements about the final product’s properties, i.e. a soll/ist relation.

  • Design operations, i.e. methodologies for synthesising, composing, evaluating, modelling, simulating, etc., for a gradual synthesis in all domains.

It was our dream that the three systems description of the Domain Theory could create the core of a design language and design models. One of the contributions in its development was the articulation of the so-called Chromosome Model [12], shown in Fig. 9.2. Its virtues are the articulation of the hierarchical structure of the systems and the causal links between the entities pointed out. However, a serious weakness of the model was later identified showing fault in viewing ‘function’ as a domain. As a function is a behavioural aspect related to activities, organs and parts, it is related to all three domains, not a domain in itself (in this sense it is similar to a property). In the next section, we will show examples of a product’s organ structure and part structure, based upon a simple product.

Fig. 9.2
figure 2

The original Chromosome Model with the later abandoned function domain, see the text ([13] adapted from Ferreirinha et al. [12])

Building on Hubka’s TTS and later Andreasen’s Domain Theory, a product‘s nature can be articulated as follows:

  • A product is defined by its structure which is a ‘static’ description of its anatomy.

  • When the product is deployed by the user, it means brought into a context and utilised in a use process, then certain stimuli will be present and the product will show its behaviour.

Eder and Hosnedl [14] define behaviour in the following way:

  • Behaviour is characterised by successive states, including manifestations and value of the properties of the system in response to its environments and the received stimuli.

A product’s or system’s attributes (attributes here is used as a general denominator) may be split into two classes, respectively, describing, the anatomy or structure and the behaviour, Hubka and Eder [7], Andreasen [1]. Based on later development made by Eder and Hosnedl [14] and Smith and Clarkson [15], we propose the following definitions of the two classes, namely properties and characteristics:

  • Properties, which are a class of attributes of an object by which show its appearance in the widest sense and by which it creates its relation to the surroundings.

  • Characteristics, which are a class of attributes of an object that define the means by which the object’s properties are realised.

In the class of properties, we find the sub-class functions, characterised by being active effects. Realising the functions is a behavioural, not structural aspect of a system; therefore it becomes meaningless to articulate a function domain in the Chromosome Model and as a result the function domain was later abandoned; we find functions related to all three structures. Below we take a closer look upon functions. The purpose of a product is to establish a transformation and to deliver necessary effects for this transformation by its functionality. This relationship is articulated in the very fundamental Model of the Transformation System (Fig. 9.3).

Fig. 9.3
figure 3

Model of the Transformation System, Hubka and Eder [7]

The Domain Theory claims that the Transformation System actually may be seen as different views upon a product, namely the activity view and two fundamentally different views upon the product: an organ view and a part view. The Domain Theory also claims the existence of three types of systems related to the product; this may be articulated in the question: What are the characteristics and properties of the three systems? We will answer the question in the following.

9.2.1 The Activity Domain: How the Product Is Used

What Hubka call a transformation process in Fig. 9.3 we call a technical activity, to underline its relation to a technical product; it is a single or sequence of transformations in which the product is utilised (for example, see Fig. 9.8 for coffee brewing activity), or transformed (for instance the coffee pot being assembled). The very interesting aspect of the Transformation System Model in Fig. 9.3 is that it relates products, activities, technology and need satisfaction:

  • The technical activity is determined by the user’s application of the product. Together with the user experience and action with the result of the technical activity it satisfies the initially unsatisfied need.

When the product is used it contributes to the transformation of operands of the classes: material, energy, information and/or biological objects.

What are the characteristics of an activity? Because of the big variety in the state transformations or the technologies’ nature we can only sketch some of the core characteristics:

  • The operands being changed in terms of: material, energy, information or biological nature, characterised by their input and output state.

  • The necessary effects from the operators, their nature, their state and how they are carried or lead into contact with the operands.

  • The conditions of the active surroundings necessary for the transformation to take place.

Example: Moka Pot. A Moka Pot is a simple product for brewing an espresso-type coffee. Figure 9.4 shows the pot and a model of the brewing activity in the form of Hubka and Eder’s Transformation System Model (Fig. 9.3) with the addition of the operator, effects and operand labels.

Fig. 9.4
figure 4

Moka Pot and the coffee brewing activity showing operands, effects and operators

The activity domain, belonging to the use of the Moka Pot, is the sequence of activities showing its use as illustrated in Fig. 9.5.

Fig. 9.5
figure 5

The use activity related to the Moka Pot, showing the many human operations (Hu) and the central brewing process

A use activity may be viewed and described on all levels of concretisation from abstract name, black box identification and pictorial articulation, mathematical and quantitative model of the technology to the full, concrete activity where the product is physically present and the user is in action. The activity’s functionality and required properties may be articulated for proper selection of best solution.

The separation of transformation and product, which we do not find in, for instance, German language literature on Design Methodology, is one of Hubka’s original ideas. In the literature, we find authors aware of composed transformations inside the product. In his efforts to clarify the concept of functions, Vermaas makes a distinction between actions of the device and functions of the device, and Houkes and Vermaas [16] introduce ‘use plans’ as the articulation of activities with the product. We also find observations of use activities in software engineering’s ‘use case’ modelling. Howard and Andreasen [17] see an activity as a dynamic phenomenon which carries properties and functions:

  • A use function is an active effect created by the use activity of the product.

It is important that the use result may be seen as a use function. It is often unnoticed that the main function of a product in itself (for instance the rotation of the cutting tool of a drilling machine) is not identical with the actual use function: to create holes. So the use result shall be seen as a most important function, satisfying the need: holes in the wall.

9.2.2 The Organ Domain: How the Product Functions

Many authors in the area of Design Methodology have recognised the importance of understanding the entities or, in system language, the elements of a product which are a carrier of certain functions. In parallel to biology Hubka, we call these entities organs, i.e., a structural, anatomical description. In the literature, organs are called function carriers, function elements or simply functions, which unfortunately mix up the view of a function as seen as a behavioural aspect of an organ. We define an organ as follows:

  • An organ is a function element (or ‘means’) of a product, displaying a mode of action and a behaviour, which realise its function and carry its properties.

The identification or understanding of organs needs a dynamic perception of the product, it means one has to imagine what happens over time (a state change):

  • An organ is based upon physical, chemical or biological phenomena. When stimuli (external effects) act on the organ, the organ delivers an effect which interacts with the surroundings, namely the wirk function.

Stimuli and effects may be material, energy, information or biological. The word wirk function is selected to remind us that wirk functions relate to the product’s mode of action (German: Wirkungsweise), to be distinguished from use functions related to its activities.

Example: Moka Pot. The Moka Pot’s organs are shown in Fig. 9.6a. The cross section shows how it works: When the pot is placed on a stove, the water will boil and be pressed through the filters and the ground coffee and collect in the serving pot. The pot consists of boiler organ, brewer organ (including two filtering organs), transfer organs and a serving organ. Secondarily, we find also a closing organ (lid) and a handling organ.

Fig. 9.6
figure 6

The Moka Pot’s organ structure (a) and part structure (b). The two structures are shown in a break down description similar to the Chromosome Model Fig. 9.3, and relations are added

The Moka Pot may be viewed as an organ system as described. Generally we may define:

  • A product is a system of organs. The product’s structure consists of its organs and their relations. The relations are active effects (Input/output).

The structure of organs explains how the composition of organs lead from the product’s input to the effects needed for the transformation activity. In the Moka Pot example, we see how pressure and material flow become input or stimuli from the boiler organ to the brewing organ; another organ.

An organ may be viewed or described on all levels of concretisation as mentioned. Many scholars see the function carriers as an abstraction of the parts in a product; actually, we cannot reach any insight into the organs by abstracting a parts view. We see organs as just as concrete as parts; when the product is in action you can hear, see and smell the organs. Again referring to the example, the Moka Pot, a central organ is the organ creating pressure, realised by the closed chamber in which the boiling occurs. The closed vessel is created by the boiler cup’s walls, the gasket and, surprisingly, the composed coffee powder kept in place by the filters. We return to the questions of organs’ properties and modelling later in the chapter.

9.2.3 The Part Domain: How the Product is Build Up

In the mechanical area, products are specified by drawings showing parts and their assembly, where parts and the parts’ assembly are primarily seen from a production viewpoint: What parts shall be produced? How shall they be assembled? Second, the drawings allow skilled designers to read the organs and their functionality from the drawings. We define part in this way:

  • A part is an elementary material element of a part system. Parts are building elements of an organ, realising the organ’s mode of action by the part's physical states and interactions.

A system’s elements may be of the kind activity, organ or part seen from the Domain Theory. However, when discussing organs, please notice the parallel with the German concept of Maschinenelemente, which are actually kinds of organs. Figure 9.6b shows the Moka Pot’s part structure similar to the organ structure concerning the break down and relations. Note that we need to understand the mode of action of the pot for being able to identify organs, while the part structure is the composition of material entities.

Above we saw that an organ is identified and characterised by its ability to create an effect, but also parts are active and interact with other parts through their interface, i.e. assembly relations. We therefore choose also to relate functions to parts:

  • A part’s function (the part’s wirk function ) is based upon physical, chemical and biological phenomena. The part’s interfaces with other parts and its surroundings, create the effects of the part.

Stimuli and effects may be material, energy, information or biological objects. One may ask if the distinction between organs and parts is actually only a question of resolution level. Our opinion is that there are fundamental differences between finding solutions for organs in an ‘endless’ amount of possibilities, and arranging parts in a limited number of roles and arrangements. The organ structure is setting the requirements for the part structure, but the part structure and parts’ functionalities are also determined by the materialisation and assembly arrangement; this is unfortunately an area lacking in supporting theories and models, Andreasen and Howard [18].

Differing from the characteristics of activities and organs, we are able to classify the characteristics of parts as proposed by Hubka and Eder [7]:

  • Form which can be modelled or interpreted as geometry.

  • Material which determines properties like elasticity, strength, conductivity, etc.

  • Surface quality which determines properties such as wear, smoothness and reflection.

  • Dimension in the meaning size and measure; slightly unsystematically can tolerances be seen as dimensions also.

Hubka also adds ‘state’ to the list, reasoning from design situations where the specification of state is important: tension, magnetic, warm, etc. We disagree on this simple articulation of state and show in a section below the overall role of state changes for a product’s functions and properties.

9.2.4 Product Synthesis

The Domain Theory offers evidently a vocabulary for analysing and describing three important aspects of a product; the question is how it can support the synthesis of new products. When a domain is modelled the model is only part of the product’s realisation and is dependent upon the synthesis in other domains. An organ is not fully determined before its parts, and the part structure’s final determination is not feasible without clarifying the activity and organ structures.

The three systems in their gradual determination may be seen as a supporting framework for the synthesis. One design strategy would be to follow what may be seen as a causal chain from user need → use activity result → determination of use activity → determination of the product’s effects and functions → determination of organs and organ structure → determination of parts and part structure. The causality is principally correct but hardly a practical strategy; the mentioned activities have to overlap each other for proper fitting of activities, organs and parts. An important aspect is that the concept of domains enables the articulation of the degree’s of freedom of a design’s total solution space.

The three views may be seen as origin of three possible strategies for synthesis: Starting with ideas and concepts, either in the activity domain, the organ domain or the part domain. We may consider the following types of product development:

  • Designing a new product: This seems like starting with an empty solution space. Typical approaches will be to create a new mode of use or start with creating mode of action for a central organ.

  • Incremental design: where past solutions are utilised. Here rough models of the activity structure and organ structure may be very supportive for defining what shall be re-used and defining the cut in the interaction and interface between the re-used and new entities.

  • Platform-based design: where a product family is created based upon past generations and expected new generations of products. We go into details with this topic below.

The navigation of the three views and the design strategy related hereto differs with the three types of development. Designing a new product may take its starting point anywhere, from a technical idea to a start in the need formulation and use activity, and progressing design from there. In incremental design, we may start by elaborated models of the systems in all three domains, so that we can be determine the parts of the structures we want to re-use and thereby defining the part to innovate. Platform-based innovation may be started from elaborated models of a company‘s central areas like production, sales and distribution, etc. The creation of alignment between these areas and the product’s design is central for this type of development. Also, here is there a need for models of the three systems, for instance, articulation of a modular product family, see below.

Dependent upon the design task there may be a need for establishing overview of a solution space in one of the domains, for creating models focusing upon interactions between elements of the kind of activity, organ or part, for creating overviews of compositions of product family members, for creating detailed models of the total product or partial models, for determination of embodiment details and experiments or simulation of the design, etc. The challenge of the Domain Theory and its models (see below) is to cover these situations.

Product synthesis has to be based upon the understanding of the nature of the solutions and reasoning about functions and properties. These are the topics for the following sections.

9.3 The Link Model

The Domain Theory and the related concepts introduced above now create a vocabulary for the ‘spelling of a product’; which means, how to articulate its structural composition. We have also introduced behavioural attributes like function and properties, but the questions remains: What relates function and properties to a user’s perception of value and needs satisfaction? And: How to reason from functions and properties to the structural characteristics of the product and its use? Our capturing and modelling of these two phenomena, closely related to the Domain Model’s concepts, are articulated in the so-called Link Model Fig. 9.7.

Fig. 9.7
figure 7

The Link Model for the product’s need satisfaction and creation of value, and for the designer’s reasoning from need to structure of product and use activity [17]

The model contains the following choices and reasoning, after Howard and Andreasen [17]:

  • The need satisfaction is created by the ‘Use Result’ (the result of the use activity) producing the brewed coffee.

  • The value perception is composed of by being the owner of the Moka Pot and able to brew coffee; the properties of the pot and its functions; the properties of the use activity and its functions, see the example above.

  • The functions related to the product are called wirk functions because they relate to how the product works or more precisely the product’s mode of action (German: Wirkungsweise) – in the case above the mode of action is how the arrangement of the brewing chamber functions ‘to create the flow of liquids’.

  • The functions related to the use activity are called use functions and represent what the operator intends to realise with the product,—in the example ‘to brew coffee’.

The Link Model may be read in two different ways: The one is the analytical way or how the user experiences the need satisfaction and value (thin arrows). The other one is the direction of synthesis from need to determining the product and its use, by function and property reasoning (big arrow).

The notation of the use activity may be expanded to the totality of the product’s life activities from manufacture to disposal. In each life activity,a stakeholder may ask for functions and appreciate certain properties, for instance may product functions be added for easing assembling and the product design may be supporting its ease of assembly; the installation operator may request certain functions for installing, adjusting and testing the product, and service delivered together with the product may call for functions, Tan [19].

The Link Model introduces the concept of ‘function properties’, which play an important role among the product’s many properties, because the composition of functions in a product is closely related to reasoning about the performance and goodness of these functions. Any distinct type of function has a related set of properties which articulate the goodness of the function, see the example in Fig. 9.8 for functions related to a use activity, an organ and a part. The boiler organ is carrying more functions, and the function properties related to ‘heat water’ are shown. Also, the boiler cup part carries or contributes to more organs and therefore carries more functions. The function properties related to ‘transmit heat’ are shown.

Fig. 9.8
figure 8

Functions and function properties related to a use activity, an organ and a part

9.4 The Role of State Changes

A precondition for designing is to understand how things behave and thereby realise the expected functions and carry the wanted properties. The simplification obtained by seeing a product’s attributes as structural characteristics and behavioural properties (between those also functions) may lead to the statement that properties are indirectly determined by the designer’s determination of characteristics. But behaviour only unfolds when the product is ‘activated’ and used, meaning that state changes occur. The properties depend upon behavioural aspects of the activity system, organ system and part system.

Any activity is as mentioned a transformation of certain operands (material, energy, information and biological objects [7], in which their states are changed; which means that values of their properties are changed. Any organ is based upon physical, chemical and/or biological effects, which are triggered by stimuli or input and influenced by the surroundings. An organ’s mode of action is also a matter of state change; of special importance is the active effect created by the organ, seen as function. The parts, which are contributing to a certain organ, each have their role of delivering surfaces, support, heat transfer, conduct electricity, etc. It means that their roles are realised by state changes, even if some of the roles look static.

All three domains may be seen as systems and therefore have structure. What we have just described are the state changes in these structures’ elements: activity, organ and part. But also the structure change. The composition of activities may change over time, certain organs may be passive in certain state transitions and the part structure may depend upon activities and operations made on this structure.

Example: Moka Pot. We have shown the use activities related to the pot in Fig. 9.5, explained its organ and part structures in Fig. 9.6, and used the pot to explain function properties. In the following, we will reason about state changes and properties of the product and its use.

The central organ in the product is the brewing chamber where filter plates keep the coffee powder in position and allow the water to pass through whilst sealing the lower chamber (over the water level) in order to create the pressure required for the brewing. We find here state changes as building up pressure, water flow and transfer of coffee oil from the powder to the water.

One of the parts is the boiling pot which has aluminium walls that transfer the heat from the hot plate to the water. But the pot also carries the thread allowing the assembly of the product and a rim, meeting the sealing, tightening the boiler and carrying the coffee container. There are several state changes ‘experienced’ by this part including its assembly and disassembly, transmitting heat from cold state to hot and back and carrying pressure from ambient state to brewing pressure and back.

The property ‘ease of operation’ is related to the activity structure by the efforts to dose, assemble (see Fig. 9.8), disassemble and clean, and the user’s task to interrupt the heating. The organ structure asks for efforts to manage the brewing and especially the assembling organ, the simple thread connection, may trouble the user. The part structure is asking the user to understand the logic and operations, and the characteristics of the thread, influencing its ‘gripping’, also playing a role in the pot’s ease of operation.

The property ‘quality of the coffee’ depends upon the technology choice for the central use activity: coffee brewing, but also of the user’s proper dosing and timely stop of the heating. The organ structure’s contribution is primarily the creation of pressure in the brewing chamber and proper filtering. The part structure influences through the choice of aluminium, chosen to not tarnish the coffee’.

The overall value or goodness of the Moka Pot is defined by the user or owner and may be composed by price, ease of operation, quality of coffee and pride of ownership. The original product from Bialetti 1933 is the aluminium product with hexagonal form, which may be the owner’s preference and therefore adding to the pride of ownership. The hexagonal form is carried by the heating pot.

The role of state changes may be postulated in this way: A certain product property may be dependent upon the state changes of the use activity, the organ structure and the part structure. This means that each of the entities activity, organ and part system has time-dependant structure, characteristics and state, by which they realise the functions and properties. The implications for designing is that the view upon design as creation of seemingly passive parts in an assembly structure is very far from understanding what really matters: The active phenomena of the use activity, the organs and the parts. Understanding the dynamics is a precondition for proper concern on functionalities, properties and detailed quality questions related to production.

9.4.1 Function and Property Reasoning

Above we have explained the system’s nature, the state change related to behaviour and the concept of function related to activities, organs and parts. It is easy to identify functions of existing products; the interesting part is to understand function reasoning, i.e. how to come from need, problem or task to the determination of how the solution shall work.

The wirk functions are achieved by the resulting effects of the organs which are normally predetermined by the designer and leave no alternatives for the user. However, the delivery of use functions seems to be an ambiguous phenomenon. The synthesis of the use activity and the product are therefore also different concerning function reasoning:

  • The pattern of wirk functions is a question of (at least at the end) establishing a precise interacting pattern (German: Logikstruktur). Systematic approaches like formulating a ‘function structure’, a design matrix or a logical plan seem appropriate.

  • The pattern of use functions is a question of interpretation of a need, of a problem or task, of the users’ intended use and utilisation, and maybe even creating a need or other ways of using the product than intended. The synthesis call for approaches utilising creativity and playing with the language.

Example: Rescuing device. Imagine a fire situation in an airport building with many travellers who shall rescue themselves by leaving the building quickly. Some persons may be in wheelchair or have walking difficulties. Can we imagine a rescuing device like a sledge, operated by volunteers from the public, which can slide safely downstairs with the disabled persons? Early ideas may be based upon using words covering things which may be applicable or similar: a sledge, a tracked vehicle, a multi-wheeler, a multi-legged walker, people with straps at both end of the device, two persons folding hands for a ‘throne chair’, and we might start seeing sub functions like turning the device, fixation of the disabled, etc. And who shall bring the device up for the next transport? How? Identifying use functions is here related to both the users’ and the helpers’ roles which may happen through the gradual addition of precision in the language supported by sketches to explain the words and lead to settling of the use activity’s and product’s characteristics. It is noteworthy to see how our reasoning about functions is closely related to reasoning about properties, like whether it is easy to use, safe, clumsy, understandable, light, etc.

Many authors have commented on the multiple concepts of function we find in practice and literature Vermass [20]. It seems evident that practitioners can cope with this ambiguous and multiple concept of function, while many researchers struggle with creating ‘the’ definition. The following degrees of concretisation seem interesting; all of them might be called function or function modelling:

  • Purpose, goal, intention and task as the starting points for designing or derived from whatever idea or design proposal there might be present.

  • Verbally formulised statements in daily language for creative capture of what might be, what the product shall do and how it is to be used.

  • Verbally formalised statements as labels for activities and organs, intentionally pointing to mode of use or mode of action, which are available and designable.

  • Black box determination of organs, labelled by their functional identity, by identification of input and output and applied for instance to articulate a so-called ‘function structure’, but actually an organ structure (German: Logikstruktur).

  • Description of organs’ mode of action in models or descriptions of their parametric dependencies being physical laws.

  • Description of organs’ embodiment in the form of principal illustrations or technical drawings showing parts and their assembly structure.

The list is telling that what starts with considerations about the interaction among user, product and use activity (see the Link Model Fig. 9.6) gradually become the product’s organ structure with functional relations, and later superimposed by the part structure and its assembly relations. What the list is not telling is how you actually determine the phenomenon suitable for an organ and give it a certain articulation in a mode of action. The Contact and Channel Approach, Albers and Wintergerst [21], Chap. 8 in this book support analysis by pointing to the lines of state changes throughout an organ structure and thereby throughout the related parts, leading to a fundamental understanding of the functions.

Functional and property reasoning [17] and the closely related area ‘property reasoning’ is not only the question of requirements and creating organ structure, but a very delicate question of mastering the best knowledge about the relation between the product’s characteristics and its properties as articulated by Weber [8], Chap. 16 in this book.

Function reasoning is one of the examples of the Domain Theory’s nature. The idea is not to formulate normative methods but to give designers a language for ‘spelling and reasoning’ and supporting the creation of a designers mindset, i.e. understanding of design phenomena and thereby supporting the creation of strategies and models and the application of methods.

Domain Theory has strong similarities to Gero’s Function-Behaviour-Structure framework and ontology, Gero and Kannengiesser [22], Chap. 13 in this book. Gero claims a generality of the framework and articulates it by identifying function, behaviour and structure of a wide palette of artefacts; The Domain Theory claims its validity for technical products and articulate function, behaviour and structure for three classes of structure, belonging to technical products. Both theories see the transformations or synthesis steps from function to behaviour and from behaviour to structure as essential. Other contributions to design science show similarities to the Domain Theory. Lindemann [9], Chap. 6 in this book presents a so-called ‘Munich Model of Product Concretisation’ which has certain similarities. Displayed in his model are working elements seen as abstraction of the components model, though it is not clear how these terms map on to our definitions of organs and parts as laid out in this chapter.

9.4.2 Product Modelling Based Upon the Domain Theory

If we shall create a Designer’s Workbench (see the product modelling section) as an information tool which is able to support the design activity and composing the gradual product synthesis in the three domains,—then there is a need for product models. A product model is a description of the product’s structure seen as an activity, organ and part structure, based upon these entities, their relations and characteristics.

Based upon the Domain Theory, Mortensen [23] proposed design languages for organs and parts, and Jensen [13] has studied conceptualisation based upon formal models of organ and part structures. Ideally seen, the models could carry fully detailed descriptions including function reasoning, designers’ intent and the realised properties (Malmquist and Schachinger [24]) but the complexity is frightening. However, we have found the modelling formalism extremely well suited for modelling of product families sharing certain entities defined for instance as modules. Harlou [25] has developed generic organ diagrams for modelling structure and interaction, and a tool, the Product Family Master Plan, for modelling the commonality and variety of a family. Formally described entities, relations and characteristics allow the utilisation of object-oriented modelling and thereby application of standard software, Hvam et al. [26].

The basic idea of the mentioned authors’ platform approach is the alignment between a company’s products and their production, marketing, sales, distribution and the company’s involvement in delivering service and actively participating to re-use, recovery and disposal. Alignment means fitting and optimising these structures to each other for overall high company performance; the fitting is partially supported by DFX methods and the basic pattern is explained in Olesen’s Theory of Dispositions [27]. The three core aspects of alignment is illustrated in Fig. 9.9, where the variety and commonalities of the product family is shown in the engineering view formulated as an organ structure and aligned with customer views showing applications, and in the part view showing the part structure’s relations to production.

Fig. 9.9
figure 9

Three aspects of alignment and platform approach, after Harlou [25]

Modularisation is based upon encapsulation leading to distinct functionality and rule-based interaction and interface of the modules. Pedersen [28] has expanded this idea to organ, part and activity encapsulation which allows identification of interaction between an organ, its related parts and their manufacturing processes, in order to create an optimised design with regards to variant creation, part commonality and optimisation of the manufacturing process. The Product Family Master Plan framework has been enlarged in work by Kvist [29] to also include the activities of the manufacturing process, for modelling interactions between parts and their manufacturing activities.

Organs are carrying a product’s functions and properties, between these its performance, while parts are the physical embodiment of the organs and relate to production and assembly. Product modelling therefore contains the challenge to formally model the relations between the organ structure and part structure. Bruun et al. [30] have developed a design tool, Interface Diagram, for handling this relation. The tool supports encapsulation of organs and groups them by their functional identity becoming an organ structure, which is superimposed by the part structure and its assembly relations. The product model has been applied as a data model in a commercial PLM systems in order to identify the interacting information belonging to the organ and part domains.

Product models are not just the result of synthesis and product variety schemes, but also visual support for management decisions and configuration management. Visual product architecture models with multiple perspectives on products have been introduced and applied in the early phases of large-scale global product development projects and described by Hansen et al. [31]. An organ structure is used for configuration, i.e. identification of modules and module variations, and basic rules for interaction and interfaces between modules which allow grouping of variants according to commonality and application areas. This creates a mapping of a product family and its commercial exploitation. Among the most important benefits of these models is the ability to describe what architectures are prepared for, and what they not are prepared for—concerning development of future derivative products.

The above-mentioned approaches, tools, and models have been developed and implemented in a range of more than a hundred Danish and international manufacturing companies belonging to a diversity of industries during the last decade. The industrial applications of the research contributions have proven that it is purposeful to apply the mindset of the Domain Theory when doing platform-based product development. Some of the documented benefits that have been achieved are: Reduction of lead-time, reduction of R&D resources and a higher degree of parallelism in design activities, and pro-active planning and preparation of future product launches.

9.4.3 Validity of Theory, Models and Methods

The Domain Theory is the authors’ imagination or mental model about the nature of artefacts and their design. The theory is based on many influences from many authors’ contribution to Design Methodology, their proposed vocabulary and models and the way they envisage designing. Our dream about a designer’s Workbench (Andreasen [11]) was quite influential concerning imaginations about design language, design models and design operations (Mortensen [23]).

We claim, as mentioned, that the Domain Theory is a model-based theory, based upon our selection and formulation of concepts and certain mental constructs. Actually not one model, but several models articulate the theory:

  • The rhetoric, mind-setting model (Fig. 9.1).

  • The Chromosome Model (Fig. 9.2) articulating the three domains and how their respective systems are bound together.

  • The Link Model (Fig. 9.6) intending to explain products and their use seen as value and utility of the user, and the distribution of functions and properties to be designed into the product.

  • The formal product defining models adding to the articulation of phenomena models in Mortensen’s Genetic Design Model System [23] and information models, see the many contributions above, which are active in the transformations illustrated by Duffy and Andreasen [32] (see Fig. 9.10).

    Fig. 9.10
    figure 10

    Design research seen as derivation of models from practice and development of tools and models for practical use. The position of the Domain Theory’s contributions and ontology description is shown, after Duffy and Andreasen [32]

  • The visual models are also introduced above, for supporting design management and decision-making.

We see the model in Fig. 9.10 as an important statement on the difference of our understanding of design phenomena and our dependency of proper articulation in concepts, structures and models, confusing what designing really is, as commented by Culley [33], Chap. 18 in this book.

Models in designing have different and often overlapping purposes like capturing the unknown in design synthesis, defining the design solution, supporting communication, obtaining insight into certain phenomena or supporting management of the design activity, Maier et al. [34], Chap. 7 in this book. The Domain Theory and its concepts have nurtured new theories like Olesen’s Domain Theory [27], models and methods related to design for assembly, quality and environments, and contributions to man/machine interaction, product life thinking and service design, Andreasen [35].

Theory, models and methods are interrelated. Several of the mentioned contributions have launched methods, for instance a framework and several methods for enhancing and designing a product’s interface and operation for giving it a competitive edge, Markussen [36]. The role of the Domain Theory has been to supply a framework and basic concepts, allowing specific areas, like man/machine interaction to be articulated in specific models [36], for instance showing the characteristics of a product’s interface. Application of the models for analysis and synthesis may result in methods.

The question related to this book’s thematic is arising: What is the validity of such a theory, models and methods? Is there any rigour and scientific foundation? The Domain Theory contains mental constructs like function, behaviour and properties, which we try to give a meaning together with other concepts by definitions and integration into models. Our proposals shall be meaningful to practitioners, they shall be easy to integrate into their practice and support their reasoning; this is where the validity shall be found.

Design theories cannot be compared to engineering theories, which are based upon the laws of physics; rigour therefore may not be seen as ‘accordance with physics’, but in the efforts to link a theory to design practice. Design theories shall give understanding and support human design; the derived methods shall ‘function in the pragmatics of professional practice’, Sonalkar [37], Chap. 3 in this book, but we cannot expect that what humans choose to do in design situations shall be generally explainable. Design methods are ‘soft’; they have only a certain probability for leading to results and often we cannot even postulate that the method was the reason for a certain result, Jensen and Andreasen [38].

We see two dimensions in a theory’s goodness, namely its range and productivity. Range is the breadth of related phenomena that the theory is able to describe based upon a shared set of concepts. The sharing or fit of these concepts into ontology, may be seen as supportive to learning and mindset and respecting Occam’s Razor and thereby to the design research area’s consolidation [39].

An interesting signal about range is created by Storga et al. [40], who categorised key concepts and relations between them and brought them into an ontology. The basis is Mortensen’s Genetic Design Model System [23], Hubka and Eder’s Theory of Technical Systems and Theory of Properties (1988), Design Process Theories by Pahl and Beitz [42] and Hubka [42], and Olesen’s Theory of Dispositions [27]. The feasibility of bringing these theories together we see as a sign of our theories’ general range and comprehensiveness. Figure 9.10 shows the position of the ontology in the model of design research.

The productivity of a theory shall be found in its suitability for teaching its applicability for designers’ practice and its utility for researchers to understand and analyse the phenomena of design. The applicability relates to building up creative and productive thinking, to lead to strong supportive models for both analysis and synthesis and for supporting visualisations for management and decision-making.

9.4.4 Summing Up

The aim of this chapter is the presentation of the Domain Theory as an example of a comprehension of theory, models, methods and ontology, illustrating the nature of these articulations. We view design theories as ‘soft’ in their origin and articulation, in their integration into designers’ practice and in their application. Therefore, we judge that goodness of a theory may be articulated by its range and productivity, underlining that such a theory is model based and mainly a mental construct for practical designing. Hereby, we return to the aim of our research concerning the application of the Domain Theory, to be able ‘to spell a product’, and to perform function reasoning and property reasoning in the design route from need and value to the structuring or spelling of the product and its use.