Week 10: Demo Day Guide

Demo Day is Week 10 — your session runs at its normal time. Depending on your group: Wednesday May 6, Thursday May 7, or Friday May 8, 2026. Each team gets 10 minutes total: 6 minutes to present, 4 minutes for Q&A.

Slides due: Tuesday May 5, 23:59 via LMO — before any session runs (file: Session[X]Group[Y]_DemoDay.pptx or .pdf).

You must record your own session — use a smartphone or any available camera. Submission is in two steps: slides first, recording link after your session (see checklist below).

---

What Demo Day assesses (40% of your grade)

Demo Day is the single largest component of your grade. It has four parts:

Element	Weight	What assessors look for
Presentation Quality	10%	Clear narrative structure · professional slides · exactly 6 minutes · confident delivery
Prototype Demonstration	15%	Working demo of core use case · core flow completes without errors
User Validation Evidence	10%	Real user testing shown · before/after iteration · specific findings
Technical Q&A	5%	Can explain choices · understands trade-offs · answers confidently

The most important number: User Validation Evidence (10%) is worth double Technical Q&A (5%). A team with a simple product and strong evidence of iteration outscores a team with an impressive prototype and no evidence of learning.

---

What we are looking for — and what we are not

Process over technology

We do not assess how complex your product is, how groundbreaking the idea is, or whether it is “first to market.” We assess whether your team followed a professional product development process.

What scores well:

• Showing a real user couldn’t find X, so you moved it — and testing the fix
• Saying “we originally built Y but users never used it, so we cut it”
• Explaining why you chose your technology stack, not just what it is
• A demo that shows the core use case clearly, without extras

What scores poorly:

• A polished demo with no evidence of user testing
• Validation slides that say “we asked 5 people and they all liked it” with no specifics
• Avoiding questions or saying “I don’t know” without trying to reason through it
• Running over 6 minutes

Uncomfortable truths score higher than glossy prototypes. The rubric rewards honest documentation of what didn’t work and what you changed. A finding like “participants couldn’t complete the task without help, so we redesigned the navigation” is worth more than five positive feedback quotes.

---

The 6-minute story arc

Structure your presentation in this order. Stick to the time allocations — most teams overrun the demo and rush the validation section.

Section	Time	What to say
The problem	1 min	Who has this problem? Why does it matter? End with one real quote from a user you interviewed.
What you built	30 sec	One sentence. What your product does and who it is for.
Live demo	2.5 min	Show the core use case only. Do not explain while demoing — show, then narrate briefly after. Have a backup screenshot or video in case of technical failure.
What users told you	1 min	Two or three specific findings. One before/after: “Users couldn’t do X, so we changed Y — here is the result.”
What comes next	1 min	One honest limitation. One thing you would build if you had more time. This is not a failure — it shows you understand your product.

On the live demo: Choose the one core user journey and demo only that. Do not try to show every feature. If the demo fails live, move to your backup screenshot and keep going — do not apologise or restart.

---

The 4-minute Q&A

Assessors may ask about any part of your work. Common questions:

• “Why did you choose [technology]? What alternatives did you consider?”
• “You showed users had trouble with X — what exactly did you change and why?”
• “If you had another month, what would you build next and why?”
• “How would this work for 1,000 users? What would break?”
• “What is the biggest risk to this product succeeding?”

How to handle a question you cannot answer: Say what you do know, then reason out loud. “I am not certain about the exact number, but based on how we built the database I think…” is a good answer. Saying nothing and looking at teammates is not.

Every team member should be able to answer at least one technical question. Know your own contribution well enough to explain it.

---

Slide structure

There is no required template. Good Demo Day slides typically follow this structure:

1. Title slide — product name, team, session and group number
2. The problem — one slide, one user quote
3. What you built — one slide, one sentence + product name/logo
4. Demo — live, not slides (have one backup screenshot slide)
5. Validation evidence — one or two slides, specific findings + before/after
6. What comes next — one slide, one limitation + one next step

Six to eight slides total. Text on slides should be minimal — you are speaking, not reading.

---

Submission checklist

Submission is two separate steps — do not wait for the recording before submitting slides.

Step 1 — Before Demo Day (due Tuesday May 5, 23:59):

• Slides submitted via LMO (Session[X]Group[Y]_DemoDay.pptx or .pdf)
• Prototype access link included in the LMO submission (URL, APK, or GitHub — must work on the day)

Step 2 — After your session (within 7 days, latest Friday May 15, 23:59):

• Session recorded during Demo Day (start before you present, stop after Q&A)
• Recording uploaded to Mediasite
• Mediasite link added to your existing LMO submission

Both the slides and the recording link are required for a complete submission.

• Backup screenshot or video ready in case of live demo failure
• Each team member knows which section they are presenting
• Timed at least once — stays within 6 minutes
• Q&A rehearsed — each member can explain their contribution

---

On the day

Before you leave for campus:

• Test the demo on the machine you will present from — not a different laptop
• Charge everything: laptop, any hardware, the phone you will use to record
• Have your slides accessible in two places (USB + cloud)
• Know your backup: if the live demo fails, which screenshot or video do you switch to?

In the room:

• Arrive at least 10 minutes before your slot — find the projector cable, test the connection
• One person sets up the laptop. One person holds the recording phone. Agree this before you walk in.
• Start recording before you start presenting. Stop it after Q&A ends.
• If something breaks during the demo: switch to your backup without apologising. Say “let me show you this another way” and keep going. Assessors see this every year — a clean recovery scores better than a frozen screen.

After your session:

• Upload the recording to Mediasite — aim for the same day while it is fresh
• Go back into your LMO submission and add the Mediasite link (you do not need to re-upload your slides — just update the existing submission with the link)
• Deadline: within 7 days of your session, latest Friday May 15, 23:59

---

Grading rubric summary

Quality	Demo Day performance
Outstanding (80–100%)	Polished prototype · compelling presentation · rich validation evidence · confident Q&A
Excellent (70–79%)	Working prototype · clear presentation · adequate validation · handles questions well
Good (60–69%)	Basic functionality · acceptable presentation · some validation shown · struggles with some questions
Satisfactory (40–59%)	Prototype barely works · poor structure · little validation evidence · cannot answer questions
Poor (0–39%)	Non-functional prototype · incoherent presentation · no validation · or did not present

The full rubric is in the Assessment Brief.