A capstone presentation outline should follow the life of the project rather than the shape of a research paper: problem, requirements, design, implementation, demo, testing and results, then lessons and next steps. For a 15- to 20-minute senior capstone presentation that usually means 12 to 15 slides plus a few minutes of demo, with every claim about the system backed by a test or a live run. Faculty and sponsors want to see that you understood the problem, made sensible design choices and built something that works. Below: how a capstone differs from a thesis defense, a slide-order table, examples for the key slides, live demo versus video backup, team roles, common grading themes and an AI workflow.
How a capstone presentation differs from a thesis defense
A thesis defense argues that a finding is credible. A capstone or design project presentation argues that a solution works and meets its requirements:
| Thesis defense | Capstone or design project | |
|---|---|---|
| Core question | Is the research sound and the finding credible? | Does what you built solve the problem, and how do you know? |
| Starting point | A gap in existing research | A problem statement, client brief or user need |
| Middle of the talk | Method, results, analysis | Requirements, design, implementation |
| Evidence | Experiments and data analysis | Demo, testing against requirements, user feedback |
| Typical extras | Literature review, contributions | Constraints, design trade-offs, project management, team roles |
| Audience | A committee of academics | Faculty, sometimes with a client or industry sponsor |
If your project is closer to a research thesis, our thesis defense slides guide may fit better.
A capstone presentation outline: slide order
This order suits a 15- to 20-minute slot with a live demo. Adapt it to your course brief:
| # | Slide | What goes on it | Time |
|---|---|---|---|
| 1 | Title | Project name, team, advisor or sponsor, course | 15 sec |
| 2 | Problem | Who has the problem and what it costs them | 1 min |
| 3 | Requirements | Key functional and non-functional requirements, constraints | 1.5 min |
| 4 | Existing options | What people use now and where it falls short | 1 min |
| 5 | Design overview | System architecture or concept diagram | 2 min |
| 6 | Key design decisions | Two or three decisions, with the alternatives considered | 1.5 min |
| 7 | Implementation | Components built, tools used, what was reused | 1 min |
| 8 | Demo | Live core flow, with a video backup ready | 3–4 min |
| 9 | Testing | Test plan mapped to requirements | 1.5 min |
| 10 | Results | Requirements met, partly met and not met | 1.5 min |
| 11 | Challenges and lessons | What went wrong and what you changed | 1 min |
| 12 | Future work | Next steps and what the client or next team receives | 45 sec |
| 13 | Thanks and questions | Team, sponsor, advisor | 15 sec |
Protect the demo and testing time; they carry the most weight. For a slot nearer 10 minutes, merge requirements into the problem slide, cut existing options to one line and keep the demo to two minutes.
Writing the key slides, with examples
To make the examples concrete, imagine a team that built a room-booking app for a campus library:
- Problem. Not "Library booking system", but a title that names who struggles and how: "Students give up on group rooms because booking happens at the desk." Add one line of evidence you gathered, such as interview notes.
- Requirements. A short table of the requirements that matter, each with how you will verify it: "Book a room within a minute on a phone, checked by timed user tests." Separate must-haves from nice-to-haves.
- Design overview. One diagram with labeled components and data flow, showing which parts you built and which you reused.
- Key design decisions. Each decision with the alternative you rejected: "We chose a web app over a native app so it runs on any phone without installs."
- Testing. A three-column table, requirement, test and result, reads faster than a list of test cases.
- Results. State plainly what was met, partly met and not met. "Core booking flow meets all must-haves; calendar sync is partial" is more credible than "Results".
Keep one idea per slide and let the titles carry the argument.
Live demo vs video backup
A live demo is persuasive and fragile. A common approach is to plan both:
- Script the core flow. Pick the one path that proves the main requirement and rehearse it until it takes the same time on every run.
- Record a backup video of the same flow. Keep it short, embed it in the deck or have it open in a player.
- Prepare the environment. Use seeded test data and a ready test account, run a local build if the network is uncertain, and silence notifications.
- Rehearse the switch. Decide in advance when you will cut to video if something fails, and practise one calm sentence for the switch.
- Cover hardware risks. For physical prototypes, bring photos and a short clip in case the device misbehaves.
If the room, network or slot is uncertain, opening with the video and doing live interaction during questions is a reasonable choice.
Team capstones: who presents what
Split by section, not by slide. One way to divide a team of four:
| Speaker | Sections | Also owns |
|---|---|---|
| A | Title, problem, requirements | Opening and closing |
| B | Design overview, key decisions | Architecture questions |
| C | Implementation, demo | Running the demo and the backup video |
| D | Testing, results, lessons | Data and test questions |
- Hand over with one sentence that names the next speaker and section.
- Show who did what on a team slide if your course asks for it.
- Everyone should be able to answer questions on the whole project.
- Rehearse together at least twice with the real handovers.
Follow any course rules on who must speak. Our group presentation guide has more on dividing a talk.
What graders commonly look for
Rubrics differ by course, program and sponsor, so read yours before building slides. As general guidance, criteria often touch on these themes:
- Problem and requirements. Clear, specific and grounded in real users or a real client.
- Design reasoning. Decisions justified, with alternatives and trade-offs considered.
- Working system. A demo that shows the core functionality the requirements promise.
- Testing and evidence. Claims backed by tests, measurements or user feedback.
- Teamwork and project management. Work planned, divided and adjusted sensibly.
- Communication. Clear slides, on time, questions handled well.
To use your rubric, list each criterion, assign it a slide or a moment in the talk, and check in rehearsal that a grader could score every item from what they saw. Common mistakes include listing tools without reasons, demoing features the requirements do not mention and skipping testing.
From project report to editable slides with AI
Your final report or design document already holds the content; the slides are selection and layout. In our AI slide studio:
- Pick the source. Use the final report, or combine the requirements, design document and test summary under clear headings.
- Upload, paste or import. Upload a .docx, .pdf, .txt or .md file, paste up to 100,000 characters, or import a web page such as your project documentation by URL. Text-based PDFs are read in your browser; scanned PDFs need OCR or pasted text.
- Edit the outline. The AI drafts a slide-by-slide outline first, and drafting it uses no credits. Reorder it to the slide order above, add demo and backup-video slides and delete anything that does not earn its time. What you confirm is exactly what gets generated (why outline first).
- Generate. Decks run from 3 to 40 slides at 2 credits per slide, AI images included, and the cost is shown first: 13 slides is 26 credits. Generation takes about one to three minutes, and credits come back automatically if it fails. Credit packs start at $5 for 150 credits; monthly plans start at $9.
- Export and finish as a team. Download an editable PPTX with real text boxes, so each speaker can edit their sections in PowerPoint, Keynote (via import) or WPS; PDF and PNG exports are also available. Exports carry a small "AI-generated" label. Add real screenshots and your demo video, and check every number against your test results.
The AI organises your report and does not invent test results, data or references. You get a high-quality, editable first draft. See editable PPTX vs image slides for why editability matters for team decks, and check your course's rules on AI tools.
FAQ
How many slides should a capstone presentation have?
For a 15- to 20-minute capstone presentation, 12 to 15 slides is a common range, with the demo counted as a block of time rather than as slides. A slot of about 10 minutes works with 8 to 10 slides. Your course sets the time limit, so build from that and rehearse to finish slightly early.
Should I do a live demo or play a recorded video in my capstone presentation?
A common approach is to plan both: a short live demo of the core user flow, plus a recorded video of the same flow ready to play if anything fails. Rehearse the switch so it takes seconds. If the room, network or hardware is uncertain, opening with the video and doing live interaction during questions is a reasonable choice.
How do you split a capstone presentation between team members?
Split by section, not by slide: for example, one person on the problem and requirements, one on design, one on implementation and the demo, and one on testing and results. Keep handovers to one sentence, have one person open and close, and make sure everyone can answer questions about the whole project. Follow any course rules on who must speak.
What do capstone graders usually look for?
Criteria vary by course, so read your rubric first. Common themes are clear problems and requirements, justified design decisions, a system that works as shown, testing backed by evidence, sensible teamwork and clear communication under questions. Map each criterion to a slide or a moment in your talk so nothing is missed.
Editorial Team