Skip to content
Science · PROCEDURAL · Ages 5–6

Testing Push & Pull Designs

Analyse data to determine if a design solution works as intended to change the speed or direction of an object with a push or pull

Lesson: Testing Push & Pull Designs

Subject: Science · Domain: Forces & Motion · Age band: 5–6 years · Type: Procedural Centrality: Foundational engineering practice · Taxonomy ID: mt_RlILL2sccX Standards: NGSS K-PS2-2 · Tailored for: Gifted asynchronous learner (IQ 125–130+), math 2–3, reading 98th %ile, emotional age 5

Your son already does pushes and pulls — he's knocked over towers and rolled cars since toddlerhood. This lesson isn't about the force itself. It's about the engineering loop: build → test → observe → revise. That cycle is where his gifted brain will light up. He may want to skip straight to "I know this" — and for the force concept, he does. The procedural discipline of collecting evidence and letting it drive a redesign is the actual lesson. Consider running the 60-second check at the bottom first.

Why this matters

This is one of those deceptively simple lessons that plants the root system for scientific thinking itself. Your son is at an age and ability level where he can grasp something many adults still struggle with: let the data tell you what to do next, not your first guess.

For a gifted child, this matters doubly. His intuition is strong — he often is right on the first try — which means he can develop the habit of trusting his hunch over evidence. That works until it doesn't (usually around middle school chemistry). Building the muscle of "test it, watch carefully, describe what happened, then decide" protects him later.

The engineering framing also feeds his need for agency and purpose. He's not just "doing science" — he's solving a real problem with a real object he built. That emotional hook matters at age five even when the intellect is running years ahead.

Learning objective

Goal: Your son will build a simple push/pull device, test whether it achieves a chosen goal, describe the result with evidence, and propose one modification based on what he observed.

You'll know it landed if he can say: "I tested it and the ball went too far, so I think I should make the ramp lower and try again."

Before you sit down together

Materials

You probably have everything. Pick what feels right for your space:

  • A ball — ping-pong, marble, small rubber ball. Different masses let him feel the difference later. Rationale: the moving object he's trying to control.
  • A target — plastic cup, taped box, circle of string on the floor. Rationale: gives the test a pass/fail — which is the heart of data collection.
  • Building materials for a ramp or launcher — books, cardboard, wooden blocks, a paper towel tube. Rationale: open-ended enough that he designs it, not you.
  • Something to record on — even if it's just you narrating. If he's game, a simple two-column scratch sheet: "What I tried / What happened." Rationale: externalizing data is the skill.

Best time of day for this lesson

Mid-morning after a snack tends to work well — he's fed, alert, and not yet in the post-lunch slump. Avoid right before a transition he anticipates (park, screen time) — his mind will already be elsewhere. Also avoid when he's already deep in self-directed play; pulling him out of flow tends to backfire with gifted kids.

Some parents find that framing it as "engineering time" rather than "lesson time" reduces resistance. You might try that.

Activity: "Get the Ball in the Cup"

Total time: 15–20 minutes. This is a procedural lesson, so the structure is Model → Guided practice → Independent practice → Wrap-up. But the "procedure" here is the engineering cycle itself, not a fixed set of steps.

Phase 1: Model (3–4 minutes)

Set up one quick ramp yourself — prop cardboard on two books, place the cup about 30 cm away. Don't make it perfect. In fact, make it slightly off so the ball misses.

Release the ball. Watch it miss.

Sample dialogue:

"Hmm. I wanted the ball to go in the cup. Did it? No. Okay — so my design didn't work yet. That's not a fail, that's information. What did I notice? The ball went too far to the left. So if I want it to go in, maybe I need to move the cup, or change the ramp. Let me think out loud: I'll try moving the cup first because that's the easiest change."

You're modeling the inner monologue of an engineer: goal → observation → hypothesis → change. That think-aloud is the real teaching.

Phase 2: Guided practice (5–6 minutes)

Let him build his own ramp with his own materials. Set the same goal: get the ball into the cup.

When he tests it, resist fixing it for him. If the ball misses, ask: - "What happened?" - "Did it go too far, not far enough, or off to the side?" - "What could you change?"

Let him choose the modification and explain why. Even if his reasoning is shaky — "I'll add another book because books make it better" — let him try it. The data will teach him.

Sample dialogue:

"You said the ball didn't go far enough. You added a book to make the ramp taller. Why did you think taller would help? ... Okay, let's test it and see if your idea was right."

Phase 3: Independent practice (5–7 minutes)

Give him a new challenge that requires a different kind of push or pull. Options:

  • Launcher: Build something that pushes the ball (a flick with a finger, a block that slides into it, a pulled-back rubber band).
  • New target position: Move the cup to require a different speed or angle.
  • New ball: Switch to a heavier/lighter ball and ask him to predict what will change.

Step back. Let him run 2–3 test-modify-test cycles on his own. If he starts narrating to himself — gold. That's the inner monologue taking root.

If he writes anything down, wonderful. If he doesn't, you can scribe for him: "Tell me what to write. What did you try? What happened?"

Phase 4: Wrap-up (2–3 minutes)

Bring it back to the big idea:

Sample dialogue:

"You tried, I think, four different things. Did any of them work on the first try? ... Right, none. But each test told you something. That's what engineers do — they don't get it right, they get it less wrong until it works. What would you try next time if we did this again?"

Don't rush this reflection. Gifted kids often skip the "look back" step because they're already mentally on the next thing. Naming the process aloud builds metacognitive muscle.

Kid-response scripts

He says... What's happening You might try...
"I already know how to do this, it's easy." He may be conflating rolling a ball with the engineering loop Raise the bar: "Great — then your job is to get it in the cup in exactly two tests. Engineers call that efficiency."
"It doesn't work!" (frustrated after one try) Perfectionism; common in gifted kids "It's not supposed to work yet. The first test is just to find out what the ball does. Now you have data."
"I'll just move the cup to where the ball went." He's solving the problem cleverly — but changing the goal, not the design Smile and honor it: "That works! But what if the cup had to stay here? What would you change about the ramp?"
"The ball is broken." Externalizing blame for an unexpected result "Interesting hypothesis. How could we test whether it's the ball? What if we tried a different one?"
(Silence, staring, then a precise fix) He's reasoning internally before acting Don't interrupt. Wait. Ask afterward: "What were you thinking when you decided to do that?"
"I want to build something else now." Flow broken or curiosity pulled elsewhere Follow him if possible: "Okay — but tell me first, did your ramp work or not? One sentence."
"What if I make it go super fast?" He's extending into variables you haven't introduced Let him. That's the Stretch, self-directed. Provide the stopwatch or longer runway.

Common misconceptions to watch for

What you see What's actually going on How to gently address
He changes two things at once (adds a book AND moves the cup) Doesn't yet grasp isolating variables — a key science practice "Whoa, two changes! Here's a question engineers ask: which one made the difference? What if we only change one thing at a time so we know which one worked?"
He declares "it works!" after one successful trial Treating a single data point as proof "It did! Let's test it three more times to make sure it wasn't just lucky. Real engineers check."
He blames the ball/materials instead of the design Conceptual gap: design vs. object properties "What if the ball is fine but the ramp needs to be different? What could we change about the ramp?"
He memorizes "test, change, test" as steps without understanding why Procedure-without-concept — the gifted-kid trap Ask "Why do we test before changing things? What would happen if we just changed stuff without testing?"

Stretch (where the real lesson lives for your son)

This is where your son likely lives. Pick one based on his energy.

1. Variable isolation challenge (5 min) Give him three ramp heights and one target. Ask: "Which height gets the ball in the cup? Test each one — but only change the height, nothing else." He's doing controlled experimentation, a skill usually introduced in grade 3+. He can handle the logic; the age-appropriate part is keeping the materials simple.

2. Quantify the results (5–7 min) Hand him a ruler or measuring tape. "How far did the ball go? Let's measure." Now he has numbers. Two-column table: ramp height → distance ball rolled. He can do the arithmetic; let him. This is where his math strength makes the science more interesting, not separate.

3. Prediction vs. result (5 min) Before each test, ask him to write or say a prediction: "I think the ball will go [near the cup / past the cup / short]." Then test. The gap between prediction and result is where learning lives — and gifted kids, who are often right, need practice sitting with being wrong in a safe way.

4. Multi-variable system (10 min, if he's still engaged) Introduce a second ball — heavier or lighter. Now the question becomes: "Does the ramp height that worked for the ping-pong ball also work for the marble?" He's now reasoning about interacting variables, which is genuine physics reasoning.

5. Design documentation (5 min) Ask him to draw his best design before he takes it apart. Label the parts. This builds the engineer's habit of record-keeping and taps his strong verbal/visual skills. If he resists drawing, let him dictate to you.

Quick mastery check (60 seconds)

  • [ ] Prompt 1: "Your ball missed the cup. What's one thing you could change to try again?" → Look for a specific modification, not "try again."
  • [ ] Prompt 2: "Why do we test a design before saying it works?" → Look for something about finding out if it actually does what we want.
  • [ ] Prompt 3: "If you changed the ramp AND moved the cup and then it worked, would you know which one fixed it?" → Look for emerging awareness that multiple changes muddy the cause.

Formal mastery check

From the assessment taxonomy:

If {{name}} builds a ramp to make a ball go into a cup, can they test it, figure out what happened, and say what to change if the ball misses?

Evidence strings to look for: - Tests simple design (ramp, launcher) and collects data on whether it meets the goal - Analyzes results to determine if the design works as intended - Suggests modifications based on data to improve the design's performance

You don't need all three on the same day. If you see the first two, the third will come with one more session. Gifted kids often need the language of evidence modeled a few times before they produce it spontaneously.

Vocabulary to use naturally

Drop these into conversation without making it a vocabulary drill:

  • Design — "What's your design for getting the ball to the cup?"
  • Test — "Let's test it and see what happens."
  • Result — "The result was: the ball went too far."
  • Modify — "What could you modify — change one thing?"
  • Variable — "The ramp height is one variable we can change."
  • Evidence — "What's your evidence that the taller ramp works better?"

What comes next

This lesson sits near the bottom of the Forces & Motion tree, so the "next" depends on which direction his curiosity pulls. Likely dependents and natural extensions:

  • Patterns in motion — predicting where an object will go based on the force applied (same ramp, different balls — does he see a pattern in how far they roll?).
  • Cause and effect in engineering — multiple solutions to the same problem, comparing which works best and defining "best."
  • Collision and transfer — what happens when a moving ball hits a stationary one? (This introduces energy transfer and is genuinely fun.)

If this lesson didn't land

Some days don't. Here are fallback strategies:

  • Different manipulative. If the ball-and-ramp feels flat, try a pulley (string over a chair back, pull a small basket up). The push/pull is more obvious and the goal is clearer.
  • Different time of day. If mid-morning was a fight, try right after nap or rest, or first thing in the morning when he's fresh.
  • Shorten it. Drop to one test cycle. "Build, test, tell me what happened" — done. Come back to revision tomorrow.
  • Skip and return. If he's resistant, shelve it. The concept recurs everywhere in play — blocks, cars, playground slides. You'll catch it in the wild another day.
  • Check the prerequisite. If he genuinely can't articulate that a push made something move, back up to pure force exploration first. But with his profile, that's unlikely — the gap is almost certainly in the engineering-cycle discipline, not the force concept.

Source

  • Taxonomy ID: mt_RlILL2sccX
  • Dataset: Forces & Motion (K–2 strand)
  • Standards: NGSS K-PS2-2 — Analyze data to determine if a design solution works as intended to change the speed or direction of an object with a push or a pull.
  • Generated by: Parent-facing lesson planner, tailored for gifted asynchronous learner (5y9m, IQ 125–130+)