Your SlideShare is downloading. ×
0
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Require
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Require

390

Published on

EFFECTIVE PRESENTATION

EFFECTIVE PRESENTATION

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
390
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. Effective Presentations Skills 1.1
    • 2. Why? <ul><li>“ I’m a programmer – I don’t need to talk”. </li></ul><ul><li>Yes, you do! </li></ul><ul><li>Communication to small groups is an essential part of team software development. </li></ul><ul><li>You need to explain prototype ideas and demos to product managers or business people. </li></ul><ul><li>You need to be able to explain designs and your approach to solving problems to other engineers. </li></ul>
    • 3. Outline <ul><li>Presentation requirements </li></ul><ul><li>Hints for presentations </li></ul><ul><li>Peer feedback </li></ul><ul><li>Practice! </li></ul>
    • 4. Presentation requirements <ul><li>The presentation should be 10-15 minutes long (shorter is better), followed by up to 5 minutes for questions </li></ul><ul><li>You should (with suggested minutes): </li></ul><ul><ul><li>Explain the storyline and rules of your game (2 mins, 1 slide) </li></ul></ul><ul><ul><li>Demonstrate your game (2-4 mins) </li></ul></ul><ul><ul><li>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) </li></ul></ul><ul><ul><li>Describe a technical challenge which you encountered during implementation and how you solved it (3-5 mins, 1-2 slides) </li></ul></ul>
    • 5. Game storyline and rules <ul><li>Describe </li></ul><ul><ul><li>Who do you get to be? </li></ul></ul><ul><ul><li>What do you get to do? </li></ul></ul><ul><ul><li>What is your goal in the game? </li></ul></ul><ul><ul><li>What are the obstacles/ rules? </li></ul></ul><ul><li>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… </li></ul>
    • 6. What makes a good speaker? <ul><li>Think of an occasion where you have enjoyed listening to a speaker: </li></ul><ul><ul><li>A memorable lesson at school? </li></ul></ul><ul><ul><li>Your granny telling you a story? </li></ul></ul><ul><ul><li>A friend telling you a joke? </li></ul></ul><ul><ul><li>The best man/bride/groom at a wedding? </li></ul></ul><ul><li>What did the speaker do to engage you? How did the speaker draw you in? </li></ul>
    • 7. Telling a story <ul><li>You are telling a story. </li></ul><ul><li>The slides are NOT the story. They are to help you tell it. </li></ul><ul><li>The best presentations are mostly pictures/graphics/tables, not much text. </li></ul><ul><li>You can direct the audience’s attention by having elements appear/disappear, or text be highlighted. </li></ul>
    • 8. Presentation marking <ul><li>Presentation will be marked on: </li></ul><ul><ul><li>Content (what you say) </li></ul></ul><ul><ul><li>Delivery (how you say it) </li></ul></ul><ul><ul><li>Use of audio visual aids and demo </li></ul></ul>
    • 9. Marking - Content <ul><li>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. </li></ul><ul><li>Negative: Unclear explanation of software design, poor understanding of the game design problem, unclear explanation of game rules, some technical errors, talk poorly structured. </li></ul>
    • 10. Marking - delivery <ul><li>Positive: Confident, clear, timing good, consistent pace, amusing, engaging, eye-contact </li></ul><ul><li>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. </li></ul>
    • 11. Marking – audio visual aids and demo I <ul><li>Positive: Clear slides, right amount of material per slide, examples well used, diagrams/pictures/tables/graphs well used, game demo well explained </li></ul><ul><li>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. </li></ul>
    • 12. Marking – audio visual aids and demo II <ul><li>Cohesion </li></ul><ul><ul><li>each slide or group of slides should help you tell a single aspect of your story </li></ul></ul><ul><li>Coupling </li></ul><ul><ul><li>you should not normally need to re-show previous slides to tell your story (and never forwards) </li></ul></ul>
    • 13. Making explanations clear <ul><li>Structuring tactics: </li></ul><ul><li>Signposts – statements which indicate the content which will follow (e.g., overview) </li></ul><ul><li>Frames – statements which show the beginning and ending of sub topics </li></ul><ul><li>Foci – statements and gestures which highlight important points </li></ul><ul><li>Links – Statements which link different parts of the talk together, or to audience’s previous knowledge. </li></ul><ul><li>Summary – end with a summary of the main points of your presentation. </li></ul><ul><li>(From Brown, Bull and Pendelbury, 1997) </li></ul>
    • 14. Examples of structuring <ul><li>Signpost: </li></ul><ul><ul><li>I’m going to start by describing my target user group. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>Frames: </li></ul><ul><ul><li>I’ve described the ideas behind my game, so now let’s see what it looks like. </li></ul></ul><ul><li>Focus: </li></ul><ul><ul><li>This game rule is the most important: You must remember that you need the octopus’s help to fight the lecturer. </li></ul></ul><ul><li>Links: </li></ul><ul><ul><li>Remember I mentioned that the map would be randomised? This turned out to be hard. These are the challenges I faced… </li></ul></ul><ul><li>Summary: </li></ul><ul><ul><li>I really learned something! I should start assignments early in the future so I have enough time to finish them.  </li></ul></ul>
    • 15. Making explanations interesting <ul><li>Show your own interest in the topic </li></ul><ul><li>Use examples and analogies which are suitable for the audience </li></ul><ul><li>If the material is unfamiliar, begin with examples </li></ul><ul><li>Use a mixture of modes: informal, personal and story-telling (but particularly storytelling) </li></ul><ul><li>Play on the intellectual curiosity of the audience through the use of puzzles, problems and questions. </li></ul><ul><li>(From Brown, Bull and Pendelbury, 1997) </li></ul>
    • 16. Tips for presenting <ul><li>Don’t write down what you’re going to say and then memorise it verbatim – this sounds very unnatural. </li></ul><ul><li>Don’t read out loud from pre-prepared notes if you can help it. </li></ul><ul><li>Practise on your own (computer better than paper) </li></ul><ul><li>Practise in front of kind friends/the mirror. </li></ul><ul><li>Spend extra time practising the beginning and end of your presentation so you project confidence. </li></ul>
    • 17. More tips <ul><li>Don’t turn your back on the audience, and make eye-contact </li></ul><ul><li>Check that your audience can hear you when you start </li></ul><ul><li>Check that they can read your slides, and the text on your demo (check these beforehand as well as at the presentation) </li></ul>
    • 18. Audience rapport - presenter <ul><li>Giving a presentation to a small group uses ordinary interpersonal communication skills. (Unlike lecturing!) </li></ul><ul><li>Look at your audience to check: </li></ul><ul><ul><li>Do they look puzzled? </li></ul></ul><ul><ul><li>Do they look interested? </li></ul></ul><ul><ul><li>Are they following along with your argument? </li></ul></ul><ul><ul><li>Are they “on your side”? </li></ul></ul><ul><li>You might find a friendly reassuring face! </li></ul>
    • 19. Audience rapport - listeners <ul><li>“ The best storytellers are the best listeners”  </li></ul><ul><li>Be supportive to the people in your presentation group </li></ul><ul><ul><li>Listen and show you’re listening (don’t “listen with your eyes closed”) </li></ul></ul><ul><ul><li>- Be courteous (don’t talk while the presenter is talking) </li></ul></ul><ul><ul><li>Be empathetic (it will be your turn soon!) </li></ul></ul><ul><li>Start a question by commenting on a positive feature of the game or presentation before moving on to a suggestion. </li></ul><ul><li>Phrase criticisms as queries or suggestions – remember the presenter has spent longer thinking about this design than you have and you may be wrong. </li></ul>
    • 20. Handling questions <ul><li>Paraphrase the question </li></ul><ul><ul><li>Ensures the rest of the audience heard the question </li></ul></ul><ul><ul><li>Gives you time to think </li></ul></ul><ul><li>Be open to criticism, suggestions for improvements – try not to be hostile </li></ul><ul><li>If you considered the change but rejected it previously, explain your reasoning. </li></ul>

    ×