The Power of Comics: An Interview with Kevin Cheng

by Jared M. Spool

Kevin Cheng is a designer at Yahoo! Brickhouse, a division of Yahoo focused on the development of cutting-edge, innovative products. He is also one of the founders of OK/Cancel, the popular user experience comic strip and blog. UIE’s Jared M. Spool recently had a chance to chat with Kevin about his work developing user experience concepts with comics.

UIE: You’re working at Yahoo Brickhouse. I bet a lot of our clients don’t realize Yahoo has such a group. Can you explain the goal of Brickhouse?

Kevin: Brickhouse is an idea incubation place for Yahoo. It’s original goal was to figure out how to build in-house products similar to Flickr, the popular online photo sharing site Yahoo acquired. Brickhouse is designed to help Yahoo’s employees bring their innovative ideas to fruition.

At UI12, you’ll be presenting a full-day seminar on how design teams can use comics for communicating key concepts behind a design’s intended user experience. How did you come upon this idea?

I first started thinking about the idea in 2005 at the Computer Human Interaction (CHI) Conference. At the conference, Bill Buxton, Principal Researcher at Microsoft Research, contacted Tom Chi, my partner in crime at OK/Cancel, and myself to bounce around ideas about how to use comics for communicating user experience concepts.

During our conversation, Bill commented, “Wouldn’t it be interesting to compare projects that use comics to tell a story to projects using wireframes?” This conversation with Bill seeded my idea of using comics in the actual design process.

In 2005, I also joined Yahoo! Local. At that time, the design teams were experiencing some difficulties with other methods, such as requirement documents, for understanding how people use features. They were having a lot of misunderstandings among team members with different people believing different things about what the product could be. That’s when I pitched the idea of using comics to Tom Wailes, manager of the Yahoo! Local user experience team.

At Yahoo, did you have much success pitching the use of comics?

In the case of Yahoo, Tom Wailes was immediately onboard with using comics. Also, once we implemented the technique, we received an overwhelmingly positive response from everyone. Our user experience researcher was immediately saying, “We should show this to users.” As a result, we conducted some usability studies with the comics and users really took to them.

Our user experience director also saw them, thought they were fantastic, and showed them to Yahoo’s head of Search at that time. Back then, the comics weren’t even created for that kind of distribution, but it quickly became clear that this means of communication was so visceral and easy to digest.

When design teams draw the comics, they aren’t drawing elements of the interface itself, right?

No, they aren’t. This is a very crucial point because a lot of teams sketch storyboards of the interface. When design teams refer to “storyboards” or “flow,” they are often sketching features of the product, such as boxes and arrows, and not the user experience.

I use comics to focus on the users’ experience and determine the story around how users will interact with a product. We shy away from drawing any kind of interface elements.

The comics are images of the users preparing to use the interface, their actual experience of using the interface, and how they react to what they’re doing. Is that a good summary?

Yes. Most people have used personas where they create a character and discuss things such as the user’s age, interests, and how many kids they have. It’s a great way for the team to understand users and keep those people in mind when designing a product. But when it comes to creating a product or a feature, design teams often don’t really think from the perspective of how users will interact with the product.

For example, let’s take the case of a user interacting with Flickr. Let’s call him “Jared.” With comics, we would describe how Jared takes some photos with his digital camera and uploads them. The comic would depict Jared taking photos. It would also show Jared thinking, “I wish all my friends could see these photos right now. But I only want my friends to see them.” He would then discover the Flickr site and use it to upload and display his photos to his friends.

The comic will avoid a lot of the specific details of how Jared will use Flickr in terms of the interface. Instead, it focuses on how users interact with Flickr in terms of the sharing, privacy, or tagging.

How long does it take to create the comics?
The method is not hugely time consuming. At Yahoo, it took us approximately two weeks to create three comic scenarios. Obviously, the more you do them, the easier and faster it becomes. I created a lot of the art on the fly as well, but you could easily just trace existing things. I have a lot of suggestions on how to make that process a lot faster.

But the idea is that the act of drawing the comics shouldn’t take up the majority of the time. There should be a lot of time spent on just thinking about what you’re going to be drawing, which is really the whole point—to decide what the story is you’re trying to tell people.

After the comic is created, the team can create designs that plug into that experience. Is this any different from how developers take advantage of use cases?

I think use cases function very similarly to comics. I don’t think comics are a replacement for many of the tools design teams have available to them. However, at UI12, I’m going to talk about the reason that comics are much more powerful than many of these other tools.

One of the strengths of comics is that they’re very condensed. It’s almost like the whole picture is worth a thousand words. And a comic is just a series of pictures. Therefore, a lot of data can be condensed into the comic. I’ve found people tend to read these types of comics more often than requirements documents. Not to say that requirements documents aren’t necessary, but there is a minimum bar you want people to have digested before a project starts and before you can be on the same page.

Comics are an exercise to ground members of the development team so they can have a high level conversation about the users without getting mired down by discussions about features, such as “Is this button going to go here? Is it going to go there?” With comics, developers aren’t dealing at that level, correct?

That’s exactly right. Comics are a great tool, both externally and internally. Comics work as an external tool where you’re using them to communicate to others once you’ve finished creating them. Comics also work as a very introspective tool as you’re building them because they force designers to think about what is important.

With comics, design teams focus more on what they are building and not how they are building it. When you’re drawing these comics, they can be stick figures or they can be a much higher fidelity and professional-looking.

I’m always shocked at how much people resist drawing. But once they start doing it and realize it’s not very difficult, they relax a bit. Do you find that resistance?

By the time people attend my seminar, they’ve committed to doing this. But, in general, I have noticed resistance before. People are sometimes apprehensive about signing up for things like my workshop because they feel like they can’t draw. However, I’ve found that stick figures are actually sufficient for a lot of the stories you need because you’re just using it for your peers.

Also, I provide a lot of templates at my seminar to assist people. For example, I provide attendees with a facial expression dictionary that teaches how subtle variations in the look of just the eyebrows and the mouth can change the emotional perception conveyed by the comic. And those are just three lines that you curve in different ways to get the different effects. Anyone can do that kind of thing. Sometimes you just need to be told which combination creates what kind of expression.

Thanks for your time, Kevin. We appreciate it.

Published here on September 26, 2007.