Project Presentation Guidelines

This page provides practical guidance for preparing and delivering your project presentation, including content selection, slide design, live demos, timing, communication, Q&A, and team preparation.

For presentation dates, submission rules, required content, and grading, see the Presentation section in the project handout.

The presentation emphasizes clarity, understanding, and technical communication, rather than polished delivery. Minor pauses, rewording, and occasional stumbles are completely normal.

The goal is practice, not perfection.

Content Prioritization · Live Demo · Slide Design · Timing & Rehearsal · Communication · Q&A · Team Preparation · Common Pitfalls · Resources

Content Prioritization

You have 6 minutes for the main presentation, which means prioritization matters.

Your primary reference should be the Presentation Rubric. The presentation is evaluated in three areas:

1. Clarity & Communication
2. Technical Progress & Demonstration
3. Advanced Features & Completion Plan

Do not try to show everything your team has done. Instead, choose the evidence and explanations that best help the audience understand:

• what you built;
• why the project or technical choice matters;
• how the important parts of the application work; and
• what evidence demonstrates that they work.

Recommended Structure

A typical 6-minute presentation might follow this flow.

Live Demo Guidance

A meaningful live demonstration is required as described in the Presentation Logistics.

Choose live demonstrations that provide useful technical evidence rather than simply showing that a webpage can be opened.

Good live-demo examples may include:

• interacting with a meaningful end-to-end user flow;
• demonstrating frontend–backend interaction;
• creating, retrieving, updating, or otherwise using database-backed data;
• uploading or retrieving files through cloud storage;
• demonstrating authentication or authorization behavior;
• demonstrating real-time functionality or another advanced feature.

Show Evidence — Don’t Just Make Claims

Whenever possible, demonstrate the technical claim you are making.

Instead of saying:

“Our frontend is connected to the backend.”

show an interaction that causes a real request, mutation, or state change and briefly explain what the audience is seeing.

Similarly, instead of saying:

“We use PostgreSQL for persistent data.”

show meaningful database-backed behavior and explain what information is being stored or retrieved and why it matters to the application.

Keep the Demo Focused

A short presentation is not the right setting for a long step-by-step product walkthrough.

Choose a small number of actions that demonstrate the most important technical ideas.

Ask yourself:

What does the audience need to see in order to believe and understand this claim?

Prepare Backup Material

Network-dependent demonstrations can fail for reasons outside your control.

Prepare short recordings, screenshots, or other backup evidence for components that depend on:

• classroom Wi-Fi;
• cloud storage;
• deployed applications;
• external APIs or third-party services;
• authentication providers; or
• slow or unreliable operations.

Backup material should supplement the required live demonstration rather than replace it entirely.

Slide Design Guidelines

Slides should support your explanation, not make the audience rush to read before the slide changes.

Readability first

Your slides must be easy to read from the back of the classroom.

• Use large, high-contrast fonts.
• Avoid dense text and crowded layouts.
• Ensure labels and text in figures, diagrams, tables, code snippets, and screenshots are clearly visible.
• Avoid screenshots that are too small to interpret.

Practical check: Imagine yourself sitting in the last row.
If you cannot comfortably read the important information on the slide, revise it.

Keep Slides Simple and Focused

• Use bullet points, keywords, or short phrases.
• Avoid full paragraphs.
• Use diagrams or visuals to communicate structure and relationships where appropriate.
• Highlight the specific part of a screenshot, architecture diagram, code snippet, or interface that you want the audience to notice.

A slide should make your explanation easier to follow, not compete with you for the audience’s attention.

One Main Idea at a Time

Avoid trying to communicate several unrelated technical ideas on one slide.

For example, an architecture diagram, a database interaction, and a cloud-storage workflow may each deserve separate attention rather than being compressed into one crowded slide.

Quick Self-Check

Before finalizing your slides, ask:

• If I know nothing about this project, can I understand what this slide is trying to communicate?
• Can someone sitting in the back of the room read the important content?
• Does every element on this slide help me explain something important?
• Am I using the slide as support, or am I expecting the audience to read the presentation for me?

Timing & Rehearsal

You are strongly encouraged to rehearse with your teammates using a timer. Running out of time is one of the most common problems in short presentations.A brief rehearsal can help you identify unnecessary material and awkward transitions before presentation day.

Suggestions

• Practice the complete 6-minute presentation at least once from start to finish.
• Assign rough time budgets to major sections.
• Rehearse live demos and transitions between slides and demo windows.
• Decide in advance who will speak during each section.
• If useful, have one person speak while another operates the demo.
• Practice stopping a demonstration and moving on if something takes longer than expected.
• Make sure your most important technical evidence appears before the end of the presentation.

Do not design a presentation that works only if every transition and demo goes perfectly. Leave yourself some margin.

Communication Expectations

Be Clear and Concise

A strong short presentation needs both.

Clear means the audience can understand your ideas and follow your reasoning.

Concise means you spend your limited time on information that helps the audience understand and evaluate the project.

More detail is not automatically better.

For example, you usually do not need to explain every route, React component, or database table. You do need to explain what the important components do, how they interact, and what evidence shows that they are working.

Explain — Don’t Read

You should be able to explain your project in your own words, rather than reading slides or notes word-for-word.

Briefly glancing at notes is fine, but your slides and notes should support your explanation rather than replace it. You may use:

• slides with short bullet points, keywords, diagrams, and visual evidence; and
• brief notes or cues containing keywords, transitions, or reminders.

Avoid:

• reading sentences or paragraphs word-for-word;
• using slides as a script; and
• keeping your eyes on notes or the screen throughout the presentation.

These behaviors make it harder for the audience to follow your ideas and may signal limited familiarity with your own work.

Rule of thumb: If your notes were taken away, you should still be able to explain the main ideas and give a high-level walkthrough of your application.

This expectation is reflected in the Clarity & Communication component of the rubric.

Explain Technical Meaning

Do not merely narrate what is visible on the screen.

For example, instead of:

“When I click this button, the task appears here.”

explain:

“Submitting this form sends a request to our server, which validates the input and stores the new task in PostgreSQL. The updated task list is then returned to the frontend and rendered without requiring a page reload.”

The audience should understand why the evidence matters, not just what it looks like.

Use Signposting

Short verbal cues can make a technical presentation much easier to follow.

For example:

• “First, I’ll briefly show the overall application architecture.”
• “The key point here is how the frontend and backend interact.”
• “Next, I’ll show how data is stored and retrieved.”
• “Finally, I’ll explain our two advanced features.”

You do not need formal transitions everywhere. A few clear signals help the audience understand where they are in the presentation.

Focus on Understanding, Not Performance Style

Perfect English, polished speaking style, accent, charisma, or memorized wording are not the goal.

The important questions are:

• Can the audience understand your technical story?
• Can you explain why your design works?
• Can you discuss your own project when asked a question?

Aim for clarity over polish.

Q&A: Answering Technical Questions

The presentation is followed by approximately 2 minutes of Q&A with the instructor and TAs.

The purpose is to give you an opportunity to demonstrate your understanding of the project and practice responding to technical questions in real time.

Listen First

Make sure you understand the question before answering. If necessary, briefly clarify what is being asked.

Do not start answering while the question is still being asked.

Answer the Question Directly

Start with the main answer, and then add the reasoning or evidence that supports it.

For example:

“We chose a Next.js full-stack architecture because our frontend and server logic are tightly coupled and the team wanted a single TypeScript codebase. The main tradeoff is that the frontend and backend are less independently deployable than they would be with a separate React and Express architecture.”

This is usually more effective than giving a long background explanation before reaching the answer.

A Useful Answer Structure

For many technical questions, the following structure works well:

1. Direct answer
2. Reason or evidence
3. Tradeoff, limitation, or example, if relevant

Not every answer needs all three parts.

Keep Answers Concise

Q&A time is limited. Answer fully enough to demonstrate understanding, but avoid turning a short question into another presentation.

If the instructor or TA wants more detail, they can ask a follow-up question.

Be Honest About Limitations

You are not expected to have a perfect application or know every possible detail.

If something has not been implemented or tested, say so clearly.

For example:

“We have not yet tested this workflow with multiple simultaneous users. The current design should support it, but we would need additional testing to verify how the shared state behaves under concurrent updates.”

This is a stronger technical answer than guessing.

Similarly, if your team made a tradeoff, you can acknowledge it:

“We chose SQLite because it simplified local development and was sufficient for our expected workload, but it would be less suitable than PostgreSQL if we needed heavier concurrent access.”

Recognizing limitations is part of good engineering judgment.

Understand the Whole Project

Teams may designate one or two members to deliver the main presentation, but all team members should be prepared to participate in Q&A.

Every team member should understand, at an appropriate level:

• the overall application architecture;
• how frontend and backend/server logic interact;
• how application data is stored and accessed;
• how cloud storage is used;
• the purpose of the major advanced features;
• major technical decisions and tradeoffs; and
• important limitations or remaining work.

You do not need to memorize every implementation detail. However, you should be able to explain the major ideas behind your team’s work.

Preparing as a Team

A strong team presentation should feel like one coherent explanation rather than several disconnected mini-presentations.

Before presentation day:

• agree on the overall technical story;
• decide what evidence matters most;
• make sure presenters understand the transitions between sections;
• make sure all members understand the major architecture and technical choices;
• decide how you will handle live demos;
• prepare backup materials;
• discuss likely questions together.

If different people worked on different components, use rehearsal time to explain those components to one another.

This helps prepare everyone for Q&A and also improves the team’s shared understanding of the final application.

Common Pitfalls

Avoid the following:

• spending too much time explaining the project motivation;
• demonstrating ordinary interface interactions while neglecting the web-development requirements;
• trying to show every feature, route, component, or implementation detail;
• using screenshots, diagrams, or code snippets that the audience cannot read;
• saying that something works without showing meaningful evidence;
• using the live demo as a long user tutorial;
• reading slides or a prepared script word-for-word;
• giving long Q&A answers before directly addressing the question;
• pretending to know an answer rather than acknowledging a limitation;
• leaving the most important technical evidence until the final seconds of the presentation.

A focused presentation that clearly explains and demonstrates the important technical work is more effective than an ambitious presentation that tries to cover everything.

Communication Resources

For additional guidance on preparing your presentation, you may review the following optional resources.

Technical Presentation Tips from Prof. Fiona Coll

Prof. Fiona Coll, lead of ISTEP’s Graduate Communication Initiative, previously delivered a 10-minute session specifically for this course on how to prepare an effective time-limited engineering project presentation.

• Recording
• Slides

These resources are optional. The key expectations for this course are summarized on this page and in the Presentation Rubric.

Final Notes

A clear technical presentation is not about perfect wording or memorization.

It is about:

• understanding your own work;
• choosing what matters most to explain;
• providing meaningful evidence;
• communicating those ideas clearly and directly; and
• being able to discuss your technical decisions thoughtfully.

A strong presentation needs to help the audience understand what you built, why it works, and how you know.

Aim for clarity over polish, and use this presentation as an opportunity to practice explaining your work in a professional setting.