Fil Salustri's Design Site

Site Tools


Design Process Overview

A very high level overview of the general design process.


To better understand where you're “headed” using this design process, this page is meant to provide a general procedural overview. Links to details are all available via the design roadmap.

We design things to make life better. That's why we call the things we make “design interventions” - they intervene in the way things are for the sake of making them better. Since this material is applied predominantly to (mechanical and industrial) engineering design, we will often just call the things we make “products.” But products are just one type of design intervention. The same overall process can be used to design a circuit board, an electric motor, a building, a process, a government, a surgical method, a banking system, an organization (like a University!), a font, a project report, a poster, and pretty much anything else.

To make things better we have to understand deeply two things:

  • how things are now, and
  • what in particular is wrong with how things are now (and why).

“Better” is a relative term. We can't make things better without first understanding the way things are. Once we do, we can develop a plan to bring about a change that will make things better. In engineering design, the general plan is “We will make things better by introducing a product that will make up for all the problems we see in how things are.”

Design is how we develop that new product.

The Design Spiral

Fig. 1: The design process spiral.

The design “spiral” is shown in figure 1. It's based on three major stages – problem analysis, system design, and concept design – which are repeated recursively at successively finer/lower levels of detail. At each successively lower level of detail, these three stages repeat – the steps remain the same – but on “different” problems at each level.

Each time through the loop, you will develop a system and its subsystems1) as well as the flows across the system boundary and between its subsystems.

IMPORTANT NOTE FOR STUDENTS. For a one-semester course, you are expected to perform the “loop” only twice. The first time through it, you will develop the overall design, which will include identifying the systems of your design intervention. The second time through, you will develop each of the systems, which will include identifying their subsystems. So going through the loop twice, you will develop three levels of the system hierarchy (the intervention itself, its systems, and their subsystems).

Briefly, here's an explanation of the stages of the design process:

Project Initialization
Establish teams and kick the project off ; review the design brief to understand what is expected; perform some background research.
Problem Analysis
Understanding the context in which your design intervention will have to operate, paying particular attention to the human element; identify all the inputs to and expected outputs from your intervention, and the context transformations expected of your intervention; capture this in the form of requirements.
System Design
Grouping requirements into logical elements (systems) and establishing how inputs will flow through those systems to become the expected outputs.
Concept Design
Embodying systems as physical principles, processes, and technologies that work consistently together to implement the system design.
Detailed Design
Turning the embodiments into plans for manufacturable/implementable objects (ultimately including CAD drawings, etc.) that together form your design intervention.

Example: Designing an Automobile The first, top-most level of designing a car would involve understanding how your new car would “fit” the circumstances in which you have come to think it will be needed/used. This means, among other things, understanding the abilities, needs, and desires of all the humans who will come into contact or use the car in any way.

The requirements you will develop at the top level will include only those that apply to the car as a whole. There will be requirements for total number of passengers and amount of cargo, but not where the passengers and cargo will be located; for speed, acceleration, and fuel economy, but not for number of cylinders, fuel type, and engine location. It will be as if the car itself were a “black box” about which you know nothing but how it must perform in a larger system (its situation).

Top level system design will result only in determining the major systems of the car (e.g., passenger system, drivetrain, structural system, steering system, braking system, lighting system, etc.) and which systems contribute to transforming inputs to the car-system into corresponding outputs.

Top level concept design will result in a collection of embodiments – one for each system – and how they interact to implement the system design. Such elements may include: the number and type of doors, the type and power of engine, the amount of fuel (if any) it ought to carry, location of cargo area, general unoptimized shape of the body, and various technologies (e.g., LED lighting) to be used.

At the next level of the design process, each system (as given above: passenger system, drivetrain, structural system, steering system, braking system, lighting system, etc.) will be treated as a new design problem, leading to the design of each system's subsystems.

For instance, designing the drivetrain system will be treated as a separate but related sub-problem. Requirements for the drivetrain design will derive from the top-level requirements, but could be very different from those of the car-as-a-whole.

The Importance of the Top Level

The top level (the first loop of the recursion) is particularly important for a number of reasons.

Firstly, since this is the earliest part of the design process, it is the one in which errors will accrue the most significant downstream costs to fix.

Secondly, the top level is the one that forms the interface between your design intervention and the “rest of the world” (the situation in which your intervention will have to operate). This situation is rarely under your control. You cannot mandate new roads just because you have a really cool car design; you cannot change FAA or CSA regulations just because you have a really innovative design for a new aircraft design or kitchen stove. And most importantly, you cannot expect people to just change their behaviours, needs, and desires to accommodate what you think is best for them.

The requirements at the top level of a design are fixed by external forces over which you have precious little, if any, control. These are requirements that you have to satisfy if you want anyone to benefit from your design intervention.

This is different than at lower levels of the system hierarchy, because you have more control over lower levels of the design. If you're designing a car, you have more control over the design of the engine than over the design of the overall car, because ultimately no one cares about the engine so long as all the overall requirements are met.

What Information "Trickles Down"?

While designing each (sub)system of a design intervention is a “separate problem,” all the systems and subsystems are related, and so too are their requirements, etc. They are related by the requirements that must be satisfied at any one level of the system hierarchy to provide the functions needed one level up.

For instance, one functional requirement of a car is that it must move. Constraints on this FR describe how fast it must move (in terms of velocity, acceleration/deceleration, and jerk), as well as how fast it must turn2), etc. These requirements exist at the level of the car, and they imply other, related requirements about the drivetrain. It's rather silly to require the engine of a car to “move;” but it is perfectly reasonable to require the engine to provide the necessary energy to bring about the movement of the car as a whole.

Another kind of requirement on a car-as-a-whole might be that we expect it to exhibit a certain rate of fuel consumption. Fuel consumption is, for the car-as-a-whole, dependent on a number of factors including the efficiency of the engine, but also including climate, driving habits of the car's user, road conditions, etc. In this case, we can place a requirement on the engine to exhibit a certain “fuel economy,” but that does not guarantee the car as a whole will hit its target for fuel economy, because of all those other factors that the designer cannot really control. In this case, however, the designer can try to accommodate those other factors by designing an engine that will be most fuel efficient in the regime (of road conditions, climate, driver habits, etc.) within which the car is expected to be used. Thus, requirements about those other forces that influence fuel economy of the overall car will be “inherited” by the engine.

Another example of inherited requirements comes from a product like a warm-air humidifier. A requirement of the humidifier-as-a-whole is to produce air that is both warm (with respect to ambient) and moist. There will likely be a heating system within the humidifier, and one of its requirements will be to produce warm air. Thus one of the overall requirements is inherited directly by one of the product's systems.

This kind of “trickle down” effect of requirements is another important reason why (1) the top level of an intervention's design is so important, and (2) we prefer to start a design from the top level.

Another kind of information “trickles down” from one level of a design to those below: information about embodiments. For instance, the top level design loop for a car will (likely) result in a decision about the overall technology/principle to be used to power it: fuel cell, or fully electric, or electric/gas hybrid, or internal combustion, or a Mr. Fusion. The conceptual decision about the technology that will provide power for the car is fundamental to the design of the lower levels of the design; you can't design the engine if you don't already know whether the car will even have an engine, let alone what type of engine it will be.

At each level of the recursion, you will make decisions about technologies and principles that will be used to implement requirements; that's what concept design is for. Those decisions and embodiments will drive the development of more detailed requirements at lower levels of the system hierarchy.

A final type of information that is passed down from one level of the system hierarchy to its sub-levels is the justification (or rationale) for each decision taken at the one level. The rationale is essential to explain your thinking to whoever will be designing the (sub)systems of your intervention; rationale answers the question Why did you design it that way? and is invariably important for designers of the (sub)systems, so that they can contextualize your work and continue on with it in a coherent and robust way.

In summary, three types of information “trickle down” from one level of the system hierarchy to the others:

  1. requirements,
  2. embodiments, and
  3. rationale.

If you're not documenting at least these kinds of information concisely, precisely, and robustly, then you're not doing your job.

See Also

  • Design roadmap - provides links to the details of the process described in this page.
Note: The terms “system” and “subsystem” are relative terms. Whatever entity is the focus of your attention is the “system;” and it is part of a larger “supersystem” and has “subsystems” as elements.
Turning, remember, is a kind of movement too.
design/design_process_overview.txt · Last modified: 2020.03.12 13:30 (external edit)