Design Process
This domain tests whether you can describe and apply an iterative route from a real need to a tested outcome, rather than reciting a fixed sequence of stages. Questions ask you to order activities, explain why a designer returns to an earlier stage, and judge how well a brief, prototype or evaluation has been handled.
Core model
A defensible process is: clarify the problem; write a design brief; research users, materials and existing products; write a specification; generate a range of concepts; develop and model the most promising; make and test a prototype; evaluate against the specification; iterate.
Iteration is not failure. Evidence from a user trial, a strength test or a cost check should feed back into the brief, the specification or the concept. Record the reason for every change, because examiners reward justified decisions, not a tidy linear story.
Worked example
A school asks for a bag that keeps a laptop dry. The first concept is a single-layer nylon backpack. A user trial shows water entering through the zip after ten minutes. Reasoning: the zip, not the fabric, is the water path. The designer adds a storm flap and a water-resistant zip, then retests. That is iteration at detail level; the brief and specification still stand. If the same trial showed students would not carry the bag because it was too heavy, the specification's mass limit would need revisiting - iteration at specification level.
Traps
- Presenting the process as strictly linear, with no feedback or evaluation.
- Writing an evaluation that says 'it worked well' without linking to specification points or test data.
- Skipping research and jumping to a favoured solution.
- Confusing the brief (broad intention) with the specification (measurable criteria).