Skip to content

Final Presentation Checklist

I2G Checklist — Spring 2026

Use this checklist to prepare your final presentation. Each section corresponds to specific slides and covers what must be included.

Presentation length: 12 minutes MAX

Title Slide & File Format

Title Slide (Slide 1)

  • Project title matches exactly the title provided in the 26S CSE120 Project Summaries.pdf file
  • Team name appears as the chosen team name followed by the team number in parenthesis using the CSE-3XX format (e.g., "MyTeamName (CSE-342)")
  • Project Partner name is listed (e.g., "Project Partner: ClientName")
  • All mentor names are listed (e.g., "Mentor: MentorName")
  • I2G logo is present in the top-left corner
  • UC Merced SoE logo is present in the top-right corner

Part 1: Introduction & Context

~3 minutes

Team Introduction (Slide 2)

  • Team member names, photos, and roles are listed on the slide
  • Technical roles are listed first if a member has multiple roles
  • Contact info (preferably LinkedIn QR code) is included for each member
  • Keep narration brief — just state your name (role/contact info is on the slide)

Project Partner (Slide 3)

  • Briefly explain who the project partner is and what they do in general
  • Explain the project partner's business operations as they relate to the project
  • Do NOT spend time on the project partner's history, successes, or advertise for them

Problem & Motivation (Slide 4)

  • Problem space and context are clearly explained — do not rush this part
  • Relevant pictures are used to explain the problem and context (REQUIRED)
  • All lesser-known or industry-specific terms and abbreviations are expanded and explained
  • Project partner's motivation is established — why the problem is relevant and how the app helps them
  • Numbers or broader impact are shown if possible (e.g., cost savings, other industries)
  • Existing solutions discussed and why they are not suitable (if time permits)
  • Do NOT assume the audience knows your domain terminology

Goals & Requirements (Slide 5)

  • Overarching project goal and desired outcome are presented (big picture, not specifics)
  • Required features are listed from highest to lowest priority
  • Bonus features are listed from highest to lowest priority
  • Delivered features are clearly indicated (e.g., check marks via animation or a second slide)
  • Check marks appear AFTER presenting the requirements (use animation)
  • Brief explanation provided for any changed or missing features
  • Clear connection shown from requirements back to the problem statement

Software Stack (Slide 6)

  • Stack is presented in layers: frontend, logic, backend, database
  • IDE is NOT included in the software stack
  • Brief motivation and justification provided for the platform choice
  • Lesser-known libraries, packages, tools, and services are explained
  • Do NOT spend much time explaining well-known components (React, Flask, Node, etc.)

Note: Explain your solution ONLY AFTER introducing the problem, goals, requirements, and delivered features.

Part 2: Architecture & Demo

~5 minutes

System Architecture (Slide 7)

  • High-level architecture diagram is included showing how major components are organized
  • Client-facing layer (what the user interacts with) is depicted
  • Backend/server layer (application logic, API endpoints) is depicted
  • Data and storage layer (databases, file storage) is depicted
  • If using a vision model: show model serving, weight loading, image preprocessing, and postprocessing
  • If using an LLM: show orchestration layer, prompt construction, context assembly, response parsing, and external LLM API; show RAG pipeline if applicable
  • Labeled boxes represent each major component
  • Arrows indicate direction of data flow, labeled where helpful (e.g., HTTP requests, tensors, prompts)
  • Clearly bounded regions group related parts of the system
  • Any novelty in the application is depicted and explained in the diagram

Application Data (Slide 8 — if applicable)

  • If data-centric: explain what the input/output data looks like and the information it conveys
  • If data is provided by the project partner, explain it before the demo using slides
  • If data is generated/parsed by the app, show it during the demo

Demo Video (Slide 9)

  • Demo video is embedded directly in the presentation (NOT a link — this is a requirement)
  • Demo video includes closed captions
  • Video is stretched to span the full slide (no logos/title/footer needed on this slide)
  • A clear sample workflow is stated at the beginning of the demo
  • Demo is shown from the perspective of a specific user role (e.g., technician, administrator — NOT generic "user")
  • All delivered features from Slide 5 are shown deliberately and not lost to the audience
  • Inputs/search terms used are meaningful and explained as they are entered
  • Tables shown on screen: column titles, example rows, and conveyed information are explained
  • Graphs shown on screen: units and information conveyed are explained
  • Organization of displayed information is explained if relevant
  • Main/selling-point features get more time; common features (e.g., login) are kept brief unless core
  • No personal information visible: browser tabs, bookmarks bar, taskbar/dock, email inbox, wallpaper, or background apps are all hidden
  • No notifications pop up or sound during the recording
  • Technical details (code, console) are clearly separated from the user-facing workflow and prefaced with narration explaining the difference (if shown)
  • Speaker's face or name overlay is shown during the demo (recommended for engagement)

Note: Keep the audience's perspective in mind — they are seeing this for the first time. Explain everything shown on screen, even briefly.

Part 3: Challenges & Future

~3.5 minutes

Technical Challenges & Solutions (Slide 10)

  • One or more specific and significant technical challenges are presented
  • Each challenge is immediately followed by how the team resolved it before moving to the next
  • Challenges are genuinely technical (NOT merge conflicts, refactoring from poor decisions, or lack of experience/knowledge)
  • Feature creep due to project partner miscommunication is NOT presented as a technical challenge
  • Design patterns or design revisions are discussed if relevant

Team Challenges & Solutions (Slide 11)

  • One or more team/collaboration challenges are presented
  • Each challenge is immediately followed by how the team resolved it
  • Challenges cover relevant factors: division of labor, coordination, communication, decision making, conflict resolution, accountability, time management, etc.

Team Successes (Slide 12)

  • One or more aspects that worked well are presented
  • Successes cover relevant factors: communication, knowledge sharing, coordination strategies, mentor communication, team cohesion, leadership, etc.

Future Work (Slide 13)

  • Short-term goals (1 month / 1 iteration) are presented: missing features, polishing, deployment, production readiness
  • Long-term goals (2–3 months / more iterations) are presented: complex features, new features beyond project partner requirements, broader industry applications, startup/market readiness

Part 4: Conclusion

~0.5 minutes

Conclusion (Slide 14)

  • Explain why the project partner will want to use the application — what makes it stand out
  • Highlight standout qualities: extensibility, scalability, industry-standard tech, responsive UI, cost-effectiveness, security, robustness, testing, documentation, etc.
  • Address competing off-the-shelf products and how your product wins against them
  • Discuss how the application can be applied to other industry sectors
  • End with a call to action — invite the audience to connect, discuss future development, or explore opportunities
  • Do NOT abruptly end with just "Thank you, any questions?" — wrap up with your team name and impact statement

Closing Slide (Slide 15)

  • Final slide includes project title, team name with team number in parenthesis in CSE-3XX format, project partner, and mentor(s)
  • All team members listed again with roles and contact info (LinkedIn QR codes)

Formatting & Slide Requirements

All slides

Slide Template Compliance

  • Presentation file is in .pptx format (PowerPoint)
  • I2G logo appears on each page (except the demo slide)
  • UC Merced SoE logo appears on each page (except the demo slide)
  • Footer on each page: "TeamName (CSE-3XX) | Project Title | ProjectPartnerName"
  • Slide number on each page
  • Title slide uses format: TeamName (CSE-3XX) where XX is your specific team number
  • Presentation is 12 minutes MAX

General Quality

  • Slides are not too sparse or too dense — information is displayed, not just spoken
  • Specific user roles are used instead of generic terms like "user", "customer", or "client"
  • Gender-neutral pronouns are used (they/them or she/her)
  • Novelty of the solution is highlighted throughout the presentation where relevant (not just at the end)
  • Algorithms, models, or databases used are clearly explained with slides, images, or diagrams
  • Tone is professional and energetic — the team sounds excited about what they built
  • File naming convention follows the instructions in the 26S CSE120 I2G Deliverable Details and File Upload.pdf document