You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: org-cyf-guides/content/presenting/demoing/index.md
+48Lines changed: 48 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,3 +59,51 @@ Make sure everyone is talking for about the same amount of time. Don't let one p
59
59
If you're handling questions, make sure everyone answers similar numbers of questions. One person shouldn't answer most of them.
60
60
61
61
**Don't ever swap laptops**. Have everyone present from the same laptop.
62
+
63
+
## Giving feedback to a demo
64
+
65
+
At CYF we all have a responsibility to give good feedback to our peers when they present a demo. That's regardless of being staff, trainee, volunteer etc. Because of this we should all know what good, supportive feedback looks like.
66
+
67
+
Good feedback has two components: what you say and how you say it.
68
+
69
+
### What feedback to give
70
+
71
+
Demos might have a variety of different purposes. It's important your feedback adapts to the goals of someone's demo. If that goal is not clear, that could be a good piece of feedback in itself!
72
+
73
+
Things you might give feedback on:
74
+
75
+
1.**Practical setup**
76
+
77
+
Do they need to spend more time opening new tabs or finding code? Do they have to do data entry to show the feature they are talking about? Are they ready to go, with {{<tooltiptext="artifacts"title="Artifacts">}}Artifacts can be anything used in the demo to show work e.g. an app, website, code snippet, Slack thread, data etc.{{</tooltip>}} pre-loaded and slick transitions between artifacts? Is their screen-sharing clear, zoomed in well enough, hiding any extra windows?
78
+
79
+
1.**Did you follow the demonstration?**
80
+
81
+
Demos should be accessible to audiences, not assuming too much knowledge from them. So if something wasn't clear, it is often a valid area to highlight. Maybe they skimmed over terms that needed defining. Perhaps they did not provide context to the problem they solved. Maybe too much detail was included and the demo lost direction as a result.
82
+
83
+
1.**Did you hear the WHAT and WHY?**
84
+
85
+
We should know "**what** are they showing us" and "**why** this is significant". To know if this is done right, a good thing to think is "Can I explain what they showed me and why?" - if you can't then the demo may not have given enough context.
86
+
87
+
### How to give feedback
88
+
89
+
1.**Stay constructive**
90
+
91
+
Whilst it feels nice to just focus on the good bits of a demo, a presenter does need to know what could've been better. To help keep your feedback "constructive" think about "What would I have done differently?" as well as the usual question of "What did they do well?". This should help give you some key points that they can fold into their demo for next time.
92
+
93
+
1.**Use "I" statements**
94
+
95
+
It's often easier for someone to hear constructive criticism when it's given as an "I" statement more than a "You" statement. E.g. "I felt like there was a lot of text on the slides" can be easier to receive than "You put too much text on your slide".
96
+
97
+
1.**Highlight what went well!**
98
+
99
+
Specific praise helps good behaviour become repeatable — and we often don't realise what we're doing well until it is named by the people around us.
100
+
101
+
1.**Keep your comments easy to understand**
102
+
103
+
Try to make sure the person receiving your feedback can understand why you're giving that feedback. Make it easy to digest, a headline takeaway for them so they can remember the feedback later.
104
+
105
+
1.**Share the space**
106
+
107
+
This point really depends on how many people are part of the demo session. If you're in a big group of people (5+ people listening) then it's worth picking one or two points of feedback before letting someone else speak.
108
+
109
+
In the same vein, if you are always giving feedback first, let someone else lead for the next round of feedback.
0 commit comments