By the end of the lesson, you can build a short, followable project presentation in which every slide serves one main claim. You consciously choose image, text, and live prototype presentation, and you do not regard walking through the whole working file as a presentation.
Why is a presentation different from a document?
A reader reads a document at their own pace, flipping back. The audience hears a presentation all at once, at your pace, and cannot flip back. So a presentation must be simpler, more orderly, and slower-moving than a document. The viewer reads and listens at the same time; if the slide has a lot of text, they lose one of the two.
One story, not a document repository
A visual narrative is a coherent story conveyed through images, text, and order. There should be one main claim on a slide. Too much text usually signals that the speaker's notes ended up on the canvas. The slide should support the message: a quote, a flow detail, or a before–after comparison often says more than a list. Supplement the details verbally, not in small print.
The anatomy of a good slide
Element
Rule
Title
The claim, not the topic: "Participants opened three pages" instead of "Research"
Visual evidence
A quote, diagram, or screen detail
Text
At most a few lines; keywords, not sentences
Contrast, readability
Even someone sitting in the last row should see it (font size!)
Consistency
The same layout on slides of the same role
Suggested structure
Situation, target user, and problem.
Research evidence and insight.
Task flow or design principle.
The key solution of the prototype.
Test and finding.
Iteration, result, limitation, and next step.
This is not a required number of slides, but a logical order. If a piece of evidence did not change a decision, it is probably not needed in the main story. If a solution is important but has no evidence, call it an experiment or an open hypothesis.
Time frame: a slide takes 45–60 seconds on average. For a five-minute talk, 5–7 slides are thus enough, for ten minutes 8–12. Always show less, but well.
Presenting a live prototype
A live demo is a task-centered, real-time presentation of the prototype or product. A live prototype is strong but risky: a broken link, slow loading, or an unexpected state easily takes away attention. Rules:
Show only that short task that proves the key decision of the story.
Have a pre-tested route and a backup (a screenshot or short recording) in case the link does not work.
Do not navigate between the Figma frames, but lead the audience through the user task ("It is Friday evening, and...").
Say what they will see before you start it; afterwards say what you have seen.
Time it: the demo at most 1–2 minutes.
Handling questions
Prepare for questions: the most frequent are "why didn't you do X?" and "how many people did you test with?". The answer to both is in the decision log and the limitations. If the answer is "I don't know", say so, and suggest a way you would find out.
Worked example: an outline of the Mai program presentation
Title: "A student, five tabs, and a bad evening" – situation and problem.
Research: a quote + the three insights on one slide.
Decision: the unified card, before–after image.
Demo: "It is Friday evening..." – 90 seconds, with backup screenshots.
Test and result: a table of observations (1/4 → 3/3), with the limitations.
Next step: testing the error state.
One slide, one claim; the details (decision log, card sort results) are in the appendix.
Common misconceptions
Claim
Clarification
"The more screens, the more thorough the presentation."
Detail is not the same as followability.
"The design speaks for itself."
Without the reason for the decision and the evidence, the audience can only give an opinion about taste.
"The slide should be full, so they see how much I worked."
A concise slide serves understanding; the amount of work is shown by the quality of the decisions.
In brief
A presentation is simpler and slower than a document; there is one claim on a slide.
The title is the claim, the visual element is the evidence.
The structure: problem → evidence → decision → prototype → test → result and limitation.
A live demo: short, tested, with a backup.
Review questions
Does each of your slides have a one-sentence main claim?
Presentation structure and visual narrative
Objectives
By the end of the lesson, you can build a short, followable project presentation in which every slide serves one main claim. You consciously choose image, text, and live prototype presentation, and you do not regard walking through the whole working file as a presentation.
Why is a presentation different from a document?
A reader reads a document at their own pace, flipping back. The audience hears a presentation all at once, at your pace, and cannot flip back. So a presentation must be simpler, more orderly, and slower-moving than a document. The viewer reads and listens at the same time; if the slide has a lot of text, they lose one of the two.
One story, not a document repository
A visual narrative is a coherent story conveyed through images, text, and order. There should be one main claim on a slide. Too much text usually signals that the speaker's notes ended up on the canvas. The slide should support the message: a quote, a flow detail, or a before–after comparison often says more than a list. Supplement the details verbally, not in small print.
The anatomy of a good slide
Suggested structure
This is not a required number of slides, but a logical order. If a piece of evidence did not change a decision, it is probably not needed in the main story. If a solution is important but has no evidence, call it an experiment or an open hypothesis.
Time frame: a slide takes 45–60 seconds on average. For a five-minute talk, 5–7 slides are thus enough, for ten minutes 8–12. Always show less, but well.
Presenting a live prototype
A live demo is a task-centered, real-time presentation of the prototype or product. A live prototype is strong but risky: a broken link, slow loading, or an unexpected state easily takes away attention. Rules:
Handling questions
Prepare for questions: the most frequent are "why didn't you do X?" and "how many people did you test with?". The answer to both is in the decision log and the limitations. If the answer is "I don't know", say so, and suggest a way you would find out.
Worked example: an outline of the Mai program presentation
One slide, one claim; the details (decision log, card sort results) are in the appendix.
Common misconceptions
In brief
Review questions