Science // Scientific Inquiry

Simple Design Problems

Define a simple design problem reflecting a need or want that includes specified criteria for success and constraints on materials, time, or cost

Ages
8 to 11
Type
Method
Builds on
1 topic
Leads to
1 topic
Standards
1 code

Quick check

Can the learner clearly state what problem they're trying to solve with a design, what would make it successful, and what limits they have on materials or time?

Ask this to see whether the topic is secure.

Topic // Mastery

What mastery looks like

What a learner can do once this topic is secure.
  • Define a design problem by describing the need or want it addresses
  • Specify at least two criteria for a successful solution (e.g. must hold X weight, must cost less than Y)
  • Identify constraints such as available materials, time limits, or cost

Topic // Map

Where this fits

What to learn first and what this topic opens up, with the reason for each link. Required links come first.
  • RequiredMust come first
  • HelpfulHelps, but not essential

Before this

1 topic
  • Comparing Design SolutionsRequired

    Scientific Inquiry // Ages 5 to 8

    Must analyse simple design comparisons before formally defining design problems with criteria/constraints

You are here

Simple Design Problems

Ages 8 to 11 // Method

Leads to

1 topic
  • Comparing Possible SolutionsRequired

    Scientific Inquiry // Ages 8 to 11

    Must define a design problem before generating and comparing multiple solutions

Topic // Research-informed

Teaching notes

From the Marble Skill Taxonomy. These notes have not been validated in classrooms, so treat them as a starting point for your own judgement.

The approach

For learners aged 8–11, teach the shift from 'make something' to DEFINING a design problem before building: name the user, state measurable success criteria, and list real constraints (materials, time, cost, size). The core skills are (1) rewriting vague wishes ('make it good/strong') into testable criteria ('holds 500 g without bending'; 'the cup holds 200 ml without leaking for one minute'), (2) distinguishing a criterion (a goal the solution must meet) from a constraint (a limit on how you may reach it), and (3) keeping in problem-space instead of jumping to a favourite solution. There is no single 'right' brief — a good brief is a defensible one that makes success checkable. The main activity has learners author a full design brief for an authentic, bounded need; supporting activities sort and sharpen individual statements; alternatives use annotated worked briefs and in-role client interviews to elicit and explain these distinctions.

Common misconceptions

  • Treating vague wishes as criteria ("make it nice/good/strong") instead of measurable outcomes.
  • Confusing criteria (goals) with constraints (limits) — e.g. listing 'use only card' as a success criterion.
  • Jumping straight to a favourite solution and back-filling the problem to fit it.
  • Thinking there is one 'right' problem statement, rather than a defensible one that makes success checkable.
  • Ignoring the user — writing criteria for what the maker wants, not what the named user needs.

Useful representations

  • Design brief card: NEED / USER / CRITERIA (measurable) / CONSTRAINTS (materials, time, cost) laid out as fillable slots.
  • Two-column criteria-vs-constraints sorter.
  • A 'testable?' check applied to each criterion — a thumb/tick that only turns green when the statement names a measurable outcome.
  • Constraint chips (allowed materials, £ budget, minutes) that visibly rule options in or out.

Teaching practices

  • Start from an authentic, bounded need with a named user ("a younger child needs a way to carry three library books across the playground in the rain") so criteria and constraints have a real referent.
  • Insist criteria be TESTABLE before any building: rewrite "make it strong" as "holds 500 g without bending" — model the rewrite aloud and have children spot untestable wording.
  • Explicitly contrast criterion (what success looks like) with constraint (a limit you must work within); use a two-column sort of mixed statements to build the distinction.
  • Give constraints teeth: a real materials budget / part list / time limit so children feel that a constraint rules options out, not just describes them.
  • Defer solutions — spend a whole session only defining the problem, so children learn problem-definition is a distinct step, not a preamble to building.

Activities to try

  1. 1

    Author a design brief for a real, named user

    Why it works: Defining a problem is itself a distinct act of construction: a good brief turns a vague wish into something whose success you could actually check, names who it is for, and states the limits you must work within — before any building begins. There is no single correct brief, only a defensible one that makes success checkable.

    1. Choose a bounded, authentic need with a named user — for example 'a younger child needs to carry three library books across the playground in the rain', or 'the reading corner gets so bright in the afternoon that children can't read the tablet screens' — and write the NEED in problem terms.
    2. Write at least two SUCCESS CRITERIA, phrased so you could actually check them. For each, ask 'How would we SEE or MEASURE this?' Rewrite 'make it strong' as 'holds 500 g without bending' and 'make it good' as an observable condition.
    3. List at least one real CONSTRAINT on materials, time, or cost (e.g. 'only card and tape', 'one afternoon', 'under £2'), and say what option that constraint rules out.
    4. Spend the whole session only defining the problem — do NOT design or build a solution yet.
    5. Check your own brief: could someone use it to judge whether a finished solution worked? If a criterion can't be checked, rewrite it.
  2. 2

    Sort statements: criterion or constraint?

    Why it works: A criterion is a goal the solution must meet; a constraint is a limit on how you may reach it. The same brief needs both, and they play different roles.

    1. Take a mixed set of about eight statements (some success goals, some limits on materials/time/cost) and sort each into two columns: CRITERIA (what success looks like) vs CONSTRAINTS (a limit you must work within).
    2. For each placement, say in one sentence why it belongs there — e.g. 'use only card' is a limit on how you work, so it's a constraint.
    3. For any statement you got wrong on a first pass, explain what made it easy to mix up.
  3. 3

    Make it testable: rewrite vague criteria and set a threshold

    Why it works: A criterion is only useful if someone could observe or measure whether it was met; naming a quantity, time, or observable condition is what makes a wish testable. (The source requires criteria to be 'specified'; making them observable is how we meet that at this age.)

    1. Given a vague criterion such as 'make it strong', rewrite it as a measurable statement (e.g. 'holds 500 g without bending').
    2. Given a need, choose a reasonable success threshold and justify it (e.g. 'the cup must hold 200 ml without leaking for one minute').
    3. Given two phrasings of the same criterion, pick the one you could actually check and say why the other can't be tested.

Topic // Standards

Curriculum standards

Codes for the curriculum statements this topic maps to. Each publisher owns its standard text.
Next Generation Science Standards (NGSS) K-5
3-5-ETS1-1

Science // Scientific Inquiry

More in Scientific Inquiry

All 30 topics