Week 6 · Lesson 2 · 50-65 minutes

Plan, Prototype, and Test

Turn your problem into a plan you can build and check: design the inputs, outputs, features, labels, and rules; make a simple prototype; and test it with real test cases.

Materials: This lesson in a web browser · Paper and pencil, or a notes app
This lesson: In progress
Auto-saves on this device

What you'll be able to do

Design your system's inputs, outputs, features, labels, and any rules.
Explain what a prototype is and make a simple one on paper.
Write test cases and use them to find limitations.
Improve your design through iteration based on what the tests show.

Think about it

You have a problem definition: sort a photo of waste into recycling, compost, or trash. What clues (features) would the system look at? What labels would you teach it? And how would you know, before building anything real, whether your plan is any good?

In this lesson you turn your idea into a plan you can actually test on paper.

Make a prediction

Predict: when you first test your prototype with tricky examples, will it get most of them right, or will it fail on some? What kind of example do you think will trip it up?

Vocabulary

See the full course vocabulary

Feature: One measurable clue about an input that a system uses to decide, like an item's color, shape, or size.
Label: The correct answer attached to an example, like tagging a photo 'recycling' so the system can learn from it.
Rule: An exact instruction a person writes, like 'if the item is a glass bottle, label it recycling'.
Prototype: A quick, rough first version of an idea, made to test how it works before building the real thing.
Test case: One example with a known correct answer that you run through your prototype to check whether it works.
Iteration: Repeating the cycle of build, test, and improve so the design gets better each time.

Design the pieces: inputs, outputs, features, labels, and rules

Before building, design the pieces. The input is what goes in (a photo of one item). The output is what comes out (a label: recycling, compost, or trash). The labels are the set of correct answers you would teach the system and use to check it.

Features are the clues the system uses to decide — an item's material, shape, or whether it's wet or greasy. If part of the task is simple and clear, you can even add a rule: 'if it's a clean glass bottle, label it recycling.' A good plan names all of these so anyone could understand how a decision gets made.

Input: photo of one item. Output: one of three labels.
Features: material, is-it-wet, is-it-paper, has-food-on-it.
Rule: 'if it's a banana peel, label it compost.'

A prototype is a rough first version made to test

A prototype is a quick, rough version of your idea built to learn from — not the finished product. Yours can be on paper: a set of 'if these features, then this label' cards, or a simple flowchart a classmate could follow by hand. The point is to make the idea concrete enough to try.

Prototypes are meant to be imperfect. Making one cheaply, early, saves you from spending lots of effort building the wrong thing. You can throw a prototype away and that's fine — you kept what you learned.

A paper flowchart: 'Is it paper? Is it wet? → label.'
A stack of decision cards a friend can follow without you explaining.
A hand-drawn sketch of the app screen showing input and output.

Test cases reveal limitations, and iteration fixes them

A test case is one example with a known correct answer. You run it through your prototype and see if it gets the right label. A handful of good test cases — including tricky ones — quickly shows where your design breaks. Those weak spots are its limitations: the situations where it gets things wrong or can't decide.

Every system has limitations; the goal is to find them on purpose, not be surprised by them later. When a test case fails, you improve the design and test again. That repeat-until-better loop is iteration — the heart of how real products get built.

Test case: a greasy pizza box. Correct label: trash or compost, not recycling.
Limitation found: the prototype labels all boxes 'recycling', so greasy ones are wrong.
Iteration: add a feature 'has food grease?' and a rule to send greasy boxes elsewhere.

Worked example

Prototyping and testing a waste sorter

Design the pieces: Input = photo of one item; Output = recycling / compost / trash; Features = material, is-it-paper, is-it-wet, has-food-grease.
Build a paper prototype: decision cards — 'If food scrap → compost. If clean paper or clean bottle → recycling. Else → trash.'
Write test cases with known answers: clean water bottle (recycling), banana peel (compost), greasy pizza box (trash), foil chip bag (trash).
Run the tests by hand: the prototype gets the bottle and banana peel right but labels the greasy pizza box 'recycling' — a failure.
Find the limitation and iterate: add a 'has-food-grease?' feature and a rule so greasy paper goes to trash. Re-run the test cases; now the pizza box passes.

Takeaway: Design the pieces, make a rough prototype, test it with known-answer cases, find its limitations, and iterate until it improves.

The build-test-improve loop

A loop of four steps that repeats. Step 1: Design the pieces (input, output, features, labels, rules). Step 2: Build a rough prototype. Step 3: Run test cases and record which pass and fail. Step 4: Find limitations and improve. An arrow leads from step 4 back to step 2, showing iteration.

Iteration means going around this loop more than once, improving each time.

A test-case sheet

Test case	Correct label	Prototype's label	Result
Clean water bottle	Recycling	Recycling	Pass
Banana peel	Compost	Compost	Pass
Greasy pizza box	Trash	Recycling	Fail
Foil chip bag	Trash	Trash	Pass

A table of test cases for the waste sorter. Each row has an example, its known correct label, the label the prototype gave, and pass or fail. Clean water bottle: correct recycling, got recycling, pass. Banana peel: correct compost, got compost, pass. Greasy pizza box: correct trash, got recycling, fail. Foil chip bag: correct trash, got trash, pass.

Activity

Prototype Plan Studio

Activity briefing

Turn your problem definition into a designed, prototyped, and tested plan you can present.

Design the pieces: name your input, output, the labels, three to five features, and any simple rules.
Make a paper prototype: draw a flowchart or write decision cards a classmate could follow without your help.
Write at least four test cases with known correct answers, including two tricky ones.
Run each test case through your prototype by hand and record pass or fail on a test-case sheet.
List the limitations the failures revealed, and write one improvement you would make next (your iteration).

Using your problem from Lesson 1, you will design the inputs, outputs, features, labels, and any rules; sketch a paper prototype; write at least four test cases including tricky ones; 'run' them by hand; and note the limitations you find and one improvement you would make. This becomes the core of your Final Project.

You will need

Paper and pencil, or a notes app

Success looks like

Input, output, labels, three to five features, and any rules are named.
A paper prototype a classmate could follow without extra explanation.
At least four test cases with known answers, including tricky ones, run and marked pass/fail.
At least one limitation identified and one improvement (iteration) proposed.

Built-in dataset

Test-case starter kit

A built-in checklist for writing good test cases: include easy examples, edge cases (wet, greasy, damaged, unusual), and examples that could go two ways. Also includes a blank test-case sheet template (example, correct label, prototype's label, pass/fail) to copy.

For now, work through this activity with the built-in materials, your notes, and discussion. An interactive version is coming in a later update.

Check your understanding

Check that you can plan, prototype, and test a design.

Question 1. Which of these are things you should design before building your system? (Choose all that apply.)
Select all that apply.
Question 2. Put the build-test-improve loop in order for one round of prototyping.
1. 1.Design the pieces (input, output, features, labels, rules)
2. 2.Build a rough prototype
3. 3.Run test cases and record pass or fail
4. 4.Find limitations and improve the design
Question 3. What should the team do next?
A team's paper prototype passes every easy test case but labels a greasy pizza box 'recycling' when the correct answer is trash.

0 of 3 answered

Try it yourself

Break your own prototype

Try hard to make your own prototype fail, then use what you learn to make it better.

Write three especially tricky test cases designed to trip up your prototype.
Run them by hand and record which ones fail.
For each failure, name the limitation it reveals.
Propose one change (an iteration) and predict whether it would fix the failures.

Success looks like

Three tricky test cases that stress the prototype.
Each failure linked to a named limitation.
One proposed iteration with a prediction of its effect.

Reflection

Saved on this device as you type

Please don't include private information. Your answers are saved only in this browser and are never sent anywhere.

Why is it useful to build a rough prototype instead of jumping straight to the finished version?

Which test case taught you the most about your design's limitations, and why?

Recap

You turn a problem into a testable plan by designing the pieces, building a rough prototype, running known-answer test cases, and iterating to fix the limitations you find.

Design the input, output, labels, features, and any rules before building.
A prototype is a rough version made cheaply to test an idea early.
Test cases reveal limitations; iteration is the loop of improving until it's better.

Grades 7–8 extension

How much testing is enough?

Real teams can't test every possible input, so they choose test cases carefully: common cases, edge cases, and cases where a mistake would matter most. A medical AI is tested far more strictly than a game that suggests emoji.

For your project, decide which test cases matter most and why. Write a short 'test plan' explaining how much testing you think is enough before this system could be trusted by real users.

Finish this lesson

Attempt the knowledge check — not done
Save a reflection (recommended) — not done

Attempt the knowledge check to finish this lesson.