Design process and problem solving
This domain tests whether you can move from a real user need to a defensible, tested design decision, and whether you can show that reasoning in writing. Examiners look for a clear problem statement, measurable criteria, evidence of iteration, and an evaluation that refers back to the specification.
From problem to specification
Design is iterative, not a straight line: identify need → brief → specification → research → ideas → development → prototype → test → evaluate → modify, with feedback loops backwards at any stage.
- Brief: one short paragraph - client, purpose, key constraints (budget, batch size, standards).
- Specification: a numbered list of design criteria, each written so that it can be measured. Split into musts (essential) and wants (desirable, used for scoring).
- The test: if you cannot name the instrument or procedure that would check a criterion, it is not a criterion. "Lightweight" becomes "total mass ≤ 1.2 kg".
Techniques examiners credit
Brainstorming (quantity before judgement, build on others' ideas); mind mapping (functions, users, contexts); morphological analysis (list functions, list options per function, combine one option from each row); SCAMPER; 5 Whys root-cause analysis; disassembly of existing products; anthropometric tables using 5th–95th percentile ranges rather than averages.
Worked example
Problem: secondary students report shoulder pain from heavy bags. Brief: "design a carrying system for students carrying up to 8 kg that reduces shoulder loading and costs under €35 at 2,000 units." Convert to criteria: load transferred to the hips, verified by pressure mapping; system mass ≤ 1.2 kg, checked on a scale; adjustable for 1,450–1,850 mm stature, checked against anthropometric data; water-resistant for 30 min under a spray test; strap replaceable with one tool. A morphological chart then combines harness type × frame × access × material, and each combination is scored against the musts before any prototype is built. Note how every specification line names its own test - that is the pattern to reproduce.
Traps
- Treating the client's suggested solution as the problem.
- Non-measurable criteria, which make evaluation impossible.
- Confusing testing (collecting data) with evaluation (judging against the specification and recommending changes).
- No iteration evidence: marks come from showing that a test result changed the design.