Why a brief comes before the build
Project-based STEM lives or dies in its first week. Teams that start building immediately often produce something interesting that answers no particular question. Teams that spend a week debating ideas often reach week three with nothing to test. A one-page quest brief sits between those two failures. It is short enough to write in a single lesson and specific enough that a teacher can say yes, no, or narrow it.
The brief is not a proposal for funding or a pitch for a prize. It is a working document for the team and the teacher. It will change. The point is that every change is visible, because the first version was written down.
The six boxes
Divide one page into six boxes. Box one is the problem, written as a situation, not a solution. “Seedlings on the classroom windowsill dry out over the weekend” is a problem. “We will build a smart watering robot” is a solution in disguise. Box two is the user: who has the problem, and what would they notice if it were solved?
Box three is the constraint: the materials, time, budget, and safety limits for this quest. Write them as facts the team cannot change, such as “cardboard, tape, one small pump from the kit, two weeks, no mains electricity.” Box four is the first object: the simplest physical thing the team can make this week to learn something. Box five is the test: what you will measure or observe, and what result would count as a pass. Box six is the demo date and what you will show on that day.
A worked example
Here is how a team might fill the boxes for the windowsill problem. Problem: seedlings in two trays dry out between Friday afternoon and Monday morning. User: the class that tends the trays and the teacher who finds them wilted. Constraint: classroom materials, one hand-made reservoir, no electronics in week one, two weeks to demo. First object: a wick-and-bottle reservoir for one tray. Test: weigh both trays on Friday and Monday; pass if the wick tray loses clearly less water and the seedlings stay upright. Demo: in two weeks, show both trays, the weights, and what the team changed after the first weekend.
Notice what the example does not say. It does not promise to solve plant care, mention sensors the team does not have, or claim a result before the first weekend. It names one object and one test. That is enough to start.
How teachers can use the brief
Teachers can review a stack of briefs in minutes. The most common feedback is about scope: the problem box describes a whole system when the constraint box allows one object. A useful comment is a narrowing question such as “Which part of this could you test with this week’s materials?” Another is to check that box five has a pass condition. A test without a pass condition becomes a demo with no result.
Add names, not just tasks
Under the six boxes, add one line per student with the part of the object or test they own this week. Shared ownership sounds friendly but makes it hard to see who learned what. Named ownership also makes the demo easier, because each student can explain the part they handled.
Revise the brief, do not replace it
After the first test, the brief will need edits. Maybe the reservoir leaked, the measurement was too rough, or the user turned out to care about a different problem. Cross out and rewrite in a different colour, or keep version two next to version one, so the change stays visible. A visible revision is evidence of learning. A brief that silently becomes a different project tells a reviewer nothing.
Common first-brief mistakes
Writing a solution in the problem box. Listing materials the class does not have. Choosing a first object that takes three weeks to make. Leaving the test box vague, as in “see if it works.” Setting a demo date without saying what will be shown. Each of these is easy to fix on paper and expensive to fix in week five.
How long it should take
A first brief should take one lesson, roughly forty-five minutes to an hour. Spend the first ten minutes on the problem box alone, because a weak problem makes every other box harder. Spend the next twenty on constraint, first object, and test. Use the rest to read the brief aloud to another team and let them ask one question per box. If a box cannot survive one question from a classmate, it will not survive the demo.
What families can ask
Families who want to support a project without taking it over can ask to see the brief. Good questions are simple: what is the first object, what is the test, and what would count as a pass? These questions keep the student in charge of the project while showing that someone at home cares about the thinking, not only the final object. Families should resist the urge to buy better materials. The constraint box is part of the learning.
Where the brief lives
Keep the brief in one place the whole team can reach: pinned to the classroom wall, at the front of a shared folder, or both. A brief hidden in one student’s bag cannot guide the team on the days that student is absent.
From brief to demo
Keep the brief at the front of the project folder and bring it to the demo. Judges and visitors understand the work faster when they can see what the team set out to test. For the next steps, read about choosing a buildable quest, why quests need constraints, and how to go from sketch to demo.