Softs were this week, and as we near the end of the semester, I thought I'd write about a few lessons I've learned about presenting our team's work. Over the semester, we've struggled quite a bit to communicate exactly what it is we're doing as a team. And though reception to our game as a work of art has been strong, reception to it as a deliverable that satisfies our client's requirements has been less positive. Our team is still in the process of developing a better communication strategy, but below are a few considerations I feel are important:
1. Make sure your team is all on the same page - It's good for all team members to give a slightly different take on the same project... emphasis on "same project." You can't give contradictory explanations of project goals or the techniques used to accomplish them. Your project shouldn't appear to be the unplanned result of people working together toward diverging goals.
2. Assume your audience is smart, but still provide explanation - Your project might not be easy to understand. That said, do NOT do any of the following: (1) Simplify your explanations so they're easy-to-understand but inaccurate (2) Apologize for the complexity of your explanations or indicate that you don't expect the audience to understand them (this is condescending!) (3) Give up trying to explain and let the audience figure it out themselves (this is a copout and makes it seem like you don't know what you're doing). Basically, you should provide concise and accurate explanations. Don't leave anything important out, but don't repeat yourself and talk down to your audience. This is a balancing act that requires careful refinement, and it might be impossible to satisfy everyone (the same explanation could be considered pretentious by one person and interesting by another--and neither person is "right").
3. Audiences like what they're already familiar with - If you know who you're presenting to, then it's valuable to give them a taste of your project in an informal setting so that they've already digested it a bit when you present to them in a more formal, time-pressured setting. They'll also give you more actionable feedback, as they already understand the project and can thus hone in on particular details in their critique.
4. Don't hype your own thinking - It's good to be enthusiastic, but don't hype your product at a theoretical level (we're revolutionizing XYZ through conceptual technique ABC). Even if your project was equal parts concept and execution--or even if your project was mostly concept and the execution is merely proof-of-concept--people rightly are suspicious of presentations that are "all talk." Even if your client is mostly interested in process, you should tailor your presentation to a general audience.
5. Project confidence in your own work - I'm particularly guilty of violating this advice, because I tend to focus on details that still need refinement--stuff the audience is unlikely to notice during a fifteen minute presentation. If you like your project in its broad strokes--even if you're also sick of it at this point--then *that* is what should come through in your presentation. And self-deprecation as a "chaser" during a complex part of the presentation is... probably not as good an idea as one might think.