3.4 Conclusion: are models useful for practising designers?
In this section I have:
built a simple model of the design process;
considered other models of the design process:
the March model
the BS 7000 model
the French Model
the Pahl–Beitz model.
One conclusion that I have reached in this section is that none of the models proposed is a perfect description of the design process for even one specialised area of design. Like all models they capture some aspects of reality, but lose others. Thus the idea of a 'golden road' to successful design embodied in a single authoritative model seems untenable.
In reality design is undertaken by humans who will reflect continually on the job in hand and on the best way to achieve the desired result. They will not approach their designing by adhering rigidly to one particular model.
Despite the artificiality of the models, however, it is true that most industries must have tight procedures in order to manage the complex and very expensive interaction between their designers and/or between design teams. Companies may impose procedures based on formal design models, simply because they have to have some explicit set of procedures to follow.
Design cannot be managed routinely if it is to result in good outcomes; whatever the procedures adopted, the success of the resulting designs will be unpredictable. Poor designs will be routinely produced, and it is better to identify and eliminate them early than to assume that a 'good' design model will eliminate them.
One thing is certain. Design, as it is currently practised in most industries (including engineering design), is not an Algorithm. However, it certainly benefits from being well-organised, and designers benefit from knowing that there are stages in the process which can be identified.
All the models we have considered had features which corresponded to some design processes. In my view this makes the models useful. I would even suggest that reflective practitioners might find them useful for comparing with their own design process. If there is something in one model which resonates with practice, and something in another model that resonates with practice, it may be possible to combine these two ideas to give a new, bespoke, model of the particular design process.
An algorithm is a sequence of well-defined operations that lead to the solution of a problem.
That definition, though, doesn't quite capture one of the distinguishing features of an algorithm, which is that the operations used to reach the solution should be specified as straightforward, unambiguous instructions that can be performed in a routine or mechanical way. So, for example, a rule for dividing one fraction by another which said, 'Turn the fraction after the ÷ sign upside down, and change the ÷ to ×,' is an algorithm. On the other hand, a rule which said that a laboratory report should consist of an introduction, a description of the method, a set of results, a discussion and a conclusion would not be an algorithm, because simply following those rules would not generate the report.
The implementation of an algorithm should not require additional creativity or problem-solving on the part of the person or machine that performs the algorithm. However, devising the algorithm in the first place is usually a highly creative business. A software engineer who writes a computer program uses creative design expertise (and other skills) in order to create an algorithm that can be performed by a machine.
Thus I am suggesting all these models might be a rich repository of design relationships. Familiarity with them may enable designers to disassemble them into pieces, which work 'locally', even though the whole does not work. Then the designer may be able to assemble pieces from the various models, and possibly some pieces they have discovered for themselves, to create their own models which they feel describe their individual design process.
I think most designers do have such models so that at any stage they feel comfortable that they know what they are doing, and why they are doing it in relation to previous and future activities.
The models you have seen in this section are part of what might be called 'the culture of design'. Most designers will have encountered aspects of the models, and those designers who are reflective practitioners will have thought about the relationships between the parts of the process. To this extent, although we don't think that the models are perfect, they inform practitioners about the possibilities they may encounter.
In a typical designerly analysis, we come to the conclusion that the models have some useful features for designers, but they cannot be blueprints for the design process. Our conclusion is that the models are neither useless nor essential.
Having described the models, I now want to examine, in Sections 4 and 5 some important aspects of the process which appear in all of the models, that is, conceptual design and the route from concept to prototype.