1 Introduction

Engineering design is a creative activity. Understanding this complex process, so as to optimise or improve it, has been difficult. Many representations of the process have been advanced to identify the key process characteristics and the causality relationships that determine successful output of the design process. Significant representations are the simple linear model (Finger and Dixon 1989a, b; BS7000 1989), functional modelling (Pahl and Beitz 1988), design science (Hubka 1987; Hubka and Eder 1996), total design (Pugh 1991) and derivatives (e.g. Raine 1998), business environment (Hales 1994), network (Crisp 1986), designer’s process (Candy et al. 1996), communications (Wallace 1987), phase diagrams (Hales 1994), project management, design structure matrix (Yassine et al 1999; Yassine and Falkenburg 1999), and signposting (Clarkson and Hamilton 2000).

A challenge to understanding design is that creative process are difficult to model, precisely because creativity involves seeking alternative solutions, even alternative methodologies for seeking solutions. Products are required to have a high degree of optimisation of function, user-satisfaction, risk, and cost. Consequently, design is increasingly complex and requires multidisciplinary and concurrent processes. A compounding difficulty is the variety of situations that involve design. As Simon (1981) observed, ‘Engineers are not the only professional designers. Everyone designs who devises courses of action aimed at changing existing situations into preferred ones’ (p. 129). We identify three areas of variety as different domains (e.g. product design, machine design, etc.), different individual approaches in the level of structured process used, and different design activities depending on the time stage (e.g. concept design, detailed design, etc.), see Fig. 1. Designers operate in different parts of the space, and consequently, there are many definitions, models, methodologies, and personal preferences for design. ‘Design’ is used in the present paper as defined by Hubka and Eder (1996):

‘The task of designing consists of thinking ahead and describing a structure, which appears as (potential) carrier of the desired characteristics (properties, particularly the functions). One can express this statement also in process terms: designing is defined as the transformation of information from the condition of needs, demands, requirements and constraints (including the demanded functions) into the description of a structure which is capable of fulfilling these demands. The demands must include the wishes of the customers, but also all stages and requirements of the life cycle and all intermediate states that the product must pass through’ (p. 4).

Fig. 1
figure 1

Conceptual model for design space, showing independent dimensions of time; domain; and approach, with illustrative labels. The space occupied by one type of designer is shown, and other designers may be at a different position in the design space

Full size image

Many other definitions are possible, some of which are listed by Hubka and Eder (1996), but the above definition was selected as it includes the concept of physical structure being a carrier for function, it acknowledges the origins of the demands (including those of the customer), it pays more attention to constraints than many other definitions of design, and it incorporates the life-cycle considerations (viz. different viewpoints).

1.1 Problem definition

Each of the existing models of design takes a particular perspective, illustrating the perceived ideal design process, or serving as a repository for knowledge about that perspective, or including a methodology by which that perspective can practically be applied to the design process. Some of the models, e.g., Candy et al. (1996), are conceptual rather than detailed, and consequently do not provide specific processes. Others are systematic, e.g. Hubka and Eder (1996), but can suffer from being intimidating and difficult to engage with (Eder 1998; Frost 1999). The models typically use flowcharts to represent the design activities, focussing on diagramming the inputs and the outputs of the process. The models usually show that the design stages influence each other, but seldom explicitly identify the nature of the influence or the constraints. Nor are the diverse methodologies and tools (mechanisms) that support the design process often made explicit. Consequently, the models tend to be focussed on particular domains, stages, or methodologies. Also, it can be difficult to integrate the models together.

The hypothesis of this paper was that a descriptive meta-model could be developed, representing the epistemology of the methods for performing design in technical systems. The model should accommodate (1) multiple dimensions of design complexity (domain, approach, time stage), (2) all design-related activities from the enterprise level through to activities of individuals (especially decision-making processes), and (3) provide a holistic treatment of existing design methods, especially to position them relative to each other, and identify areas weak in supportive methodologies. This is worth doing because of the potential support it could give to the design process.

2 Method

The method was to use a structured, deductive process to decompose the design process into multiple sub-processes. For each of these the initiating events, controls, inputs, supporting mechanisms (e.g. design tools) and outputs were determined. This process was repeated as necessary to provide additional detail. The developing model was inductively reconciled with existing knowledge about design (Pons 2001). The resulting model was expressed as a series of flowcharts using integration definition zero (IDEF0) notation (FIPS 1993; Addy and Simms 1996). The notation was likewise used by Court et al. (1996) to explore a related but different aspect, namely how designers access information.

With IDEF0 notation, a block represents an action. Every inputs, (always on the left of the block) is transformed or even consumed by the function in the block, to produce one or more outputs (exit to the right). Controls, which enter above the block, initiate or ensure that the output is correct. The mechanisms that support the function enter under the block. The notation therefore permits inputs and outputs to be clearly distinguished from other factors that influence the activities. With other flowchart notations the meanings of the arrows is sometimes not explicit, and they generally represent sequence of activities (or influence). However with IDEF0, it is essential to note that arrows convey objects to activities. Therefore, an activity may begin autonomously when its required inputs are available and its constraints permit. Consequently, the IDEF0 notation readily provides that multiple activities can be simultaneously active, and thus supports the modelling of concurrent engineering processes. It also supports sequenced (serial) activities. Multiple levels of model are readily permitted.

3 Results: the design mechanism and constraint model

The presentation of the resulting model starts at the enterprise level, and progresses to further detail including that of the decision process.

3.1 Enterprise perspective of design

The enterprise level is shown in Fig. 2. The activities are numbered and briefly described. The activity ‘Recognise need to develop new product’ (1) involves a design manager or product champion initiating the activity ‘Develop product’ (2), in response to a management or customer stimulus. Working capital is consumed to produce a product specification. Some key characteristics of the product (identified in the figure) are potentially apparent after this stage. The activity (2) is further detailed in a following diagram.

Fig. 2
figure 2

Design mechanism and constraint diagram at the top level

Full size image

The ‘Produce product’ (3) activity is initiated by the upstream product specification, and consumes materials and labour. Some constraints are internal to the organisation (e.g. production capability) and others from external sources (e.g. health and safety legislation). The projected sales volume also influences the production activity. Production also generates concurrent engineering constraints for design and other activities. Key characteristics of the product (e.g. cost, quality, reliability) only become evident as the final product is deployed. The product is sold (4), generating sales volume and net income.

The strategic activity to set organisational priorities (6) produces directives which prompt new product development, and allocates finance for development. Constraints here include the organisation’s mission and the shareholder needs. Input finance is provided by market capital and reserves. This part of the model is not exhaustive but rather illustrative of the financial constraints that affect resource allocation (capital rationing) in product development. Project funding is thus identified in the model as an important aspect of managing design, and one over which the design manager may have limited influence.

The customer measures the worth of the product (7), based on personal values and resource constraints. The customer’s assessment is a subjective process depending on perceptions of a number of key characteristics of the product (e.g. function). Although these key characteristics may be quantified by the manufacturer, the customer usually has only tenuous information, and the measure of product worth may be influenced primarily by perception. Likewise, the values held by the customer, and the means to satisfy them, are incompletely known to the manufacturer and form the basis for market-research activities on product worth, to inform activity (1).

3.2 Product development

The ‘Develop Product’ activity is elaborated in Fig. 3. The model is not prescriptive as to the work breakdown structure in a project, as various activities can simultaneously be active as soon as their constraints permit. Indeed, for quicker time to market it is necessary that many of the activities occur concurrently. For convenience the explanation begins at activity (1).

Fig. 3
figure 3

Design mechanism and constraint diagram for the activity of develop Product

Full size image

Initial concepts at (1), if any, might include market pressure, bench marking against related products, and customer feedback. These are used to produce specifications for the user interface (styling) and engineering product function, and subsequently a styling design (2). Engineering details are designed (3), resulting in drawings and computer-aided design (CAD) models, finite element analysis, etc. Constraints at this stage include styling design, engineering specification, cost, material strength, corrosion resistance, reliability, and production. The downstream task (4) is to design the manufacturing processes, to produce tooling and specifications for manufacturing processes from the engineering drawings.

Observe in Fig. 3 that the activities are more endowed with constraints than inputs. This is a consequence of the modelling approach, which explicitly sought to explore the constraints on design. The ‘constraints’ perspective is unusual compared to other models. The outcome too is somewhat unusual in that it strongly suggests that design is a process of augmented creativity rather than a professionally isolated creativity. The figure shows that the output of any one design stage is not so much the input as the constraint on the next. Thus each design stage is not the complete creative effort, such that downstream activities are merely non-creative technician tasks. Instead, further creative activities are necessary by other downstream designers to complete the overall design. Herbert Simon (1981) came to a similar conclusion concerning the social planning aspect of design:

‘The real result of our actions is to establish initial conditions for the next succeeding stage of action. What we call “final” goals are in fact criteria for choosing the initial conditions that we will leave to our successors’ (p 187)

Each design stage adds a new value to the existing design. Therefore, the skills of different types of designers are complementary and necessary to develop a product to completion. From this perspective, it is clear that the attitude that some designers have for their downstream colleagues, whose work they consider inferior and uncreative, is inappropriate and contrary to the effectiveness of the overall design process and thus the long-term well-being of the organisation.

3.3 A Generic Design Activity

The next part of the model is sought to elucidate the mechanisms available to designers. Design activities occur in each of the activities represented in Fig. 3, i.e., market research, styling design, engineering design, and manufacturing design (this list is not exhaustive).

A key characteristic that emerged in the analysis was the high commonality of design mechanisms across different domains and stages (viz. Fig. 1). This characteristic then was represented by a generic design activity (GDA). The GDA is a conceptual building block for design that encapsulates multiple design mechanisms suitable for deployment at various stages in the design cycle (including all those of Fig. 3), and at as many locations as the design occurs, with one or more of its mechanisms operative. Any number of GDAs may be connected together to represent the total design process. The common sub-activities of the GDA are shown in Fig. 4, and elaborated below.

Fig. 4
figure 4

Generic design activity in the engineering design context

Full size image

3.3.1 Generate candidate solution

A primary task is to find a creative design solution to a problem that is partially defined by some constraints, and for which some partially developed existing concept may exist. The designer, whether human or artificial intelligence, takes the existing concept (if any), and uses various inventive mechanisms to create a candidate solution within prescribed constraints on how the solution should perform. These constraints could originate from upstream or downstream activities. At styling and early design, the upstream inventive constraints may be provided by other mechanisms e.g., voice of the customer (Gustafsson 1996), market survey, focus group, quality function deployment (QFD; e.g. Bergman and Klefsjö 1994; Martin et al. 1998), or analytical hierarchy process (AHP; e.g. Gustafsson 1996; Perego and Rangone 1996). If the GDA is deployed at later design stages (e.g. manufacturing) then the preceding stages (e.g. styling) provide the constraints.

If the design is an incremental improvement on an existing design, then a well-defined input concept exists. In the more general case of innovative design there may be no existing concept and the solution must be created from scratch. The inventive mechanisms include human serendipity, brainstorming, natural analogy, systematic idea generation (Pahl and Beitz 1988), catalogue methodologies (Kersten 1996), Theory of Inventive Problem Solving (TIPS/TRIZ; Zlotin and Zusman 1999), morphological analysis (Hague et al. 1996), genetic algorithms (Schmidt and Cagan 1993), grammars (Andersson 1994), expert systems (Cunningham and Smart 1993), and neural networks (Noguchi 1998).

The output is a candidate solution. It is possible that several solutions may be considered simultaneously and be in various positions within the design activity, and several design activities in a larger system may all be active. Therefore, the GDA should not be interpreted as a set of discrete-state transitions but as a system of multiple simultaneously active threads.

3.3.2 Assess Solution

The candidate solution is next assessed for validity. Mechanisms include focus groups (especially at early styling design), system simulation (throughout engineering design), functional modelling (Hubka and Eder 1988; Oh and Sharpe 1996), bond graphs (Cellier 2001), feature-based modelling (Fu and De Pennington 1994), risk assessment (including qualitative, hazard and operability study, quantitative, fault tree analysis, and failure mode effects analysis; Ossenbruggen 1994), sensitivity analysis, design of experiments, loss functions (Box et al. 1988), decision analysis and belief networks (Clemen 1996), operational research/management science (Taylor 1999), Fuzzy Theory (Wood and Antonsson 1989), Monte Carlo analysis (Vose 1996), and qualitative simulation (Kuipers 1994).

The assessment constraints may originate from prescribed upstream constraints, e.g., manufacturing design may receive geometric tolerances from an upstream detailed design. There are also ‘reasonably anticipated constraints’, which include professional judgement factors such as safety and liability. Also, the proposed solution must not violate earlier design intent, especially for incremental design or where design is reworked in response to failure.

The primary output from this activity is a solution concept. This adds value to the original candidate solution, either by clarifying or adding new information. Additional outputs include the preliminary constraints for concurrent engineering, cf. the overlapping concept in design structure matrix (Yassine and Falkenburg 1999). Although the design has not yet been finalised, there will be sufficient information for other upstream and downstream activities to begin their processes. If the candidate solution fails the assessments, then either a new solution must be generated or the design must proceed with an imperfect solution.

3.3.3 Select solution

A decision must be made whether or not to accept the solution concept. Decision mechanisms include decision-problem classification (Ullman and D’Ambrosio 1995), conflict resolution, and risk/decision analysis (Clemen 1996) (including belief networks, influence diagrams, and decision trees). The activity is constrained by concurrent engineering requirements from elsewhere in the system (upstream or downstream). However, it is commonly not possible to satisfy all the constraints in a system, and a management decision might be made to give priority to one activity and require the others to compensate. The action of selecting a solution freezes part of the design and imposes constraints on other design activities. The decision process, and the management of risk in selecting a solution may be an underdeveloped area of design research (e.g. Thornton et al. 2000).

The activity is further explored in Fig. 5. The core activity is to make a decision, which is done under management decision constraints and using various decision mechanisms (see diagram). Another activity is to adjust the decision as consequences develop, e.g., the design selection of plastic rather than sheet metal for a dishwasher tub may be found to adversely affect thermal deflection which in turn may necessitate adjustment of the design. Adjustment may be constrained by uncontrolled factors and by not knowing which factors are influential. Controllable factors (‘tuning parameters’; Otto and Antonsson 1993) may be available for manipulation even once the design is complete. Constraints on the decision-making process are identified as the need to accommodate: (1) varying degrees of information abstraction, being quantitative variables (ratio and interval scales) and qualitative variables (ordinal and nominal scales), (2) information that may be uncertain (deterministic, probabilistic, or possibilistic), (3) multiple viewpoints other than function (e.g. the capability to anticipate other views and see how a change in one area affects the system performance in another viewpoint), and (4) incompleteness of knowledge of system performance (mathematically explicit vs. subjective relationships between variables).

Fig. 5
figure 5

Model of the decision process, in particular the influences on a designer or design manager who is selecting a solution

Full size image

Activities such as generating a candidate solution (Activity 1, Fig. 4) and making a design decision (Activity 2, Fig. 5) are cognitive processes. Thus psychological factors, especially personality dimensions and organisational behaviour affect the design process. Their elaboration is a possible area of future research.

3.3.4 Implement solution

Here the selected solution is consolidated into a detailed design, for example, by producing drawings or models. Implementing the solution creates constraints for other activities (e.g. production). If at any stage the design fails then previous activities are re-examined. The activity is further detailed in Fig. 6, the context being mechanical product design.

Fig. 6
figure 6

Model of the implementation process, showing various attributes of the solution that have to be implemented in the detailed design

Full size image

3.3.5 Record and retrieve design intent

The activity here is to record the current design intent, and subsequently retrieve it and feed it forward as a constraint to future solution assessment. This prevents incremental design improvements from unintentionally violating a requirement that was known to earlier designers but is not self-evident in the finished artefact. Recording the rationale for a design is one part of the task, but it is essential that something initiates the retrieval process where appropriate. Design intent seems to be poorly supported by mechanisms. Although the design intent can be recorded in design documentation, or indeed in some CAD software applications, the default mechanism is human memory (Court et al. 1996). Where there is a formal requirement to document the design, e.g., for resource consent, internal approval, or legislative purposes, then there will be documentation of at least the major features in the design. However, for many other design cases, such as product design, there is little to no formal documentation of design intent. In some cases, the close integration of design and manufacture, as in computer-aided manufacture, means that there are no drawings produced either, only direct transfer of data files. Human memory is thus an important mechanism for sustaining the design intent into the future, but is prone to forgetfulness, distorted recall, and loss at staff turn-over.

A separate design activity could model each designer or design team in each of the various stages of the design cycle. The GDA concept is flexible as to the composition of a team, so it does not matter how the distinctions are drawn between styling, engineering, and manufacturing design. The benefits of the GDA approach are the provision of a classification scheme for design tools, the identification of areas that may benefit from further research, and the identification of a ‘common creative activity’ (Simon 1981; p. 158) among different types of professional designers.

4 Discussion

The model is differentiated from other representations of the design process by:

  1. (a)

    The explicit separation of mechanisms, controls, inputs, and outputs.

  2. (b)

    Systematic modelling of microscopic and macroscopic activities of the organisation

  3. (c)

    The identification of a recursive nature to the design process, analogous to the recursion that features in Beer’s viable system model for an organisation (Beer 1985).

The model provides a descriptive perspective that integrates many other design methodologies. It is not an inventive method as are functional modelling (Pahl and Beitz, 1988), TRIZ (Zlotin and Zusman 1999) and others, though it shows where these methods fit in. During its development the model was reconciled with the observations of others on design. At times this involved redefinition of the model. The model should therefore not be considered so much as a hypothetical model of what design should look like, as a perspective on the current body of knowledge on design.

While some other methodologies mandate a formal and relatively complete problem specification before design commences (e.g. the Structured Planning approach of Owen 1993), the present model is not prescriptive about this. Problem definition is implied as prescribed inventive constraints, concurrent engineering constraints, prescribed assessment constraints, and reasonably anticipated constraints (professional judgement). Such constraints may arise from an imposed and premeditated specification, and/or from requirements that arise during the design process. The model does not explicitly provide for a degree of compulsion (Owen 1993) against each constraint, though that is not excluded.

Identifying activities with too few or too many controls or mechanisms may suggest areas of weakness in design. The problem of too few mechanisms was identified in connection with recording the design intent. A case of too few controls appears with solution creation. It appears that most of the effort that has gone into automating and supporting the design process, particularly artificial intelligence, has focussed on solution creation, as opposed to constraint generation. The position with design tools such as expert systems, genetic algorithms, TRIZ, qualitative simulation, and optimisation, seems to be that if there is an intractable design problem, then what is needed is a novel solution. Alternatively that design impasses are caused by a designer who is ignorant of possible solution principles. The first difficulty with this premise is that providing the required explicit specification constraints without resorting to subjective judgement is a non-trivial undertaking in many real designs. Designers may have to determine constraints from incomplete and qualitative specifications, using their professional judgement and experience. Indeed, Court et al. (1996) established that designers rely heavily on their memory, knowledge, and experience. Second, as the above diagrams illustrate, constraints arise from multiple sources, so that over-constraint of the design space is a real possibility. To find a solution it may be necessary to relax some constraints, which involves distinguishing the degree of flexibility in multiple constraints. This too is difficult since there are different functional perspectives (client, design, production, service, etc.) each of which may have multiple members who may agree imperfectly. Thus relaxing any constraint involves negotiation with others and engagement with the complexity of organisational behaviour. These subjective processes are difficult to automate. Thus a formal specification activity will not necessarily fully or even sufficiently identify quantitative constraints prior to commencement of the design. Automated design mechanisms can usually find a solution in a given domain, if supplied with complete problem and constraint definition (usually quantitative). Consequently, such automated design tools are tightly focussed on the domains for which constraints can be specified, and find the terrain difficult where constraints are qualitative or over-constrained.

Another area of future research on design is suggested to be the accommodation of various uncertainties: multiple viewpoints, uncertainty of analysis (incompleteness of knowledge), uncertain variables, and varying degrees of information abstraction. Existing design methodologies do not operate well with these uncertainties and generally simplify them to unambiguous relationships, quantitative variables, and deterministic variables. As Simon (1981) observed, ‘the heart of the data problem for design is not forecasting but constructing alternative scenarios for the future and analyzing their sensitivity to errors in the theory and data’ (p. 171). Related work by Pons (2001) sought to further explore this area.

There is also a need to better understand personality and organisational behaviour factors, and their influence on engineering decision-making.

Thus the benefits of the model are the different perspectives it provides on design, and the identification of possible areas for further design research. A limitation is that the model is complex, and the IDEF0 diagrams might be formidable to non-specialist readers. Another limitation is that the model is dependent on the subjective opinion of its authors, although in mitigation, an explicit premise of the IDEF0 modelling standard (FIPS 1993: p. 14) is that multiple models, from different perspectives, are generally possible and valid. The descriptive nature of the model is not necessarily a limitation, for example Simon (1981) expected that complex systems could be constructed in a hierarchy of levels, and that each of the subsystems may be defined by describing the functions of that subsystem, without detailed specification of its submechanisms. Furthermore, he believed that a powerful technique for designing complex systems was to discover viable ways of decomposing it into semi-independent components corresponding to its many functional parts, although there is no reason to expect that the decomposition of the complete design into functional components will be unique (p. 148–149).

5 Conclusions

This paper has demonstrated a descriptive model of the design process, with special emphasis on the mechanisms that support design, and the constraints on the process. The model accommodates multiple dimensions of design complexity (domain, approach, time stage), enterprise through to individual design activities, and positions existing design methods relative to each other. Furthermore, a set of activities are identified as being generic to design.

From the perspective taken here, design is an augmentative process whereby various mechanisms are used to add value to the design. The output of one design activity may be a constraint rather than an input on the next, so that further creative (as opposed to simply technician) activities are necessary to complete the overall design.

Areas of design that may benefit from additional research are identified and include:

  1. (1)

    The need to help the designer to anticipate constraints from incomplete information, and negotiate for the selective relaxation of constraints in over-constrained design spaces. Success here would likely also enhance the effectiveness of solution-generation systems, particularly the artificial intelligence tools which are dependent on explicit prior constraint formulation.

  2. (2)

    The need to accommodate multiple viewpoints, cope with uncertainty of analysis (incompleteness of knowledge), propagate uncertain variables, and accommodate varying degrees of information abstraction.

  3. (3)

    The lack of robust mechanisms for recording and retrieving the design intent.

  4. (4)

    There is a need to better understand personality and organisational behaviour factors, and their influence on engineering decision-making.