Analyze Failures and Iterate

Every prototype eventually fails. A bridge sags, a wheel falls off, a paper airplane nosedives. Failure is not the end of the design — it is the start of the most useful part. Engineers do not panic when something breaks; they investigate. Analyzing a failure means asking what failed, why it failed, and what one change would most likely fix it. This lesson is about turning a broken prototype into the next, better prototype.

Failure mode: what actually went wrong

• Failure mode is the OBSERVABLE way a prototype broke down. Not your guess about why — just what you saw.
• Examples: the bridge cracked at the center, the LED never lit up, the airplane spun left every flight, the boat tipped after 3 seconds.
• Be specific. "It did not work" is not a failure mode. "The hinge snapped on the third trial" is.

Root cause: why it went wrong

A root cause is the deepest reason behind the failure mode. Most failures have three possible sources: the test data was wrong, a component was weak, or a design assumption was off. Engineers ask "why?" until they reach a cause they can actually change. The first answer is rarely the real one — keep digging until you reach something you can fix.

• Test data: did you measure correctly? Did the test setup match the real conditions? Bad data can fake a failure.
• Component: is one part too weak, too small, or the wrong material? A snapped hinge is a component cause.
• Design assumption: did you assume something that turned out to be wrong? "The paper would be stiff enough" is an assumption that may have failed.

Hypothesis: a testable guess

A hypothesis is a single, testable sentence that names what you think went wrong AND what change should fix it. Good hypotheses follow the pattern: "If I change X to Y, then the failure should improve because Z." The hypothesis points to ONE controlled change — not a list of fixes. One change per iteration is the rule.

Controlled change: only one variable per iteration

• Change ONE thing between iterations. Keep every other variable identical to the previous trial.
• If you change two things and the result improves, you cannot tell which change helped — your evidence is muddled.
• Slower at first, faster in the end. Disciplined iteration finds the real cause in a few steps; sloppy iteration spins forever.

Post-mortem: documenting what you learned

A post-mortem is a short written record after a failed trial. It captures what happened so the next iteration starts from real evidence, not memory. A good post-mortem fits on a single page: trial number, failure mode, suspected root cause, hypothesis for next time, and the one variable you will change. No blame, no excuses — just facts and a plan.

1. Observe: write what happened, in plain language. Photos and quick sketches count.
2. Identify the failure mode: name the specific way it broke.
3. Hypothesize the root cause: data, component, or design assumption?
4. Pick ONE controlled change to test next.
5. Retest and compare to the previous trial — not just to your hopes.