Defining the Problem: Q&A with Kevin Cheng

by Luke Wroblewski May 10, 2006

In the third round of our discussions about using design for Defining the Problem, I had the chance to speak with Kevin Cheng, top-notch comic artist and UI designer at Yahoo! and OK/Cancel. In particular we discussed a problem framing technique he’s been presenting at several user experience design events.

Q: First of all, I'm a big fan of your recent work using comics to communicate product direction to both stakeholders and end users. Can you talk about how that initiative came about? What were you guys trying to achieve?

A: The idea originated from a discussion between Tom Chi, my partner in OK/Cancel, and Bill Buxton at CHI 2005. Bill was working on a book on experience design and thinking about how to apply Scott McCloud's concepts in Understanding Comics to sketching the dynamics of interaction. The three of us got together and the discussions moved towards the use of comics as contrasted with the use of traditional screen storyboards.

Later, I joined Yahoo! Local and Maps and one of the key issues they faced in a recent launch of Local was the inconsistent interpretation of what the product vision and direction was. As it happens, I was about to embark on designing a major product feature, which had yet to be defined in depth. We took this as an opportunity to try something new since nothing we'd tried thus far worked to a satisfactory level.

Our goal was to have something which could be used to quickly solicit feedback and could be easily iterated, digested and distributed. Comics turned out to have these properties and more.

Q: Why opt for a format like comics instead of say, a mockup, wireframe, or other artifact? What was missing in these more “traditional” formats?

A: All of those formats you mention are really useful and have their place in Yahoo! but really don't belong in the conceptual phase of the design process when we're still defining the problem. I think something we've forgotten as this industry matures is that these methodologies are for designing the interface (or the solution in general) and can easily lead us to forget about the situation and people we're building the solution for.

We also tried some other tools like personas and user scenarios. These tools can be very powerful but were still lacking for our needs. User scenarios were easily misinterpreted but more often, were not read at all while personas didn't convey the person within the context of the problems we're trying to define and ultimately solve.

Q: With each story, were you trying to define the problem you needed to address or propose several solutions to a well-articulated problem -which I assume would have come from the business side of your team? How did you decide what to include in each story?

A: A lot of different sources fed into the initial ideas. We had brainstorming sessions that involved a cross functional team to get the general ideas out. The team as a whole has a pretty good idea of some of the problem areas in this space. That knowledge comes from previous versions of our product, user research, market research and internal industry expertise. What the brainstorms yielded was an idea of the general direction we wanted to go and a starting point for the narratives. We created 3-5 narratives which were representative of potential solutions for certain situations. Each one solved a different, unique, problem but the overarching theme of the stories was actually quite similar.

For example, if I was to give an example of what we might create based on the existing Yahoo! Maps Beta, there might be a story on somebody who needs directions a party but needs to stop at a grocery store. Another may be somebody who needs directions to a movie theater but also needs to know if there are any places to eat nearby. Our narratives loosely allude to the solution we're proposing but when we show the users these comics, they also help to verify if the problem is one they can relate to.

In terms of the actual content of the comics, we strayed from showing any interface artifacts if we could help it. We also tried to keep all of the text restricted to dialogue from the characters of the comics. A common mistake that I see others making when they are trying to borrow our technique is to create some panels of art and then have narrative text underneath explaining what is happening. Inevitably, a lot more information is conveyed in the text than is necessary and it becomes more like a picture book user scenario than a comic. The text becomes a crutch. When the information is restricted to the perspective of the characters (i.e., the hypothetical users), you don't get to put in information like, "the device then links to the computer and downloads the information". Instead, we're dealing only within the context of the character's mental model.

Q: So once you drafted the stories and put them in front of users, what was the effect on your team? Did you guy find the clarity you needed to design an appropriate solution?

A: Engagement was the primary effect we got. Back when people actually read the newspaper on Sundays, the first thing we read were the Sunday funnies because they were the quickest, easiest to digest and probably most entertaining. Deliverables are not useful if they aren't read. Comics provided something everyone was likely to read and become engaged in.

Through the numerous feedback loops with users and internal stakeholders, we were also able to get the data we needed to answer, "do they really need this?" What we didn't have was a formal prioritization of which of the illustrated scenarios we actually wanted to pursue.

Q: Is there anything about the work or training of designers that enable them to communicate product concepts through comics as you’ve done?

A: If you're referring to artistic talent, I don't think there are as many illustrator/designers as one might think. That's not to say it's a necessary requisite for the methodology. We've seen many different levels of participants in the workshops that Jane Jao and I teach on this methodology and all of them have produced comics, which are sufficient to convey a useful narrative.

I do think that designers are more versed in the aggregating feedback from other functions and distilling that into something digestible for the team and for user feedback. All the other formats we talked about earlier fall into a similar category.

Q: So the obligatory “strategy” question... For several designers I’ve spoken with, defining problems has been a path into the world of product strategy. What was the impact of your methodology on the strategic process and your involvement?

A: I think in the teams I've been on, I've been fairly fortunate to have been an integral part of the strategy and planning such that I'm not getting thrown requirements. A large part of that comes from helping the team understand the problem through user research and deliverables that communicate these findings easily.

What these comics provided was a really fast and easy way to get people involved with the strategy on board and listening - to each other and to the users.

Thanks Kevin!