Communicating Concepts with Comics: An Interview with Kevin Cheng

Kevin Cheng is a senior interaction designer with Yahoo! Maps and Yahoo! Local, and is an expert in using comics as a technique to communicate the key concepts behind a design’s intended user experience. UIE’s Ashley McKee recently had the opportunity to talk with Kevin about the increasing popularity of using comics in the design process, the five inherent properties of successful comics, the skills needed to create comics, and the best way to deliver comics to key stakeholders. Here is what Kevin had to say about his experiences with comics.

UIE: How long have you been utilizing comics in your work? Can you give us an example of a recent concept or product design you’ve conveyed through comics?

Kevin Cheng: We started trying out the idea in the fall of 2005 after a conversation with Bill Buxton at CHI. Bill was looking at various ways of conveying concepts and was curious whether comics would be a good tool for communicating ideas instead of our more widely used tools like personas and requirements documents.

We’ve used the idea for Yahoo! Maps, and I’ve seen some other groups in Yahoo! Mail and Yahoo! Autos utilize comics for their products as well. In particular, I believe the Yahoo! Mail Messenger integration had some concept comics during its early design phase though I wasn’t a part of that.

What limitations with existing tools (requirements documents, personas, user scenarios, and storyboards) led you to start focusing on using comics in the design process? 

All of the tools you mention are used throughout Yahoo! and have their place in the design process depending on the project. The problem we encountered was the documentation would either not be read thoroughly enough or each person would interpret the meaning of the requirements differently. Two months later, we were deep in the development process and suddenly realized everyone had different visions of what the requirements actually meant.

You often talk about the 5 inherent properties of comics (communication, imagination, expression, motion, and iteration), which, if understood, can help people use comics to their full potential. Can you briefly explain these properties?

Communication references how comics are a visual language or as I say in the presentations, a “universal” language. “A picture is worth a thousand words” is a cliched term but for good reason.

Imagination speaks to the ability for illustrations-and it’s important that they’re illustrations, not photographs-to abstract away unnecessary details so the reader can focus on what you really want and fill in the rest.

Expression and motion are about the properties of comics as a medium, and how you can tell different kinds of stories with comics because of the expressiveness of the visual form, and the sequential nature inherent in it.

Finally, we all want tools with which we can do rapid designs and iterations, and comics have been great for that.

It’s hard to explain these properties in one sentence or less because they are so key to understanding how this medium is much more valuable and expressive than you initially think.

At what point in the development process will comics come into play?

Comics will come into play somewhere after the brainstorming and before any sort of wireframing. You want to have some high level idea of what the product or feature is and what kind of use cases it’s trying to solve. Subsequently, you want to use comics to quickly disseminate these ideas and get everyone in the team and organization to say, “yes, that sounds like a great idea!” or, “I’m not so sure that would be useful.”

What organizations do you know of that use comics in their development process? (These don’t necessarily have to be organizations that you’ve worked with-just the ones that you think “get it.”)

A surprising number of organizations have told me that they’re starting to incorporate them, either through inspiration of some of the original presentations or through their own accord. I know many design firms, including nForm in Canada and Adaptive Path in San Francisco, have used them on one or two projects. Other internal design teams at companies like Sun Microsystems and Sprint have embraced the methodology as well.

How much skill do you need as a drawer to make comics an effective part of the design process? Does the level of fidelity in the comics matter? 

The level of fidelity matters the same way anything you present matters. When you’re discussing an idea with your business partner, you can do it on a napkin but you wouldn’t use that same napkin to present it to the CEO or a venture capitalist. Similarly, anyone can use comics to help communicate ideas more concisely and accurately but the higher up you go, the more polished they should be.

Are there any resources or tools you recommend for people thinking about incorporating comics into their design process, or just starting out with comics in their organization?

I’ve been collecting resources as I see them on my blog. I try to keep that up to date with new tools I find. You can see the resources I’ve collected here: kev/null

Is it a good idea to use captions under the comics to convey what the user is doing, or should all wording be kept to the users’ voice and thoughts?

Sometimes, you’ll see comics that have captions above or beneath the imagery like in Farside or Family Circus. However, both of those generally are using the captions as an unobtrusive way of doing dialogue. Like the rules taught in English in high school (“don’t start a sentence with because”), there are guidelines that exist to help a person until they understand the medium better. My rule of thumb is to not use captions at all and use dialogue to communicate the story. Let the characters drive the story forward. We practice user-centered design after all.

What templates do you use to bring comics in a manageable format to all the different stakeholders concerned with a project?

We’ve been using a template that’s fairly inexpensive called the Tarquin Engine. It’s an Adobe Flash template and opens up to a lot of flexibility in what kind of sequential stories you tell, but most importantly, it packages up a comic in a nice flash file that anyone can view in a browser from a hyperlink.

In terms of making comics easy to digest for stakeholders, is there a maximum number of panels to limit comics to?

As a general rule, we try to keep it between 6-10 panels. That’s basically the equivalent of a comic short story-more than a comic strip, less than a graphic novel. When you go beyond that, and you start to include unnecessary details. Limiting the panels, like limiting the text to dialogue, forces us to think about what part of the story is truly important to convey.

Do you tend to hear of a lot of resistance from management to implement comics in the development process? Do you have any tips for developers and designers trying to champion comics within their organization?

Surprisingly, we haven’t. I think many organizations actually recognize that something is broken in the early part of the chain when it comes to getting everyone on the same page. We’ve been lucky in having a very supportive team, but even if we’d met a lot of resistance, I don’t think it would be too difficult to get them to look at the comics.

Obviously, we would communicate them as “conceptual storyboards” or something more elegant sounding, but in the end, it’s a lot easier to get people to read 10 panels of a comic than it is to read a 50 page requirements document and really understand what the product is about.

Are there any instances or conditions under which you don’t recommend using comics in design?

I’m not one to make everything a nail when I have a hammer. Comics have their place as a way to communicate and disseminate new feature and product ideas and get everyone on the same page before moving forward. It could save people a lot of time down the line-and would have saved us a lot of time if we’d used it for some of our older projects.

At a higher fidelity, it might even be a great sales tool or in some cases, a way to explain to users what a tool does as part of the marketing. But the tool doesn’t replace wireframes, specifications, use cases and all sorts of other tools that we employ throughout the product cycle.

Thanks, Kevin!