To make a video explaining your capstone engineering project, structure it as an engineering argument rather than a diary: the problem and who has it, the requirements you set, the two or three design decisions that mattered and what you rejected, how the system works, and how your test results compare with the requirements. Three to five minutes is right for most showcases, about 450 to 750 spoken words. Draw the system as it works rather than filming the hardware sitting still, put your measured numbers on screen next to the targets, and say plainly what did not meet spec. Then cut a 60-second version for your portfolio, because that is the one recruiters will actually watch.

Who watches a capstone video

A capstone video usually has three audiences, and they want different things from the same few minutes.

You cannot make three videos, so build the main one for the judges, because their rubric is the strictest, and make sure it also answers the sponsor's question in the first minute and names who did what at the end. The 60-second cut is for recruiters.

The structure

Most capstone rubrics, and ABET-accredited programmes in particular, look for the same chain: a real need, measurable requirements, design under constraints, and verification that the design meets the requirements. Your video should follow that chain in order.

The problem, in one scene. Who has it, what it costs them, why existing solutions do not fit. Fifteen to thirty seconds.

The requirements, as numbers. Not "fast and reliable". Three to five measurable targets, each with a unit. These go on screen and stay available to come back to, because the results section will be compared against them.

The decisions. Two or three, each told as: the options, the criterion that decided it, the choice. This is the section that proves you were engineering rather than assembling. Most capstone videos skip it entirely.

How it works. The system in operation, one subsystem or one step per scene, drawn so the viewer sees data or force or material moving through it.

Results against requirements. The targets from earlier, with your measured values beside them. Green where you met them, and an honest note where you did not.

What you would change, and the team. One or two lessons, then names and roles.

Worked example: decentralised warehouse robots

Here is the scene list for an imagined capstone: a fleet of small warehouse robots that coordinate without a central server, so the fleet keeps working if any single computer fails. The numbers below are illustrative. Yours must come from your own tests.

1. The problem. A warehouse floor at night. One central fleet controller, drawn as a single box with lines to every robot. The box goes dark and every robot stops. "In many fleets, if the central controller goes down, every robot waits."
2. The requirements. Four targets drawn as a card that will return later: no single point of failure; fleet keeps working with up to 20 percent of robots offline; no collisions at intersections; throughput within 15 percent of a centralised baseline.
3. Decision one: how robots agree on who goes first. Three options on screen: a central scheduler (rejected, single point of failure), first come first served by radio (rejected, ties under packet loss), and intersection reservations negotiated between neighbouring robots (chosen). "We chose the option that still works when a message is lost."
4. Decision two: how they talk. Each robot broadcasts its position and planned path to neighbours within range, drawn as overlapping circles around each robot.
5. How it works. Two robots approaching the same intersection. Each sees the other's plan, they compare reservation times, one slows, one passes. Shown step by step, with the messages drawn as small labelled envelopes.
6. Failure test. Three robots go grey and drop out. The rest re-plan and keep moving.
7. Results. The requirements card returns, with measured values beside each target. One row is amber: throughput came in below target in the densest layout. One sentence on why.
8. What we would change, and the team. "We would test with more realistic network loss earlier." Four names, four roles.

Notice scene 7. Showing a missed target is not a weakness in a capstone video. Judges are assessing engineering judgement, and a team that measured honestly and explained the gap scores better than one that claims everything worked.

If your team is also presenting a mid-project review of one subsystem, such as a communications fallback for these robots, that is a different video with a different job; see how to make a video for an engineering design review.

Draw the system, film the proof

Hardware on a bench is not self-explanatory. A camera pointed at a robot shows a robot. It does not show the reservation protocol, the sensor fusion, or the control loop, which is the part you spent the year on.

So split the job. Use drawn scenes for everything that explains: architecture, data flow, decisions, the sequence of what happens. Use real footage, if you have it, only as proof: ten seconds of the actual robots passing at an actual intersection, placed right after the drawn scene that explains what you are about to see. The drawing tells the viewer what to watch for, and the footage confirms it happened.

A drawn style that suits system flows is cutout or whiteboard. Here is a cutout explainer of a different system, contactless payment, which shows the kind of step-by-step flow a capstone's "how it works" section needs.

The 60-second cut

Recruiters will not watch five minutes. Cut a separate version that runs in this order: the problem in one sentence, the one decision you are proudest of, the system working, one result, and your specific role. That is about 150 words.

Write it as a new short script rather than trimming the long video, because a trimmed video keeps references to scenes that are no longer there. Put it on your portfolio and link the full version underneath.

Make it

1. 1

   Write the requirements as numbers first

   Three to five measurable targets with units, taken from your design report. Everything else in the video points back to these.

2. 2

   Write the script from your report

   Problem, requirements, two or three decisions with the rejected options, how it works, results against targets, lessons and team. Aim for 450 to 750 words.

3. 3

   Draft it in openCanviz

   Paste the script, choose Keep my wording since engineering terms must stay exact, set the target length, and pick cutout or whiteboard so system flows read clearly.

4. 4

   Check every number and label

   Compare every figure, unit and component name on screen with your test data and your report. A drafted label that says the wrong sensor is the kind of thing a judge notices.

5. 5

   Add proof footage where you have it

   Export the drawn video, then drop short real clips in with any video editor, each right after the drawn scene that explains it. Record your own narration if the showcase assesses delivery, or keep the generated voice if it does not.

6. 6

   Write and draft the 60-second cut

   A new 150-word script built around your own role. Make it as a separate project so both versions stay editable.

Common questions

How long should a capstone video be? Use the limit your programme gives. Many showcases ask for three to five minutes; if yours does not specify, aim for that, plus the 60-second cut.

Should every team member speak? Only if the brief asks for it. One clear voice is easier to follow than four nervous ones, and you can still credit each person's role on screen. If individual delivery is assessed, record each person's section yourselves.

Can I use the video as part of my final presentation? Yes. Play the how-it-works section during a live presentation instead of talking through a block diagram. It is usually the hardest part to explain live, and the drawing keeps it in order.

What about confidential sponsor details? Check with the sponsor before publishing anything. A drawn explainer makes this easier, because you can show the architecture without showing their facility, data or product.