Engineering Design Process
The Loop, Not the Line
Design is usually taught as a sequence - define, research, generate, select, prototype, test, iterate - but exam questions reward you for knowing that the arrows point backward as often as forward. A failed test sends you back to concept generation; a new constraint sends you back to problem definition. The stage you are in is defined by the question you are answering, not by a calendar.
Key concepts to hold: divergent versus convergent thinking (open up options, then narrow), the difference between iteration (repeat a stage with better information) and convergence (options eliminated until one remains), and the role of design reviews as deliberate checkpoints. Know that requirements freeze late and cheaply only in theory; in practice, late changes cost more because more decisions depend on them.
Traps
- Confusing verification (did we build it right, against the spec?) with validation (did we build the right thing, against the user need?).
- Assuming a linear process is "more efficient." Questions often describe a team that skipped testing and asks what failed - the answer is usually that a wrong assumption survived unchallenged.
- Treating brainstorming and evaluation as one meeting. Mixing them suppresses ideas.
Rule of Thumb
The 10x rule of change cost: a defect caught at the requirements stage costs roughly one unit of effort; at detailed design, ten; at production, a hundred. When a question asks where to invest review effort, the earliest stage with unresolved uncertainty is usually correct.
Worked example: A team's prototype leaks. Options: (a) redesign the seal, (b) re-examine whether the housing material was specified for the operating temperature. The disciplined answer is (b) first - if the material requirement was wrong, every downstream seal decision is built on sand.