Tom Erickson
  home •• pubs essays  HCI Remixed HICSS PC patterns  Apple Human Interface Alumni page

On Designing Design Presentations

Thomas Erickson

circa 1994

This was originally a note written to students who had just given a final presentation of their quarter's design work, and who were about to receive a critique on it.

There will undoubtedly be a number of cases in which I say 'you don't deal with X', and your reply will be, 'Yes, we did.' I have two responses. One is that I *do* miss things and details tend to evaporate from my mind in the aftermath of several hours of back-to-back detail-rich presentation. The other response is to point out that this failing of mine is not an unusual one, and that in your lives as designers you will often face clients who miss a whole lot more, since they share the forgetfulness characteristic of humans, and lack the knowledge and awareness of details that designers have developed in the course of learning their craft. Thus, you should take my comments as comments upon both your design and your presentation...and you are the only ones who have a chance of figuring out which is which.

Since I'm on the subject, let me say a little more about presentation design. First, I should mention that a presentation can be ineffective in many ways. People tend to get hung up on the degree of fluency and polish in the presentation. While this is always nice, I've seen miserable presentations (no, I'm not talking about any of you) that were fluently presented, well-organized, with lots of great looking graphics. To my mind, the real test is what the audience walks away knowing. I suggest the following exercise. The next time you do a presentation, give the presentation a second time, to an audience of friends (preferably not designers). Do the whole thing: talk, show slides, have them ask questions. Then ask them what they thought of the presentation and listen to their (probably) mostly kind words and constructive suggestions. And then--and this is important--sit down and question them to find out how much they really understand about your design, and the other components of your presentation. I predict that you will be shocked and appalled at how little most of them got out of it (excepting designers, or experts in the domain for which you're designing). Yet, for the most part, in the non-academic world this is exactly the audience to whom you will generally be presenting, and who will determine the success or failure of your design in the larger organization with which you're working.

So what do you do about this? My approach is to design a presentation with multiple levels. I typically think in terms of three levels. At the deepest level, designed with domain or design experts in mind, I identify a relatively small set of sophisticated concepts, clever touches, or other points that can be appreciated by afficianados. To the extent that most designers design their presentations, they tend to think in terms of the deepest level, for it is that which differentiates the good design from the brilliant design. But, as implied above, this matters the least; I believe that most of your audience is fated to miss most of this level. The next level up is what I try to focus on the most: I try to identify 3 to 5 points, preferably one's which make up a little story, that the average attendee can walk away with. In designing the talk I make sure that each point is clearly stated, usually more than once, with a concrete example or diagram illustrating it, and then I repeat the points in the summary. If you do your job well, the audience will leave and be able discuss it among themselves (which is where the experts in the audience will be able to chime in and provide their opinions about the deepest level of the talk), and tell others who weren't there about it. In my view, as far as the ultimate goal of getting your design turned into reality, this is the real goal of a presentation, and the best indicator of whether the presentation was a success or a failure. Oh, and of course the highest level is distilling a one sentence take-away for the busy exec who pops in at the end, or who is trying read email or whatever as you give your talk. It may seem trivial, but the person who has that single sentence in his or her head feels like they understand what you're doing, and that can be important in the success of a design.

Tom Erickson

home ••• pubs essays  HCI Remixed HICSS PC patterns Apple Human Interface Alumni page •