To make a video for an engineering design review, treat it as a pre-read that reviewers watch before the meeting, so the meeting can be spent on questions instead of on you explaining the design. Structure it around decisions rather than features: the requirement driving the design, the options you considered, what you chose and why, the questions still open, and the risks you want reviewers to attack. Five to eight minutes is about right, roughly 750 to 1,200 spoken words. End with an explicit list of what you need from the review. A design review video that only presents a finished-sounding design is wasting the reviewers' expertise, because the point of a review is to find problems while they are still cheap to fix.

What a design review is actually for

Engineering programmes borrow the review structure from industry and agencies such as NASA: a preliminary design review (PDR) checks that the chosen concept can meet the requirements, and a critical design review (CDR) checks that the detailed design is ready to build and test. Student teams usually run one or both, under those names or simpler ones.

In both, the reviewers are not your audience in the showcase sense. They are your colleagues for an hour, and their job is to break your design. The best outcome of a review is a list of problems you had not seen. The worst is a polite meeting where everyone nods and you discover the problem in month three.

This is why a design review video is a different thing from a final project video. The capstone or showcase video, covered in how to make a video explaining your capstone engineering project, sells a finished result to people who were not there. The design review video exposes an unfinished design to people who can improve it.

Why send a video instead of slides

A slide deck sent as a pre-read is usually skimmed, because slides without a speaker are fragments. A written design document is better but long, and reviewers often arrive having read only the first section.

A short narrated video is the speaker plus the slides, in the order you intended, at a length people actually finish. Reviewers can pause on the architecture diagram, rewind the trade study, and arrive with questions already written. The meeting then starts at minute one with "on your third risk", rather than with twenty minutes of presentation.

Keep the design document as the source of truth. The video is a guided tour of it, and it should say so.

The structure

The requirement that drives this design. One scene. Not every requirement in the system, only the one or two that this subsystem exists to meet.

The context. Where this subsystem sits in the whole system, in one drawing. Reviewers from outside the team need this or nothing else lands.

The trade study. The options you considered, the criteria, and how each option scored. A table drawn on screen, built one row at a time.

The chosen design. How it works, one step per scene.

Open questions. Things you have not decided yet and want input on. Be specific.

Risks. What could make this design fail, how likely you think each one is, and what you plan to do about it.

The ask. Three to five concrete things you want reviewers to check, challenge or answer.

Worked example: a Li-Fi fallback for warehouse robots

Here is the outline for an imagined preliminary review. The team's robots normally talk over Wi-Fi, but one zone of the warehouse has heavy radio interference from equipment, and robots there lose contact. The proposal is a fallback link using Li-Fi, which carries data by modulating light, through transceivers mounted on the ceiling over that zone. The numbers are placeholders for the team's own.

1. Requirement. "In Zone C, robots must keep a link to the fleet with less than 200 milliseconds of interruption, even when Wi-Fi drops." Drawn as a floor plan with Zone C shaded.
2. Context. The robot's communication stack: Wi-Fi as primary, the proposed light link as fallback, the fleet coordinator behind both.
3. Trade study. Four options as rows: a second Wi-Fi band, a wired tether at docking points, ultra-wideband radio, and Li-Fi. Columns for interference tolerance, cost per zone, install effort, and data rate. Li-Fi wins on interference tolerance, because light is unaffected by radio noise, and loses on install effort.
4. Chosen design. Ceiling transceivers over each aisle in Zone C, a receiver on top of each robot. Recent Li-Fi equipment increasingly follows IEEE 802.11bb, ratified in 2023, which uses near-infrared light and works alongside ordinary Wi-Fi. Shown as cones of light from the ceiling, with a robot passing from one cone to the next.
5. Handover. The robot detects Wi-Fi signal falling, switches to the light link, and switches back when it leaves the zone. Drawn as a sequence, with the target interruption marked.
6. Open questions. "Does a robot carrying a tall load block its own receiver? Should the receiver be on a mast?" and "Should handover be triggered by signal strength or by position on the map?"
7. Risks. Three, in a table: line of sight blocked by racking or loads (high likelihood, mitigated by overlapping cones); handover gaps longer than target (medium, to be measured in a mock aisle); dust on optics in a working warehouse (unknown, need advice).
8. The ask. "Please challenge our likelihood rating for line-of-sight loss. Tell us if anyone has seen optical links in dusty environments. And check whether the 200 millisecond target is the right number for the fleet coordinator."

Look at scenes 6 to 8. They are the reason the video exists. A reviewer with warehouse experience who watches scene 7 might know immediately that the dust risk is serious, and that single sentence in the meeting is worth more than the rest of the presentation.

Writing it so reviewers can push back

Show the losers in the trade study. The rejected options, with the reason each lost. Reviewers can only challenge a decision if they can see the alternatives.

Put the criteria weights on screen. If interference tolerance counted double, say so. Hidden weights are where trade studies quietly go wrong.

Rate your own risks. A risk table with likelihood and consequence invites the reviewer to say "that is not medium, that is high", which is exactly the conversation you want.

Use numbers with units and sources. "Under 200 milliseconds, from the coordinator's timeout setting" can be checked. "Fast handover" cannot.

Say what you do not know. "Unknown, need advice" is a perfectly good entry in a risk table. Reviewers trust a team that admits gaps far more than one that claims full coverage.

Make it

1. 1

   Start from the design document

   Pull out the driving requirement, the trade study table, the chosen design, open questions and the risk table. If any of those is missing from the document, write it there first.

2. 2

   Write the narration as a guided tour

   One paragraph per section, ending with three to five specific asks. Aim for 750 to 1,200 words, five to eight minutes at about 150 words a minute.

3. 3

   Draft it in openCanviz

   Paste the script, choose Keep my wording so technical terms and numbers stay exact, set the target length, and use a whiteboard style so tables and diagrams build one row at a time.

4. 4

   Check every number, unit and component name

   Compare the screen with the design document line by line. A drafted label with the wrong unit will derail a review for ten minutes.

5. 5

   Send it two days before the review

   With the design document attached and a line asking reviewers to bring questions on the open-questions and risks scenes.

6. 6

   Update it after the review

   Edit the risk and decision scenes to reflect what changed. The updated video becomes the starting point for the next review.

Common questions

How long should a design review video be? Five to eight minutes for a single subsystem. If your review covers a whole system, make one short video per subsystem rather than one long one, so reviewers can watch the parts they are qualified to judge.

Does this replace the live review? No. It replaces the presentation part of the live review. The meeting still happens, and it is better because everyone arrives prepared.

What if my supervisor expects slides? Bring the slides too, and use the video as the pre-read. Most supervisors are pleased by a team that sends something watchable in advance, but check what your course expects before you replace anything.

Should I use my own voice? For a review, it often helps, because reviewers then hear the person they will be talking to. Record your own narration and replace the generated voice if you can do it clearly; if not, a generated voice is fine for a pre-read.