The engineering design process

Why it matters

Engineers rarely get a design right the first time, and they do not expect to. What makes engineering reliable is the process: a repeatable way to go from a vague need to a tested solution. You will see versions of it in every engineering class, every design competition and every job interview question that starts "Tell me about a project...".

The core idea: a loop, not a line

Different organisations draw it with five, seven or ten boxes, but the steps are the same:

1. Define the problem. Who needs what, and why? Write requirementsStatements of what a design must achieve, written so they can be measured, such as "does not tip in ten taps". (what it must do) and constraintsLimits on how you may achieve the requirements, such as budget, size, materials, time, safety and codes. (limits such as budget, size, materials, time, safety and codes). Decide how you will measure success.
2. Research. What already exists? What do the relevant standards say? What failed before?
3. Ideate. Generate several options without judging them yet. Quantity first; ten rough sketches beat one polished idea.
4. Select. Compare options against the requirements, often with a decision matrixA table that scores each option against weighted criteria and adds the results to show which option fits best and why. (below).
5. Build a prototypeAn early working version or model of a design, which can be as simple as cardboard, a spreadsheet or a simulation. or a model. Early prototypes can be cardboard, a spreadsheet or a simulation.
6. Test against the success measures you defined in step 1. Record the results honestly, including failures.
7. IterateTo use what a test taught you to improve the design, then test again.. Use what you learned to improve the design, then test again. Communicate the final design with drawings and a short report.

The arrow from "test" back to "define" or "ideate" is the most important one. A failed test is information, not a disaster.

A worked example: a phone stand

Define. Need: hold a phone upright for video calls on a desk. Requirements: holds a phone at about 60-70 degrees from horizontal; does not tip when the screen is tapped; charging cable still fits. Constraints: one sheet of cardboard, tape, scissors; 30 minutes; no glue.

Ideate. Three options: (A) a folded triangle prism, (B) two interlocking slotted pieces, (C) a rolled tube with a slot cut in it.

Select with a weighted decision matrix. Score each option 1-5 per criterion, multiply by the weight, and add:

Option B wins, but the matrix also tells you why: stability carried the most weight.

Build and test. Tap the screen ten times with one finger. Result: the stand tipped backwards twice. Iterate: extend the rear leg by 3 cm and retest: zero tips in ten taps. That one cycle of test and change is the engineering method in miniature.

Requirements versus constraints

Students often mix these up. A requirement describes what the design must achieve ("holds a phone at 60-70 degrees"). A constraint limits how you may achieve it ("one sheet of cardboard"). Good requirements are measurable. "Sturdy" is not testable; "does not tip in ten taps" is.

Common mistakes

• Jumping to the first idea. The first idea is rarely the best; generate options before choosing.
• Vague success criteria. If you cannot test it, you cannot know whether you met it.
• Changing several things at once. If you change the leg length and the angle together and it improves, you do not know which change helped.
• Hiding failed tests. In industry, test records are part of the design evidence. A test that failed and led to a fix is a strength in a portfolio.
• Skipping documentation. A design only helps if someone else can build it from your sketches and notes.

Quick recap

• The design process is a loop: define, research, ideate, select, build, test, iterate.
• Write measurable requirements and clear constraints before sketching.
• Use a weighted decision matrix to choose between options and explain the choice.
• Change one thing at a time, record every test, and treat failure as data.

Try it

Open the Do tab and run one full design loop on a small, safe problem using paper, cardboard or household items.