In this guide
Your presentation deck is the one artefact every examiner sees, even the ones who never touch your hardware. A clear 10–15-slide story can lift an average project; a padded 40-slide deck can sink a good one. This guide gives you the exact structure, slide by slide.
What your presentation is really being judged on
Examiners score three things during your slot: did you solve a real problem, do you understand what you built, and can you communicate it. The deck is evidence for all three. A rambling deck suggests rambling thinking; a tight one suggests you made decisions and can defend them. Before you open your slide software, decide the single sentence your panel should remember — for example, "a low-cost soil-moisture system that cut irrigation water use by a third in our field test." Every slide must serve that sentence.
The 10–15-slide structure that works
Fewer focused slides beat padded decks. Ten to fifteen slides force you to choose what matters, and they fit comfortably into a typical 10–15 minute slot with time for questions. Use this order — it mirrors how examiners think:
| # | Slide | What goes on it | Common mistake |
|---|---|---|---|
| 1 | Title | Project title, your name(s), guide name, institute, date | Cluttered with logos and decorative images |
| 2 | Problem | The real-world problem in one or two sentences | Starting with technology instead of the problem |
| 3 | Objectives | 3–5 measurable objectives | Vague aims like "to study IoT" |
| 4 | Literature / existing work | What others did and the gap you address | A wall of citations nobody can read |
| 5 | Approach | Your chosen approach and why, in plain language | Jumping straight to the circuit diagram |
| 6 | System design | Block diagram of hardware and software | A photo of tangled wires with no labels |
| 7 | Implementation | Key build steps, tools, and technologies | Listing every library version |
| 8 | Results | Honest measurements with a baseline for comparison | Adjectives ("very accurate") instead of numbers |
| 9 | Limitations | What the system cannot do yet | Hiding this slide or skipping it |
| 10 | Conclusion | Which objectives were met, in one line each | Repeating the introduction |
| 11 | Future scope | The next real step, named concretely | "Can be extended to many applications" |
| 12 | Thank you / Q&A | Your name and a contact line | Ending on "Any questions?" with no summary |
If your project needs it, add one slide for the demo setup or cost summary — but stay within fifteen. Every slide beyond that is a slide the panel stops reading.
Tip: Write the slide titles first, as a plain list, before designing anything. If the titles alone tell the story — problem, approach, results, limitations — your structure is right. If they don't, no amount of design will fix it.
Slide design rules for a panel sitting five metres away
- One idea per slide. If a slide needs two headings, it is two slides.
- Minimal text. Aim for under 30 words per slide; the explanation comes from your mouth, not the screen.
- Diagrams over paragraphs. A labelled block diagram communicates your system design in seconds; a paragraph describing it takes a minute and loses the room.
- Readable from the back row. Large fonts, high contrast, no light-grey-on-white body text.
- Label your photos. A photo of your hardware is good evidence — but only with labels or arrows pointing at the parts you are talking about. An unlabeled photo of a breadboard tells the panel nothing.
Warning: Never read your slides aloud word for word. The moment you turn around and read the screen, the panel stops listening. Slides are prompts for you and signposts for them — the story lives in what you say.
Show honest results: use baselines, not adjectives
Examiners trust numbers and distrust adjectives. "The system is very accurate" means nothing; "the sensor readings stayed within ±2% of a calibrated multimeter across 50 samples" means everything. Wherever possible, compare against a baseline: manual measurement, the previous version of your system, or a published figure from your literature review. If a result is weaker than you hoped, say so and explain why — a panel will forgive an honest shortfall and punish a hidden one. This is the same honesty that carries your project viva: examiners probe reasoning, not marketing.
Put your limitations on a slide, on purpose
An explicit limitations slide is one of the strongest moves in your deck. It shows you tested your own work critically instead of only demonstrating the happy path. Name two or three genuine limits — range, accuracy under certain conditions, cost, power consumption — and, where you can, what would fix each. Panels ask "what are the limitations?" in almost every viva; having the answer on a slide turns an attack into a showcase.
Rehearse the story, not a script
Avoid memorised scripts. A memorised talk sounds robotic, and one forgotten line can derail the whole presentation. Instead, rehearse until you can talk through each slide from its title and diagram alone — three or four full run-throughs, timed, out loud. Time yourself strictly: if you run over, cut a slide, not your speaking speed. And rehearse the demo separately from the talk, because the demo is where things fail.
Demo-day checklist
- Charge every battery and carry the charger and a spare cable.
- Record a video of the working demo as a backup — if the live demo fails, state what it was meant to show and play the recording.
- Carry your laptop charger, an HDMI adapter, and the presentation on a USB drive as well as in the cloud.
- Arrive early and test the projector, clicker, and audio before your slot.
- Keep a one-page printed summary of your results in case the projector dies entirely.
Close with the next real step
Your closing slide should name the next real step for the project — the concrete thing you or a future student would do next, like "field-test with ten farmers over one season" or "replace the Arduino Uno with an ESP32 to remove the separate Wi-Fi module." A specific next step shows the panel you understand where your work sits in a longer journey. A vague "it can be extended to many applications" shows the opposite.
If you are still shaping the project itself, start with how to choose a final-year project topic and how to write a project synopsis — a clear topic and an approved synopsis make every later slide easier to write.