Why a weekly cycle beats a long build
Student prototyping projects often follow a familiar pattern. The team spends weeks building a complete version, tests it once near the deadline, and discovers a problem too late to fix. The build-test-log cycle breaks that pattern into small weekly loops. Each loop makes one change to the prototype, tests that change against a condition written in advance, records what happened, and ends with a decision about the next change.
The method suits project-based STEM classes because it fits a school week and produces visible evidence every time. A teacher can look at the log and see what the team tried, what failed, and why they changed direction. A student can explain the prototype at a demo by walking through the log rather than through a rehearsed story.
Build: one change, written down first
At the start of the week, the team writes one sentence describing the change they will make. Examples: replace the cardboard arm with a thinner strip so the gripper closes fully; move the sensor two centimetres higher so it clears the wheel. One change at a time matters. If a team changes three things and the result improves, nobody knows which change helped.
Keep the build to what the team can finish with the materials and tools available that week. If the change needs a part that has not arrived, choose a different change. The constraint keeps the loop short and stops the project from waiting on purchases. Take a dated photo of the prototype before and after the change and add both to the folder.
Test: a pass condition written before building
Before the build begins, write the test and its pass condition. The test should be something the team can repeat in a classroom: lift a specific object, roll a set distance, hold water for a set time. The pass condition says what result counts as success. Writing it in advance prevents the common habit of deciding after the test that whatever happened was good enough.
Run the test more than once if it is quick, and record every attempt rather than the best one. Note the conditions, such as the surface, the battery, or who operated the prototype. If the test cannot be run because the build is incomplete, record that too. An honest incomplete entry is more useful to the teacher than a vague claim that the prototype mostly works.
Log: one entry per loop
The log is a single shared document or notebook page with one entry per week. Each entry has the same fields: date, change, test, pass condition, results of each attempt, and what the team noticed. Keeping the fields fixed makes entries quick to write and easy to compare. Over a term the log becomes the clearest record of how the prototype developed.
Write the log in plain language and in the past tense. Name who did what, so that contributions are visible. Avoid adjectives such as amazing or perfect; replace them with observations, such as the gripper held the block on four of five attempts. Teachers can read a page of these entries in minutes and give targeted feedback.
Decide: keep, change, or revert
Each loop ends with a decision recorded in the log. Keep means the change passed and stays. Change means it partly worked and the next loop will adjust it. Revert means it made things worse and the team returns to the previous version. Writing the decision closes the loop and sets up the next week's build sentence.
Decisions should follow from the test results, not from how much effort the change took. Students sometimes keep a change because it was hard to make. The log makes this visible, and a short conversation with the teacher can turn it into a lesson about evidence and judgement.
How teachers can run the cycle across a class
Teachers can give every team the same log template and the same weekly rhythm: build sentence on the first lesson, test on a later lesson, log and decision at the end. A brief check of each team's build sentence early in the week catches changes that are too large or tests that cannot be measured. This keeps feedback light and frequent rather than heavy at the end of term.
At the demo, ask teams to present two or three log entries, including one where the test failed. This shifts the demo from a show of the final object to an explanation of how the team learned. It also gives audiences something specific to ask about.
A worked example of one loop
Imagine a team building a small cart that should carry a cup of water across a table without spilling. In week three the build sentence reads: widen the wheelbase by adding a longer axle. The test is to push the cart across the same table five times with the same cup filled to the same line. The pass condition, written before the build, is no visible spill on at least four of five runs.
The team runs the test and records three clean runs and two small spills, both when the cart hit the table edge. The log entry notes the spills and the cause the team suspects. The decision is change: keep the wider wheelbase, and next week add a simple bumper. That is one honest loop, and it gives the next week a clear starting point.
Common mistakes and fixes
Teams often write tests that cannot fail, such as the robot moves. The fix is to add a measurable condition, such as moving a set distance in a straight line. Another mistake is skipping the log when a week goes badly. Those weeks are the most informative entries. A third is changing several things at once under time pressure; split them into separate loops even if that feels slower.
Run the cycle consistently and the prototype improves in steps that can be explained. The result is not only a better object but a record that shows the thinking behind it, which is what project-based learning is meant to build.