Using Visuals in Presentations for a Technical Audience
Published: August 23, 2010
In this edition of Ask UXmatters, our experts discuss how to use visuals in presentations for a technical audience.
Ask UXmatters is a monthly column, in which our panel of experts answers our readers’ questions about user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to us at: email@example.com.
The following experts have contributed answers this month:
- Valentin Alexeev—Lead Architect, Multimedia Solutions
- Jean-luc Doumont—Founding Partner at Principiae
- Jessica Enders—Principal at Formulate Information Design
- Jim Ross—Principal of Design Research at Electronic Ink; UXmatters columnist
- Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); UXmatters columnist
- Jo Wong—Principal and Cofounder of Apogee Usability Asia Ltd.
Q: Our UX department has been asked to provide more visuals in our presentations to the development teams. What types of visualizations should we use when presenting to a technical audience?—from a UXmatters reader
The Power of Visuals
“Visual representations—drawings, graphs, photographs, and the like—are powerful communication tools indeed,” replies Jean-luc, “but they are not a goal in themselves. Do not add any visualizations just because you have been asked to do so. Add them because you are convinced they help you get your message across.
adding another mode of communication to your presentations.”—Whitney Quesenbery
“Visual representations are like Rorschach inkblot tests: what you see in the illustration you have created may not be what everyone else will see. You may thus want to test your illustrations on others, to see what they suggest to them. Better still, you can avoid ambiguity by stating your message verbally in a caption or as the headline of your slide. This statement should be a full sentence. Do not write what the illustration is—the what. Instead, state what you are trying to say with it—the so what.”
“Don’t add images—even if beautiful—to your slides just to make them more graphic,” warns Whitney. “Instead, find data visualizations, images, annotated product images, or whatever that really support the points you are making—adding another mode of communication to your presentations.”
Why Are They Asking for More Visuals?
“When someone asks for more visuals, they are suggesting a solution to a problem,” responds Jessica. “I wouldn’t take this solution on face value. Instead, like a good UX professional, try to find out more about the problem first.
“For example, can you ask what is it about the presentations they feel is difficult to understand or unappealing? Is it that they are finding it hard to imagine what you’re describing? In that case, more screenshots—perhaps including callouts—might help. Or is there a lot of data that is hard to digest? In this case, solutions might come not only from visuals, but from other things as well—like telling a story; using an inverted pyramid approach, in which you provide a summary of the most important information first; or grouping your messages into threes. By thinking of the presentation as an interaction you need to design, with the development team as your target audience, you can use your UX tools to work out what changes you should make.”
“Your development team probably wants two kinds of visuals: those illustrating the problems and those illustrating the solutions,” answers Jim. “It’s often difficult to effectively communicate problems and recommended solutions using text alone. By adding visuals that clarify your meaning, you can prevent misunderstandings. Use screenshots of a user interface to illustrate existing problems. Point out the problem areas with callouts. If necessary, annotate the visuals with brief text, explaining the problems.
“Video from usability testing or other user research sessions is another great way of showing problems. There is no better way to explain a usability problem than to let the development team see it happening to someone.
“When communicating the changes you’re recommending your development team should make to a user interface, show them visualizations of your design solutions. If it’s a small change, you can use a graphics program to modify a screenshot to show the changes. If it’s a more complicated change, you’ll probably need to mock up a completely new design before the team does any development work.”
“You might want to think about what they’re really asking for,” suggests Whitney. “They may be asking you to tell them a story, instead of just plowing through a set of facts. Without seeing your presentations, it’s hard to know how to answer your question, but there are several suggestions I can make.”
Improving Your Entire Presentation
“Do your presentations make your point clear?” asks Whitney. “I see a lot of presentations that look more like notes for the speaker than information for the audience. Jean-luc Doumont has some excellent advice on how to construct a presentation slide:
- The title of the slide should be a crisp, clear statement of what you want the audience to remember. The so what.
- The body of the slide is the supporting evidence. Not a hint of what the evidence is, but the most salient and memorable reason why the title is true. The what.
“One way to think about this is that the slides should be the notes you want the audience to take—the memorable conclusions. This is called the Assertion-Evidence structure.
“Do you show how your points connect to the actual product you are talking about? If you are presenting results from a usability test, show the screen or product, so everyone can see the issues in context. Or show how your recommendations will transform the product. If you are presenting contextual information, use visuals to help the audience get the picture. Use imagery in your language to support the visual images.”
“First think of the message you are trying to convey with a given slide—that is, the one sentence you want your audience to remember about it,” recommends Jean-luc. “Write this sentence as the headline of your slide—it should fit on a maximum of two lines, or be about 12 words in length. Then, come up with a way to develop or illustrate this message visually. To avoid distractions, remove unnecessary details from your illustrations; for concepts, prefer schematic drawings to photographs. For an illustrated checklist of how to design slides, see my ‘Checklist for Slides,’ which I’ve adapted from my book Trees, Maps, and Theorems.”
Presenting Information Using Multiple Channels of Communication
“Do you present information in more than one format?” queries Whitney. “A presentation combines spoken, written, and visual communication. You want all three to support each other, so your visuals should reinforce the main point you want to make.”
Conveying Data Visually
“Representations such as drawings and photographs are condemned to be concrete,” states Jean-luc. “They cannot easily convey a generic or abstract concept on their own. For example, it is hard to say dog generically with a picture. Even a simplified line drawing would suggest a specific breed, as well as a specific activity—walking, running, or sitting—an attitude, and so on. That said, schematic drawings do a better job than photographs at conveying something generic or abstract. Thus, if you need to show that something exists or what it looks like, use a photograph. If you want to explain how something works or how to complete a task, use a line drawing.”
“Development teams usually operate using models of different kinds,” replies Valentin. “Such models describe either a product’s momentary state or transitions from one state to another. In software development environments, this could be a data-model definition—as an example of a momentary state—or a sequence diagram, showing the transitions between task-related sets of components. Using only one type of model or another cannot give a complete overview of a system. For communicating UX design, the same types of models make sense. We use flow diagrams to define how one screen appears after another. To show a momentary state, we provide wireframes showing the most significant parts of a screen. I say screen here, but the same approach can apply to physical object design or human-to-human interactions.
“One of the better representations we use when designing applications is a moving mockup—that is, an automated playback of one or more scenarios. Each frame is a wireframe or graphic mockup, and the wireframes or mockups transition from one to another, as defined in the screen flow. Such mockups blend the two types of models I’ve described, providing in a consistent picture of a user interface.
“As for the actual tools we use, of course, it would be better if we could use the same technology to draw our models as the development team uses when developing the actual product, but this is not always possible. So, since we also use flows and wireframes to communicate with our customers, we tend to choose a tool that can work for all audiences. We have used the Microsoft Office suite—particularly, Visio and PowerPoint—and Flash for our moving mockups. For notations, the models’ language is quite simple. We define three or four main entities, and the whole description fits onto two PowerPoint slides.”
“If you are showing quantitative evidence, make sure that the most important data is clearly visible,” recommends Whitney. “For example—and this is from Doumont again— you don’t need to show an entire scale on each axis. Instead, show the numbers that matter. Yes, this means you have to carefully craft the story the graph or diagram represents, not just shove a bunch of data points into a PowerPoint chart.”
“Getting back to the idea of making a presentation into a story,” adds Whitney. “Think about how you would tell a close colleague about what you’ve learned. Do you drone on through a number of bullet points, or do you tell each other stories? If you can find a good story to support each of your points, you might find that the visuals and verbal points you need to illustrate with that story become much clearer.”
As always, the answer to this question about what types of visualizations we should use when presenting to a technical audience is: “It depends on what you are trying to communicate and the objectives,” advises Jo. “I would think of ways to touch the technical people’s hearts—whether it’s a graph; photos of customers, their environment or context of use, other products they use, or their friends and families; or storyboards that depict their stories. Tell the stories in a language a technical audience can relate to and focus on what’s relevant.”
Here are some resources that describe how to create clear presentation slides:
Alley, Michael, Editor. “Rethinking the Design of Presentation Slides: The Assertion-Evidence Structure.” Writing Guidelines for Engineering and Science Students. Last updated September 2009. Retrieved August 12, 2010.
Doumont, Jean-luc. “Checklist for Slides.” Principiae, 2009. Retrieved August 12, 2010.
—— “Creating Effective Presentation Slides (Audio Presentation).” IEEE Professional Communications Society, December 12, 2007. Retrieved August 12, 2010.
—— Trees, Maps, and Theorems. Belgium: Principiae, 2009.