Require
Upcoming SlideShare
Loading in...5
×
 

Require

on

  • 650 views

EFFECTIVE PRESENTATION

EFFECTIVE PRESENTATION

Statistics

Views

Total Views
650
Views on SlideShare
650
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Require Require Presentation Transcript

  • Effective Presentations Skills 1.1
  • Why?
    • “ I’m a programmer – I don’t need to talk”.
    • Yes, you do!
    • 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.
  • Outline
    • Presentation requirements
    • Hints for presentations
    • Peer feedback
    • Practice!
  • 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
    • Describe
      • Who do you get to be?
      • What do you get to do?
      • 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
    • You are 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:
      • Content (what you say)
      • 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
    • Cohesion
      • each slide or group of slides should help you tell a single aspect of your story
    • Coupling
      • you should not normally need to re-show previous slides to tell your story (and never forwards)
  • Making explanations clear
    • Structuring tactics:
    • 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
    • Signpost:
      • 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.
    • Frames:
      • I’ve described the ideas behind my game, so now let’s see what it looks like.
    • Focus:
      • This game rule is the most important: You must remember that you need the octopus’s help to fight the lecturer.
    • Links:
      • Remember I mentioned that the map would be randomised? This turned out to be hard. These are the challenges I faced…
    • Summary:
      • 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:
      • Do they look puzzled?
      • Do they look interested?
      • Are they following along with your argument?
      • Are they “on your side”?
    • 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
    • Paraphrase the question
      • Ensures the rest of the audience heard the question
      • Gives you time to think
    • Be open to criticism, suggestions for improvements – try not to be hostile
    • If you considered the change but rejected it previously, explain your reasoning.