DESIGN

The word 'design' means different things to different people - a wallpaper pattern, a fashionable dress, the appearance of a racing car and so on. We therefore start by defining what we mean by 'design' in the present context - ie. What design is all about. This understanding will lead to an examination of

• Why we need to 'design', particularly in an engineering environment, and
• How we might best go about 'designing'.

What is design ?

• Means to ends implies that we design not for the abstract mental exercise, but with a definite goal in view - some action or some physical object (artefact) will result from the design.
• Mental suggests that design is a   thinking process. When we design we deal primarily with ideas, with abstractions rather than with numbers - and computers for example cannot do the job for us, though they can help in certain tasks.
  No matter what we design, it is vital that we develop and apply our imagination to   visualise realistically the future form of the artefact or action, how it will eventually come into being and most importantly how it will thereafter interact with people and other artefacts or actions.
• Plan, scheme infers that design is distinct from implementation. Designers especially in engineering seldom execute their plans, but rather   communicate them to others - either by word of mouth, or visually (sketches, engineering drawings, computer simulations &c), or through the written word. Again, note the lack of emphasis on numbers.
• Invention means just that, we are coming up with something   NEW - at least partly.   Creativity is crucial as we shall see later.

So, can we now define design completely?   No ! and neither do we need to. A rigid definition implies a rigid process, and design is anything but that. We shall adopt the following interpretation as it incorporates the above concepts and conveys a reasonably clear idea of what design is all about -

Design is the application of creativity to planning the optimum solution of a given problem and the communication of that plan to others.

Apart from the communication aspect therefore, we understand the essence of design to be problem- solving, though the type of problem encountered in design is not like a typical textbook mathematics problem for example in which the unique 'correct' solution is guaranteed by following, automaton- like, a series of learned solution steps. A design problem on the other hand is a real- life problem with many solutions, some of which meet the problem requirements better, some worse, and where the process of discovering the solutions is not mechanistic.

Some problems might appear not to need 'design' as a solution can be cobbled together without much thought. This is true enough - if the solution can be based on direct experience. However we shall soon come to realise that without experience such a thoughtless solution usually comes to grief sooner or later - the more involved the problem and the more folk affected by the solution, the more likely is the solution going to fall in a heap.

Any old solution will not do - we must strive for the optimum solution.

We expect that the design process, if properly carried out, will show a high probability of disclosing a solution which is optimum or close- to- optimum, if indeed a unique optimum exists.

The prime aim of this chapter is to develop a structured approach to design - an approach which will promote confidence in effectively solving real life problems. We shall focus on problems involving engineering hardware - particularly for Design and Build (D&B) Competitions - however the approach is perfectly general and applicable to problems arising from a marketing sortie or a labour wrangle for example. The approach is thus very relevant to managers and the like - not just to 'hardware designers'.

Before presenting the method however, let us look briefly at Why we go to the trouble of designing . . . .