Project Presentation Guidelines

This page provides practical guidance on preparing and delivering your project presentation. It complements the Presentation section in the project handout, which outlines dates, submission rules, required content, and grading. The focus here is on making effective choices about content, slide design, timing, and delivery.

The presentation is intentionally low stakes. The emphasis is on clarity and understanding, not polished performance. Minor pauses, rewording, or small stumbles are normal and expected.

The goal of this presentation is practice, not perfection.

Content Prioritization (What to Cover)

You have 6 minutes, which means prioritization matters.

Your primary reference should be the presentation rubric. Use it as a checklist to decide what deserves the most attention.

For this course project, the highest priority is demonstrating and explaining the core technical requirements.

Recommended structure (example)

A typical 6-minute presentation might follow this flow:

• Brief project overview

  • What problem your application addresses
  • Who the target users are
  • What your application enables users to do

• System overview: Give a high-level view of how your system is structured. You might include:

  • Overall architecture (Next.js full-stack or React + Express)
  • Major components (frontend, backend, database, storage)
  • How data flows through the system
  • Where state lives (client state, server state, database)

• Core technical requirements (main focus): Spend most of your time here. This is where the majority of presentation points come from.

• Advanced features: Present at least two advanced features

  • If implemented: briefly demonstrate and explain their role in the system
  • If not yet implemented: clearly explain the intended behavior with a diagram, mockup, or partial implementation, and present a concrete, feasible plan for completion by the final deadline

You do not need to explain every implementation detail or walk through how to use individual features step by step. A common pitfall is spending too much time demonstrating how a single feature works, at the expense of showing how the system as a whole meets the course project requirements.

Instead, focus on clearly demonstrating that the core technical requirements are implemented, functional, and well understood, and that advanced features are thoughtfully designed and on track.

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 all labels and text in figures, diagrams, and tables are clearly visible
• Avoid screenshots that are too small to read

Practical check: Imagine yourself sitting in the last row. If you cannot comfortably read everything 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 show structure and relationships when possible

Well-designed slides help the audience follow your ideas, rather than read content word-for-word.

Quick self-check

Before finalizing your slides, ask yourself:

• If I know nothing about this project, would these slides help me understand what it does and how it works?
• If I am sitting in the last row of the classroom, can I clearly see and follow everything on the screen?

Timing & Rehearsal

You are strongly encouraged to rehearse with your teammates using a timer. Running out of time is one of the most common issues in short presentations. A brief rehearsal can help you identify and fix timing problems early.

Suggestions:

• Practice the full presentation at least once from start to finish
• Assign rough time budgets to major sections
• Rehearse demos or recorded clips
• Decide in advance who transitions between sections
• For demos, consider having one person speak while another operates the app

Communication Expectations (Delivery)

Core expectation

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

Briefly glancing at notes is fine. Reading continuously from notes or slides is not.

Rule of thumb: If your notes were taken away, you should still be able to explain what you built and why.

Acceptable preparation (recommended)

You may use supporting materials to guide your presentation, not to read aloud.

• Slides: bullet points or short phrases that show structure and key ideas
  (not full sentences or paragraphs)

• Notes / cues: keywords, outlines, or transition reminders
  (glance occasionally; do not read verbatim)

What is discouraged

• Reading sentences or paragraphs word-for-word
• Using slides as a script
• Keeping your eyes on notes or the screen all the time

These behaviors make it difficult for the audience to follow your ideas and signal uncertainty about your own work.

This expectation is reflected in the Clarity of Presentation component of the rubric.

Final Notes

A clear presentation is not about perfect wording or memorization.

It is about:

• understanding your own work,
• choosing what matters most to explain,
• and communicating those ideas clearly and directly.

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