1. Why presentations matter¶
Presentations are part of the SDS320 project process. They help you receive feedback, communicate decisions and show how your project develops over time.
You will present your project twice:
a concept presentation,
a final presentation.
The two presentations have different purposes. The concept presentation explains what you plan to do. The final presentation explains what you implemented, found and learned.
2. Concept presentation¶
The concept presentation focuses on your project plan.
It should explain:
motivation,
research question,
planned data sources,
intended methods,
expected output,
possible bottlenecks.
The goal is to receive feedback early enough to improve the project before most implementation work is completed.
A useful structure is:
1. Project title and motivation
2. Research question
3. Study area and planned data
4. Intended method or workflow
5. Expected output
6. Main risks or bottlenecks
7. Questions for feedbackKeep the presentation focused. At this stage, it is better to be clear about open questions than to pretend that everything is already solved.
3. Final presentation¶
The final presentation focuses on what you actually implemented, found and learned.
It should present:
implemented workflow,
key results,
figures or maps,
interpretation,
limitations,
remaining challenges,
changes from the concept,
decisions made during implementation,
what you would improve with more time.
The final presentation should show development from idea to implemented spatial analytics workflow.
4. Concept vs. final presentation¶
| Concept presentation | Final presentation |
|---|---|
| What I plan to investigate | What I actually investigated |
| Planned data | Data actually used and why |
| Intended method | Implemented workflow and changes |
| Expected output | Actual output and key result |
| Possible bottlenecks | Real challenges and how I responded |
| Questions for feedback | Limitations and next steps |
A strong final presentation is honest about changes. If your project became smaller, explain why. If you changed methods, explain what you learned. If the output is limited, explain what can and cannot be concluded.
5. Possible presentation formats¶
Suitable formats include:
short live demo,
repository walkthrough,
workflow diagram,
key result explanation,
before/after comparison,
focused discussion of limitations,
comparison between planned and final implementation.
Live demos can be useful, but they can also fail or take too long. Keep them short and have screenshots or figures as backup.
6. Slide structure¶
A possible final-presentation slide outline is:
1. Title and project question
2. Motivation and study area
3. Data sources
4. Workflow diagram
5. Method and implementation
6. Key result figure or map
7. Evaluation or plausibility check
8. Limitations and uncertainty
9. What changed from the concept
10. Conclusion and next stepsThis is a recommendation, not a rule. Adapt it to your project and time limit.
UZH presentation templates are available from the Corporate Design website:
https://
7. Designing presentation visuals¶
Use figures and maps that are readable from a distance.
Check:
title is clear,
labels are readable,
legend is simple,
colours are interpretable,
main message is visible,
map has enough context,
figure is not overloaded,
limitation is mentioned where needed.
For more, see Figures and maps.
8. Explaining limitations¶
Limitations show that you understand your data, method and result.
Useful phrasing:
This result should be interpreted carefully because ...
The main uncertainty comes from ...
The workflow worked for ..., but not yet for ...
With more time, I would improve ...9. Flags & checks¶
| Red flag | First check |
|---|---|
| Too much background | Move quickly to the project question. |
| The research question is unclear | State it early and return to it at the end. |
| Too many figures | Select only visuals that support the main story. |
| No workflow explanation | Include a simple workflow diagram. |
| Method and result are disconnected | Explain how the method produced the output. |
| No limitations | Discuss uncertainty, data limits or implementation limits. |
| Final presentation repeats the concept | Focus on what changed, what worked and what you learned. |
| Live demo is too long | Use a short demo or screenshots as backup. |
| Repository is not mentioned | Show where the main workflow and README are located. |
10. Mini task¶
Write a one-minute explanation of your project.
My project investigates ...
This matters because ...
I use ...
My workflow ...
The main result shows ...
The main limitation is ...Read it aloud. If it takes too long or feels unclear, simplify the project story.
11. Key takeaways¶
The concept presentation is for feedback on the plan.
The final presentation explains implementation, results and learning.
The final presentation should show development, not repetition.
Clear figures, a workflow diagram and honest limitations make the presentation stronger.
Your audience should understand what you asked, what you did, what you found and what remains uncertain.