Feb 13, 2008
Effective Presentations Skills 1.1
Why? “ I’m a programmer – I don’t need to talk”. Communication to small groups is an essential part of team software development. You need to explain prototype ideas and demos to product managers or business people.
You need to be able to explain designs and your approach to solving problems to other engineers.
Presentation requirements The presentation should be 10-15 minutes long (shorter is better), followed by up to 5 minutes for questions You should (with suggested minutes): Explain the storyline and rules of your game (2 mins, 1 slide) Demonstrate your game (2-4 mins) Describe your game design at a high level (e.g. by showing a class diagram and explaining which class is responsible for which functionality) (3-4 mins, 1-2 slides)
Describe a technical challenge which you encountered during implementation and how you solved it (3-5 mins, 1-2 slides)
Game storyline and rules What is your goal in the game? What are the obstacles/ rules?
e.g. My game’s called “Revenge of the couch potato”. You get to be a crime fighting vegetable setting out to save the Golden Carrot from certain peril. But one obstacle remains – King Tomato is making soup…
What makes a good speaker? Think of an occasion where you have enjoyed listening to a speaker: A memorable lesson at school? Your granny telling you a story? A friend telling you a joke? The best man/bride/groom at a wedding?
What did the speaker do to engage you? How did the speaker draw you in?
Telling a story The slides are NOT the story. They are to help you tell it. The best presentations are mostly pictures/graphics/tables, not much text.
You can direct the audience’s attention by having elements appear/disappear, or text be highlighted.
Presentation marking Presentation will be marked on: Delivery (how you say it)
Use of audio visual aids and demo
Marking - Content Positive: Good explanation of software design, good understanding of the game design problem, clear explanation of game rules, well structured talk, highlighted important points, explained hard ideas well, questions handled well.
Negative: Unclear explanation of software design, poor understanding of the game design problem, unclear explanation of game rules, some technical errors, talk poorly structured.
Marking - delivery Positive: Confident, clear, timing good, consistent pace, amusing, engaging, eye-contact
Negative: Nervous, confused; delivery flat, hesitant, mumbled, voice too quiet, ran overtime, ran undertime, laboured easy material, skimmed difficult material, turned back on audience, obscured screen.
Marking – audio visual aids and demo I Positive: Clear slides, right amount of material per slide, examples well used, diagrams/pictures/tables/graphs well used, game demo well explained
Negative: Omitted illustrative examples, would have benefited from diagrams/pictures/tables/graphs, slides too crowded, fonts too small, background too busy, typos on slides, game demo poorly explained.
Marking – audio visual aids and demo II each slide or group of slides should help you tell a single aspect of your story
you should not normally need to re-show previous slides to tell your story (and never forwards)
Making explanations clear Signposts – statements which indicate the content which will follow (e.g., overview) Frames – statements which show the beginning and ending of sub topics Foci – statements and gestures which highlight important points Links – Statements which link different parts of the talk together, or to audience’s previous knowledge. Summary – end with a summary of the main points of your presentation.
(From Brown, Bull and Pendelbury, 1997)
Examples of structuring I’m going to start by describing my target user group. You will have heard the myth that programmers are boring. But once you’ve seen my game, you can decide whether this is really true. I’ve described the ideas behind my game, so now let’s see what it looks like. This game rule is the most important: You must remember that you need the octopus’s help to fight the lecturer. Remember I mentioned that the map would be randomised? This turned out to be hard. These are the challenges I faced…
I really learned something! I should start assignments early in the future so I have enough time to finish them.
Making explanations interesting Show your own interest in the topic Use examples and analogies which are suitable for the audience If the material is unfamiliar, begin with examples Use a mixture of modes: informal, personal and story-telling (but particularly storytelling) Play on the intellectual curiosity of the audience through the use of puzzles, problems and questions.
(From Brown, Bull and Pendelbury, 1997)
Tips for presenting Don’t write down what you’re going to say and then memorise it verbatim – this sounds very unnatural. Don’t read out loud from pre-prepared notes if you can help it. Practise on your own (computer better than paper) Practise in front of kind friends/the mirror.
Spend extra time practising the beginning and end of your presentation so you project confidence.
More tips Don’t turn your back on the audience, and make eye-contact Check that your audience can hear you when you start
Check that they can read your slides, and the text on your demo (check these beforehand as well as at the presentation)
Audience rapport - presenter Giving a presentation to a small group uses ordinary interpersonal communication skills. (Unlike lecturing!) Look at your audience to check: Are they following along with your argument?
You might find a friendly reassuring face!
Audience rapport - listeners “ The best storytellers are the best listeners” Be supportive to the people in your presentation group Listen and show you’re listening (don’t “listen with your eyes closed”) - Be courteous (don’t talk while the presenter is talking) Be empathetic (it will be your turn soon!) Start a question by commenting on a positive feature of the game or presentation before moving on to a suggestion.
Phrase criticisms as queries or suggestions – remember the presenter has spent longer thinking about this design than you have and you may be wrong.
Handling questions Ensures the rest of the audience heard the question Be open to criticism, suggestions for improvements – try not to be hostile
If you considered the change but rejected it previously, explain your reasoning.