A design situation is a short description of a real context with people in it, such as "the primary classes share one library trolley and books get damaged on the way between rooms".
It names a place, a group of people and something going wrong, then it stops.
It never tells you what to make, which material to use or how big it should be, and that gap is your job.
Situations usually arrive from your teacher attached to a global context, for example globalization and sustainability or identities and relationships.
Two students handed the same situation should finish with different products, because they picked different problems inside it.
Unpack the Situation Before You Choose Anything
Write out who is affected, where it happens, how often it happens and what people currently do instead.
Ask what already exists, because somebody has usually tried something and the reason it failed is the most useful fact you can get.
Split what you know from what you are assuming, then plan to check each assumption with a person rather than a search engine.
List the constraints already baked into the situation, like the width of the corridor, who is allowed in the room and how long a solution must survive.
Five minutes standing in the actual place beats an hour guessing at a desk.
Criterion A, Inquiring and analysing, covers how to run that research and analyse existing products, so treat this stage as the step just before it.
Example
The situation given is that the year 7 locker corridor jams every break and bags end up on the floor.
Unpacking it gives 90 students, 60 lockers, a corridor about 2 m wide and a 15 minute break.
A sign asking students to queue went up last year and is now ignored, which tells you signs alone do not work here.
The two things worth timing are how long one student spends at a locker and whether the jam forms at the lockers or at the doorway.
Choosing the Problem: Narrow Until It Fits One Sentence
One situation holds half a dozen problems and you can only solve one of them properly.
Write each candidate as a sentence naming the user, the difficulty and what better would look like.
Pick one you can measure, because a problem with no visible sign of improvement leaves you nothing to evaluate in criterion D.
Prefer the problem you can watch happening.
A narrow problem solved fully earns more than a broad problem half addressed.
Keep the rejected problems written down, since saying why you set each one aside is part of your analysis.
Scope It Against Time, Tools and Skill
Count the working lessons you actually have left, then halve the number, because testing and folder pages take up the second half.
List the tools you can genuinely book and use, since one 40 minute slot on the laser cutter will not cut fifteen prototype parts.
Check that materials are on the shelf now rather than on order, because a two week delivery can end a project.
Leave room for one full remake, because your first prototype will be wrong somewhere.
Digital projects trap you the same way, for example promising a booking site with a live database when you have three weeks and know only HTML and CSS.
Shrinking the scale is the easiest fix, so design the insert that fits the existing trolley instead of a new trolley.
Activity
Write your problem as one sentence and read it aloud to someone who was not in the lesson.
If they ask what you are going to make, the sentence works, because it described a problem and left the product open.
If they ask what the sentence means, cut a clause and name the user.
Time yourself explaining it in 20 seconds with no diagram.
Agree a Client Who Will Answer You Twice
A client is one named person, or a small named group, who wants the problem solved and will give you an opinion on your work.
A client has a name, so Mr Okafor who runs the year 7 form room counts and the word "teenagers" does not.
Agree with them in writing what they need, what they will not accept and when you can speak again.
You need them at least twice, once before you write the specification and once while you are testing, and both conversations become evidence for the design folder.
Ask what would make them call the product a success, because their answer converts almost word for word into a specification point.
Note their constraints too.
Common Mistake
A situation you picked because it sounded impressive but cannot visit will starve your research from week two onwards.
Deciding the product in week one, such as announcing "I am making a Bluetooth speaker", forces every later page to defend a choice you never tested.
A problem with no measurable success, like making break time happier, gives you nothing to test against.
A client reachable only through one email address usually replies once and then goes quiet.
Lock the Statement Down and Date It
Once the situation, the problem and the client are agreed, write one short statement holding all three and put the date on it.
That statement opens section A of the folder and every later page answers it.
Show it to your teacher before you start researching, because five minutes of checking saves a month aimed at the wrong target.
Wording can be tidied later, but swapping the problem itself in week five leaves your earlier research supporting nothing.
If a real change forces itself on you, write down what changed and why, since a recorded change of direction is evidence of thinking.
Active recall
What three things does a design situation name, and what does it deliberately leave out?
Why is it worth keeping a written record of the problems you rejected?
Give two checks that tell you a problem is too big for the time you have.
What makes a named form tutor a client when "teenagers" is not one?
Which question to your client turns almost directly into a specification point?