Previous: Gas Giants Weather: Crash Course Kids #43.2
Next: Testing and Trials: Crash Course Kids #44.2



View count:130,176
Last sync:2024-06-02 06:30


Citation formatting is not guaranteed to be accurate.
MLA Full: "Designing a Trial: Crash Course Kids #44.1." YouTube, uploaded by Crash Course Kids, 10 February 2016,
MLA Inline: (Crash Course Kids, 2016)
APA Full: Crash Course Kids. (2016, February 10). Designing a Trial: Crash Course Kids #44.1 [Video]. YouTube.
APA Inline: (Crash Course Kids, 2016)
Chicago Full: Crash Course Kids, "Designing a Trial: Crash Course Kids #44.1.", February 10, 2016, YouTube, 04:35,
It's time to design some trials. Sometimes engineers need to figure out how to test ideas. In order to do that, we need to design trials to find failure points and see how things are going to work in the real world (with gravity, wind, and human error all factored in). In this episode of Crash Course Kids, Sabrina takes us to the fair to help us design a trial.

///Standards Used in This Video///
3-5-ETS1-2. Generate and compare multiple possible solutions to a problem based on how well each is likely to meet the criteria and constraints of the problem.

Want to find Crash Course elsewhere on the internet?
Crash Course Main Channel:
Facebook -
Twitter -
Tumblr -

Producer & Editor: Nicholas Jenkins
Cinematographer & Director: Michael Aranda
Host: Sabrina Cruz
Script Supervisor: Mickie Halpern
Writer: Jen Szymanski
Executive Producers: John & Hank Green
Consultant: Shelby Alinsky
Script Editor: Blake de Pastino

Thought Cafe Team:
Stephanie Bailis
Cody Brown
Suzanna Brusikiewicz
Jonathan Corbiere
Nick Counter
Kelsey Heinrichs
Jack Kenedy
Corey MacDonald
Tyler Sammy
Nikkie Stinchcombe
James Tuer
Adam Winnik

Sabrina: If you've ever taken a math test, then you know that sometimes "close" just doesn't count. And guess what, close isn't what engineers shoot for when they're designing the solution to a problem. Which is just fine by me, because I like my bridges to get the whole way across the river.

When engineers design the solution to a problem, they focus on a specific outcome. And if you've been following us on our engineering adventures through gorgeous piles of marshmallows, bowling alleys and bridges, you know that in order to make sure that a solution meets that outcome, engineers do a bunch of trials.

But how do we put together everything we've learned about engineering so far to come up with a test that helps us get the results we want? What things do we need to think about when we design trials?

(Big Question)

Let's recap all of the things we've gone over in the last few episodes. Even though our fabulous feats of engineering solved lots of different kinds of problems, they all had some things in common. For each problem, we decided on the criteria for a successful solution. These were the rules we used to judge whether a solution worked or not.

In the bowling alley, our criteria were getting all of the pins down and getting them all down in one turn. We also identified variables - those conditions that could be changed over the course of the experiment.

We learned that some variables we can control and some we couldn't. In the gorge, for example, we couldn't control gravity - but we could control the amount of weight we were supposed to get to the other side of the gorge.

After we pinpointed these variables, we isolated one variable that we could control - and we isolated that one because we wanted to make sure that we knew why a solution worked or didn't. So, when we launched Catbot into a pile of marshmallows, we only changed the angle of the slingshots between the trials and kept everything else the same.

Finally, the last thing we did was to identify failure points: those places where a solution didn't work anymore. Then we tried to fix those failure points. Like we added some extra support to our bridge so both Little Sabrina and her bulldozer could get safely across. And it was important that we do all of these things; if we didn't, we'd have a hard making a solution better if and when it didn't work.

So now let's put the whole bunch of stuff together to plan a set of trials using everyone's favorite carnival game, the ring toss.


First, we'll come up with criteria for a successful outcome. If you've ever done a ring toss, you know that you get a couple of tries to get a ring around the pin. And I say, "Go big or go home," so let's aim to do it in one. So, those are our criteria: we get a ring around the pin, and we do it in one throw.

Next up we identify the variables and isolate one to change between trials. Well, let's see: the ones we can change are the size of the ring, the distance we can stand away from the pin, the size of the pin, and how we throw the ring. We can't do anything about gravity (not that we'd want to!) and there's no wind.

So let's say we choose to isolate the size of the ring. We stand the same distance away from the pin, use the same pin each time, and do our best to throw the ring the same way each time.

Now, step right up - it's time to do some trials! For trial one we'll start with the small ring. We'll throw it and... we'll miss. For trial two we'll use a medium-sized ring... close! But still a no-go. For the next trial we'll use an even larger ring... bingo!

Pretty easy - much easier than at the fair. I'd have a lot of large stuffed animals if it were that easy!

Now we need to see if we can find any failure points. Hmm... Let's try moving away from the pin - way far away. We'll toss and... we'll miss. So there we have a failure point! The solution of using a bigger ring works, but once we change another variable and get too far away from the pin, a bigger ring isn't going to meet our criteria of a successful solution.


So when we design a solution to meet a specific outcome, we have to make sure that we're paying attention to all of the little details. After we decide what the criteria are for a successful solution, we need to make sure that we identify variables and isolate one to change between trials. And even once a trial gives us the outcome we want, we still need to try and find failure points, so we can see if our solution has any limits.

But what if we want to create more than one test? I'll let you toss that around in your mind until next time.