The University of British Columbia
The Big Question
← Course Home
Module 1 of 6

Engineering Design - an Introduction

Before you can solve a problem well, you need a process. This module introduces the engineering design process - why it exists, what each stage does, and why skipping steps always costs more than taking them.

COST vs. TIME Project timeline → Cost → Stage 1 Stage 2 Stage 3 Stage 4 Costs committed Actual spending Early decisions commit most future spending

By the end of this module you will be able to

Recall the stages of the engineering design process
Explain how iteration works and why it's normal
Describe why a formal process beats trial and error
Interactive module

Watch the module

The full module from the original Canvas course, running here. Use the playbar to move through the slides. The summary below covers the same material in text for review or print.

Open the module in a new tab →

Design is a process, not a talent

When people hear "design" they usually think of creativity or innovation. Those things are part of it. But in engineering, design means process - a systematic way to apply technical knowledge to real-world, open-ended problems.

A real-world problem is meaningful for people, society, or the planet. An open-ended problem has no single right answer and no single route to get there. Most engineering problems are both. Your job as an engineer is to understand the problem, then find the best solution you can.

This is completely different from a textbook problem, which has one right answer, is already well-defined, and tells you which method to use. Textbook problems are good for learning specific techniques. Design problems are what you'll actually face.

What the novice gets wrong

Most people, when presented with a problem, immediately try to solve it. They pick the first idea that comes to mind and start building. When it doesn't work, they fix it. When it still doesn't work, they fix it again.

This trial-and-error approach might work fine when you're building with Lego. It does not work well when you're designing a bridge, a medical device, or a solution to an infrastructure problem. The costs of fixing mistakes rise sharply the further into the project you are. And the result is almost never optimal.

The core trap: jumping to a solution before you understand the problem. The formal design process exists specifically to prevent this.

The 5-stage engineering design process

Here is the process you'll be working with on May 16. Each stage has a specific purpose:

0
Problem given
For the competition, this is the case envelope. The problem comes to you.
1
Study and clarify the problem
Most problems are not well defined. Who are the stakeholders? What do they actually need? What constraints exist? This stage produces a clear understanding of what you're solving.
2
Generate potential solutions
Resist the first idea. Generate as many different options as possible before evaluating any of them.
3
Identify the most promising solution
Use screening, ranking, and scoring to narrow down to the one idea worth developing.
4
Develop and test
Detailed engineering work - analysis, refinement, testing the chosen solution.
5
Implement
Final construction or production. This is not the end - operation, maintenance, and end-of-life considerations continue beyond it.

Iteration is not failure

The stages are not a straight line you walk through once. In practice, you are constantly moving backwards. You discover something in Stage 3 that sends you back to Stage 1. A constraint you missed changes which solutions are viable. A new idea surfaces in Stage 4 that's worth revisiting in Stage 3.

This is expected and normal. The design process handles iteration systematically. An unstructured approach treats every backtrack as a failure. The formal process treats it as information.

Rule of thumb: the later in the process you discover a problem, the more expensive it is to fix. Getting Stage 1 right is the single highest-leverage thing a design team can do.

Why early stages are the most important

Consider two cost curves running alongside each other through the project timeline.

The first is actual costs - what you're spending. Early stages are cheap. Speaking with stakeholders, sketching concepts, and studying the problem costs very little compared to building and testing a solution in Stage 4.

The second is the costs committed curve - future spending that is effectively frozen by decisions you make now. Even in Stage 1, your choices about what the problem is and whose needs matter will determine most of what you'll need to spend later. Choose the wrong problem in Stage 1 and Stage 4 will be very expensive.

The novice approach skips the cheap stages and commits enormous resources based on incomplete understanding. That's why it almost never produces an optimal result.