Page added by Joan Costello
Video - 04:17
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help
 |
Comics are known to be one of the most powerful communication tools, and are a unique way to communicate — using both image and text to effectively demonstrate time, function, and emotion.
Today’s article is an excerpt from Kevin Cheng’s “See What I Mean” — a book that walks you step by step through the process of using comics to communicate, and providing examples from industry leaders who have already adopted this method. Enjoy!
When creating a product or feature, you undergo a product development process. For example, you might start by interviewing some existing customers or by running focus groups. You might create business and functional requirements that describe what you need. Then, when you’re ready, you begin designing and developing and iterating on the product.
Or perhaps you prefer to define products by first building a prototype, bypassing formal requirements. Everyone has their own preferred process. The process you follow and how strictly you adhere to it depend on the circumstances.
The same could be said of creating a comic: there isn’t one correct way to go about it.
I’ll present a process that includes all of the steps involved in creating a comic for a product, but it’s just one of many approaches. The more practiced you are at it, the better you will be at knowing which steps to spend the most time on and which steps you can combine or skip over entirely.
Multiple steps are involved in creating a comic for your product. Full view.
The process of creating a comic for your product can be broken down into the following steps. For larger projects, you might feel the need to create multiple comics that represent different personas and use cases. In the case of the comics we made for Yahoo, we created a total of three comics. Each comic represented very different use cases that resonated with different participants. The goal was to be representative, not comprehensive.
The comic creation process.
To illustrate each of these steps more clearly, I’ll use an example and create a comic from start to finish. The example is a real product, but, to my knowledge, its maker hasn’t used comics in its product development or marketing. So, let’s pretend we’ve been asked to create a comic for it.
Square is a little physical card reader that you can plug into the headphone jack of an Android phone, iPhone or iPad.
The Square credit card reader.
After plugging it in, you can accept payments from any major credit card with minimal set-up. It’s currently used by small businesses, coffee shops, street food carts, people selling items on Craigslist, people running garage sales and many others. This card-reading device and its associated software are free, but each time you run a transaction, a flat rate is charged to the merchant.
Square is an appropriate example for a number of reasons. First, the product spans many platforms, including mobile devices, tablets and a website. Secondly, the product has many use cases and personas, which is probably the case for many of your products. Finally, clear real-world interactions can be associated with the story of Square’s usage.
If you’d like more information on Square, you can look up the product on the official website. It’s worth mentioning that the founder of Square is also a cofounder of Twitter, where I used to work. However, my use of the product as this book’s example is done without any consultation or inside knowledge. We’ll go into detail with this example soon and continue doing so for the next few chapters.
Now that we have an example to work with, let’s start the first step of the comic creation process by answering the question, What’s the comic about?
Answering this question can be tricky. Instead of approaching it as one broad and vague question, breaking it down into a few logical steps might be easier. Once you have addressed these, narrowing down your comic’s story should be much easier.
Before thinking about what should go into the comic, start with what you want it to accomplish. If you know what actions you hope to inspire through the comic, then you can design the comic towards that goal. When Google decided to create its comic for Google Chrome, it had a clear goal in mind. It didn’t want people to focus on comparing features between browsers; instead, it wanted readers to gain an understanding of its technical motivations for building a Web browser from scratch.
The goal of the comic may vary, depending on whether it’s for a product that already exists. When using comics to describe products that haven’t yet been built, the goals may be centered on understanding and sponsorship. The comics we created at Yahoo were used to validate our product vision with potential users as well as with management. Our goal was to get feedback on how useful the product ideas were and to get support from management to start building the product as described in the comic.
Sometimes, the goal can be completely measurable. At Raptr, we used a comic on the home page to describe the product. Our goal was to help visitors understand our product, but we were also hoping to inspire a particular action: user sign-ups. Similarly, because Square is a product that’s already in the market, the goal of our fictitious comic should be to help merchants understand why it’s useful and, ultimately, to have them sign up to receive a Square device.
Defining the goal of your comic is a crucial step, but it shouldn’t be that difficult. If you’ve already decided to create a comic, chances are you have some idea of what you’re hoping to accomplish from it.
After deciding what your comic is about, the next important factor to determine is how long the comic will be, because you need to know how much room you have to work with. I recommend a very short comic (three to eight panels) to illustrate an idea. At that length, it’s easy to consume, yet contains enough information for both internal and external communication. The comic should fit on the home page of a website, on a postcard or in an email to your team.
However, there are plenty of examples of longer comics. The Google Chrome comic was over 30 pages and fairly technical in nature.
A copy of the Google Chrome comic book.
Even at that length, it was much more digestible than a detailed white paper, and it had just the right balance for readability. The comic was available online, but it was also distributed in physical form to key developers and industry experts.
As a way to connect to its Japanese audience, the US Navy created a full manga (a Japanese form of comic book) in both English and Japanese to explain why its aircraft carrier would need to be docked in Japan for several months.
Manga for the US Navy’s USS Washington.
Given the widespread acceptance of manga as a medium for any topic, this seems like a great way for the US Navy to connect with its audience. A lot of people were interested in the carrier, so publicizing the comic wasn’t difficult. Many local and online press outlets wrote articles about the comic. When the book was released, there was a line around the block to get a copy!
Another proponent of long-form comics is Adobe’s Evangeline Haughey, who had been trying to find creative ways to encourage team members to read her user research reports and decided to spice up one of her reports by presenting it in comic book form. The comic was a handful of pages, and she printed it as a booklet, complete with a mock comic-book cover illustrated by her colleague Julie Meridian.
Adobe’s comic book cover.
One commonality among these examples of long-form comics is that they all feature a physical component to their distribution. If your ideas are complex or lengthy, consider a longer comic, but also think about ways to distribute physical copies. It’s surprising how hard it is not to read a copy of a comic that’s in your hand!
Long comics aren’t always appropriate, however. Akoha, a startup that uses trading cards to encourage good deeds, tried to use comics to explain its services in an innovative way. Unfortunately, it was a multi-page comic that few visited when coming to Akoha’s home page. By contrast, many companies, including Nectar, have used very simple three-panel comics on their home pages. These comics are easy to consume and immediately explain the product.
Akoha’s multi-page comic versus Nectar’s three-panel comic.
I love constraints. We’ve all witnessed their power. Presentations are constrained by time, and reports by number of pages. In film, the editing process is crucial to ensuring that a movie stays under a certain number of minutes. This process culls scenes that do not add depth to the story. These constraints may seem artificial, but you’ll find that they’re helpful because they force you to be creative and thoughtful. By constraining a comic to between three to eight panels, you’re forced to think about what features are most important to convey.
Aside from length, the Google Chrome and US Navy comics share something else in common. Both demonstrate a clear understanding of their audience and tailor the stories specifically to them. In the case of Google Chrome, the audience was technical enough to care about browser performance and engineering. With that in mind, Google was able to tell stories about JavaScript processing and browser caching.
The US Navy’s understanding of its audience — Japanese residents of Yokosuka — determined the format of its messaging. In fact, it was so successful in that campaign that people lined up around the street to get a copy of the manga. Who your audience is, where they’re from and what they know will influence the contents and delivery of your story.
Let’s say someone asked you, “How do I get to the nearest post office?” What would you say? Maybe something like:
“Turn left at the first light. Keep going until the stop sign, and then make a right on Main Street.”
These directions seem pretty straightforward. But what if you knew the person who was asking you? Let’s say it’s your cousin Joseph, who is a bit navigationally challenged. Then, you could give a few more details.
“Turn left at the first light, where the blue gas station is. Keep going — you’ll pass that playground we used to play at — and make a right when you see our old high school.”
What you’re doing is offering the right level of detail based on the person you are communicating the information to. We scope our conversations based on context and audience all the time without even realizing it. If you had answered the question in painstaking detail, it would be more like this:
“Insert your key into the ignition; turn it once until you feel the engine starting. Before you back out of the garage, make sure to check all your mirrors for any people or vehicles…”
… and so on. We don’t go into this level of detail because we implicitly understand and account for the audience’s level of expertise.
This consideration is important and yet insufficient. Beyond expertise level, we also need to consider the audience’s context. In the last example, I assumed that the person would be driving. But they might be a cyclist or a pedestrian. A cyclist would want to know the grade of the street; a pedestrian won’t care about one-way streets; and a driver wouldn’t be able to drive down stairs.
Let’s consider a business context. In The Design of Everyday Things, Don Norman discusses the concept of mental models — how people view a system. Norman uses a camera as an example. If you were to ask an engineer how a camera works, you might get an explanation of light, aperture and shutter speed. The comic for such an explanation might look like this:
How a camera works.
If you were to ask a layperson how a camera works, they might explain how to turn it on, how to focus and how to upload a picture. Then the comic might look like this:
How a camera works to a layperson.
Both of these comics are correct. They simply differ based on the expertise of the audience and the context of what the audience hopes to learn from the story. If you know your audience, you’ll have a much better idea of what your story should be and how to frame it. We can apply these considerations to our Square example, too. Square’s audience is merchants who have trouble receiving credit-card payments and might find Square useful.
The merchants need to own a smartphone, so they will presumably be reasonably tech-savvy. At the same time, they will only care that the device is easy to use and secure, and would be unlikely to understand (or care about) the detailed technical workings of the hardware.
You now know who you want to read your comic and their context. The next step is to find a story that will help your readers understand why they should care! To accomplish this, find a use case that resonates with them and that addresses their problems. You may be telling the story of a problem that they didn’t even realize they had.
When Apple launched its video-conferencing application, FaceTime, people already had many competing and compelling products they could use. Skype, Google Talk and even Apple’s own iChat have free video-chat and even video-conferencing capabilities. One important distinction was that FaceTime is on a phone rather than a computer — but, given that you still had to be connected to a Wi-Fi network, this portability was limited.
Apple didn’t explain FaceTime’s differentiation through a list of features. Instead, it aired a series of short advertisements that showcased powerful human use cases — scenarios such as a father traveling abroad and conferencing with his family, and grandparents seeing their grandchild for the first time. Are these scenarios unique to FaceTime? Certainly not, but they were compelling and helped the viewer understand why the feature was important to them.
Find a use case that resonates with your readers addresses their problems.
Let’s go back to Square. What kind of use cases could we use for Square? Let’s list a few use cases for which we think Square would best help solve a problem.
Notice the commonality in these use cases? In each case, the user typically does not have an easy means of accepting credit-card payments but needs to do so or else lose business. For some, such as the coffee shop and small merchant, the user has an established business. For other use cases, such as the garage sale and the items on Craigslist, the individual would need to accept credit cards on occasion.
Still others are in the goods and services business, providing their service in varied locations such as conferences, craft fairs and people’s homes. Two themes arise from looking at these use cases: the advantage of Square’s mobility, and the ease of access to a credit-card payment system. Conceivably, we could create just one comic about the mobile use case, and it would naturally also describe the easy credit-card payment system.
However, if we were actually creating these for Square, having a separate comic for merchants would be beneficial, lest they think, “Well, that’s nice, but my shop doesn’t move around, so I don’t need a mobile solution.” For the purpose of this example, let’s create a comic for the use case of selling books at trade shows and conferences. Which of Square’s features should we highlight?
Perhaps listing all of the features would be useful:
Yikes! Those are a lot of features to include in a story. How will we create a comic that captures all of these points in only three to eight panels? We have more bullet points than panels! Luckily, we have a use case now to help us narrow down which features to highlight and which are less important. One important aspect is that the device plugs into popular mobile devices and accepts all major credit cards.
Whether you need to highlight the cost of the device (free) is debatable. You could argue that the comic is meant to get the reader interested enough to investigate, and you could subsequently explain the details in another medium. However, as we’ll see later, incorporating the cost into the dialogue is easy enough. Some details we can skip in the comic are the schedule for depositing money received, the fees and the lack of a contract.
All of these elements are important selling points for the product, but remember the questions that the comic should answer: “What is this, and why should I care?” Can you imagine if iPhone commercials talked about two-year contracts or even the cost of the phone?
Summing up, here are the features that seem most important to highlight for the mobile payment use case we’re addressing:
This list seems much more manageable. Can you see the story crystallizing?
We’ve decided that the goal of the comic is to get merchants to understand Square and to sign up for one. The audience for the comic is merchants who are technologically savvy. The problem we’ll address is the sale of goods at trade shows and conferences, with no easy way to accept credit cards. We’ll narrow the story to a person who wants to sell books at a conference. (As it turns out, Rosenfeld Media, the publisher of this very book, now uses Square to sell its books at conferences!)
We have finally narrowed down the feature list to just over a handful. Now we know what the story is about.
Editor’s Note: A special thanks to Kevin Cheng and Karen Corbett for providing us with this book excerpt (the entire book is available here). If you’re also interested in having your work featured on Smashing Magazine and in the Smashing Library, feel free to contact us anytime!
(al) (ea) (il)
© Smashing Editorial for Smashing Magazine, 2013.
]]>Page edited by Susan Dawson - "Added steps to print and the quick reference guide."
The process for completing your FAR via Digital Measures remains the same as with the previous FAR. After completing the required sections in Digital Measures, we are asking that you print the FAR within Digital Measures, sign it and turn it in for review. This does not change.
The FAR deadline is April 11th.
From the Digital Measure Home Page, click Run Custom Reports.
Click here to view the Quick Reference Guide.
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help
 |
 |
|
|