Applying Comics

An excerpt from Kevin Cheng’s Rosenfeld Media book, See What I Mean.

Getting on the Same Page

Having everybody reading the requirements document before a project starts isn’t just bureaucratic nonsense; it also ensures there are no surprises at the end. The problem is that requirements documents use words like “community,” “leverage,” “user-generated content,” or other buzzwords du jour that seem meaningful but are rife with ambiguities.

Each person develops his or her own interpretation of what these words and phrases mean and thinks everyone else’s interpretation is the same as his or her own. “These requirements look good,” thinks the marketer. “Yep, looks about right to me,” agrees the product manager. “Alright, I’ll go build it according to this document then,” says the engineer.

If instead, a comic illustrating the story of how someone may potentially use the product were shared among the team, it would be much easier to determine if everyone were on the same page.

For example, with Yahoo! Local, there was a lot of enthusiasm over the next version being all about “community,” but the interpretation of that word differed from person to person. When comics were used to describe just how people would be using the new Yahoo! Local in the context of their lives, it was much easier to visualize the product and its features.

A Great Starting Point

Alexa Andrzejewski, the cofounder of the mobile start-up Foodspotting, created a one-pager that was comic-like, as the first step in her start-up.

“The very first thing I did, before I ever opened up Photoshop or put down a line of prototyping code, was to capture the core ideas behind Foodspotting in a one-page poster.”

This comic was not only used to set the tone for what the product would be and do, but it was also used in investor meetings to help them get funding. They didn’t only use the one-pager for themselves, though. Alexa continues:

I used this poster to do some ‘customer discovery.’ I ate out a lot and shared my poster with anyone who would listen, which enabled me to validate and refine my ideas. Over the course of these six months, as I solidified my vision through paper proto-types and image map prototypes, what began as a literal ‘Yelp for Dishes’ evolved into the ‘Visual guide to food and where to find it’ that it is today, and by the time I found my cofounder Ted, who also happens to be the world’s fastest, or at least most fearless, coder, we were able to hit the ground running and launch a beta within a month.

Which brings us to another application of comics: using them to validate your ideas with potential users.

Validating Ideas

Imagine getting these kinds of responses to your product before you even start building it:

“I think my friend would really get a kick out of this.” “I don’t think that’s very useful to me.”

“You’ve got to be in trouble with your girlfriend to go through all that hassle.”

These are some of the responses we got on some proposed Yahoo! Local features we had, but we didn’t get the responses by just describing the features. Nor did we spend time building prototypes of the features. We got these responses from showing comic scenarios to potential users.

Mark Wehner, the user researcher I worked with at Yahoo! Local, came up with the idea of showing these comics to potential users of the product. This idea was a huge success, and the feedback helped us refine some ideas and outright remove others.

Showing stories to participants provides them with a context they would otherwise be missing from just looking at screenshots. Instead of having participants “think-aloud” about what they think a button will do, you can engage them in an experience they can put themselves in.

To use comics in this manner, you can simply show them to people you meet, as Alexa did. However, you can also formalize the process a little more. At Yahoo!, we printed out our comics (you can print one panel per page to ensure that it’s big enough) and ran our participants through a process.

Read It Twice

If you are testing a prototype, you might have some tasks for the participant to perform. But with comics, it’s a little different since there’s no interface. The first step is to ask the participants to read the comic on their own to ensure they have time to digest the story before providing feedback on it. This initial reading also allows the participants to immerse themselves in the story without interruption.

Once they’ve finished reading it, have the participants go through the story a second time, aloud, and describe the story in their own words. This reading ensures that they’ve interpreted the story correctly.

Sometimes, we’ve found that a story was poorly written and completely misconstrued. If we didn’t have them describe the story in their own words, the feedback we’d receive could be completely irrelevant, and inaccurate feedback is even worse than no feedback at all!

Solicit Feedback

As the participants read the comics the second time around, you can start to solicit feedback from them. Find out what about the story and product is intriguing, appealing, confusing, or complicated to them.

As I’ve mentioned before, one of the strengths of comics is their abstract nature, which allows readers to relate themselves or someone they know to the story. As your participants are giving feedback on the comics, make sure that you ask them explicitly to talk about how this relates to them. Some quotes I’ve heard include the following:

“This would have been useful when I was…”

“I normally wouldn’t do this, but I know this couple that would love this.”

Talking about these real-world scenarios helps refine the use cases you’re trying to serve. By asking them their own stories, you are building up a set of real use cases that your product will be serving, and you can also adjust your comic to represent these use cases.

Feedback on Comic vs. Concept

Remember how we asked the participants to describe the story back to you? One of the reasons we did this was to gauge whether the comic itself was conveying what you thought it was.

A brilliant idea may not be received well if the story describing the idea is poorly done. It’s important to differentiate whether feedback, especially negative feedback, is directed toward the comic or the concept. Is the negativity because your participants don’t understand what you’re trying to say or because what you said isn’t appealing to them?

Once you can separate these two types of feedback, you can act accordingly. When we realized that the language our character “George” used was so contrived that it became a distraction, we modified his dialogue. We adjusted the way the story was told rather than the story itself and then proceeded to show the new comic to the ensuing participants.

The wonderful thing about these simple comics was that we were literally able to make these adjustments within under an hour so that we could try the iterated versions right away. Just as we discovered what areas were appealing in a product concept, the feedback on the comic could also help uncover the barriers that potential users would have with using the product.