Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 04 2014


Guerrilla Usability at Conferences

Does your company have display booths at trade shows and conferences? Typically, these are marketing-dominated efforts, but if you make the case to travel, working the booth can be used for user research. Here’s how I’ve done it.

Positioning and justification

At times it can be a hard internal sell to justify the costs and diversions to take your one- or two-person show on the road, all the while piggybacking off of another department’s efforts. Yet, standing on your feet for 12 hours a day doubles as a high-intensity, ‘product booth-camp.’ Say what you will about sales folk, but they are well trained on knowing how to (or finding someone who can) answer any question that comes their way. As an in-house UX professional, the more I can technically understand about our SaaS product, the more context I can have about our user’s needs.

I’ve found that having prospective customers participate in a usability session is a great way to show that we were taking the time to invest in them and their opinions of the product. As a result, there have been specific features that have been rolled into our application during the next sprint, which were proposed as small sound bites of feedback during these sessions. It shows we were listening, and makes a great justification for a follow-up phone call.

Recruiting and screening

To recruit, I scan Twitter to find those who tweet that they are excited about attending the upcoming conference. I cross-reference the Twitter handles to the names in LinkedIn to see if, based on job title and industry, they would be good participants.

I reach out to them to see if they’d be willing to sign up for a slot, proposing times between presentation sessions or before/after lunch to not conflict with their conference attendance.

Because the expo halls are generally open the entire day, even if there is no one booked on the calendar in specific spots, I also grab people just milling about to keep the sessions going. If you do this, be sure to quickly do a visual scan of their badge, as you can get a good sense of what they do and what knowledge they might have by where they work.


For the time bookings, I find that is a flexible, free, user-friendly way to book time slots with random people, using just a URL with no account sign-ups needed. In addition to custom time buckets (18 minutes, anyone?), Calendly also provides the option of a buffer increment after every session, so I can take notes and regroup.

Screen shot of a calendar with appointments booked.

Pick a time, (most) anytime.

Calendly does a good job of reminding participants when to show up and how find me–all the important things, including integrating well with all the major calendaring applications.

Come conference time, I have a slate of appointments along with contact information and reminders when they were coming. Couldn’t be easier. If expo hall hours change, I can easily message participants to let them know of the reschedule.


In a normal, controlled setting, I would typically want to go a full hour with a participant to properly delve into the subject matter and go through a number of different tasks and scenarios. “Pick a few and grade on a curve,” as Neilsen once said.

However, with the participant’s attention scattered given the sensory overload of the conference floor, anything more than 20 minutes gets to feel too long. At conferences, you’re going for quantity over quality. An advantage to this staccato method is when you find a vein of usability that you want to continue to explore in further depth and detail, there’s likely another participant right around the corner (either scheduled or random) to confirm or refute that notion.

Script and tone

The main challenge of this technique is that you’re not supposed to ‘sell’ in the role of testing moderator but rather to guide and respond. I wear many hats when working a booth; when not conducting these sessions, I sell the product alongside marketing.

As a result, 90% of the conversations in the booth are indeed sales, and switching roles so quickly is sometimes hard. I try to check myself when the testing script bleeds into ‘did you know that there are these features…’, because after 3+ days and what feels like a thousand conversations, I tend to put my conversations on a programmed sales loop, letting my brain rest a bit by going off of a script.

A pre-written task list helps keep me on point as a moderator. However, with the variety in participant group, I use the script much more as a guide than a mandate.

As with any usability session, I let the participants veer into whatever area of the app interest them the most and try to bring them back to the main road ever so subtly. With so many participants in such a short period of time, sometimes these unintended diversions became part of the next participant’s testing script, as it is easy to quickly validate or refute any prior assumptions.


Following the ‘guerrilla gorilla’ theme of this article, I use Silverback for my recording sessions. Silverback is a lightweight UX research tool that is low cost and works very well.

At one event, without my Bluetooth remote to use Silverback’s built-in marker/highlights, I paired an iPhone with an app called HippoRemote. Meant initially to provide ‘layback’ DVR/TV functionality, Hippo can also be written with custom macros to allow you to develop third-party libraries.

In the case of integrating with Silverback, this meant Hippo marked the start of new tasks, highlights of sound bytes, and starting/stopping recording–all the things that the Apple Remote should have done natively.

Despite some of the challenges in peripherals, Silverback is absolutely the right tool for the job. It’s lightweight, organized, and marks tasks and highlights efficiently.

Screen grab of the Silverback UI

Silverback UI

I recommend a clip-on microphone or directional mic given the background noise from the conference floor. Any kind of isolation that you can do for the participant’s voice will save you time in the long run, because you won’t have to try to scrub the audio in post-processing. Moving the sessions to somewhere quiet is a hard proposition, as the center of activity is where the impromptu recruitment tends to occur.


As a data-intensive SaaS product, the biggest challenge comes when trying to use the conference wi-fi. With the attendees swamping access points, there is no guarantee that I can pair the testing laptop and the iPhone used for marking, because they both need to be on the same network router for integration with with Silverback.

An ad-hoc network for the Mac won’t work, because I still need web access to use the application. Using my mobile phone as an access point has bandwidth constraints, and choppy downloads are not a good reflection on the speed of our application.

Unfortunately, then, every session begins with an apology on how slow the application is performing due to the shared conference wi-fi. A high-speed, private access point or a hardline into your booth cures all of these issues and would be worth the temporary investment for sales demonstrations and usability sessions alike.


There are a few adaptations we, as usability professionals, have to make from a traditional sit-down, two-sided-glass setting. Conference booth testing is a much more informal process, with an emphasis on improvisation and repetition. Some of the tools and methods used in guerilla testing certainly are not as proven or stable, but the potential recruitment numbers outweighs the inconveniences of a non-controlled setting.

From an educational standpoint, being inside the booth for days at a time will raise your knowledge-level considerably. You’ll hear again and again the type of questions and responsive dialog that prospective customers have around the product, and you’ll start to recognize the pain points coming from the industry.

After a half-dozen conferences, you’ll start to understand the differences in the average participant. In the case of the technology-centric attendees, some conferences provide a recruitment base of high-level generalists, with others being much executionally closer to the ground and detail-oriented. I tend to tailor my scripts accordingly, focusing on principles and concepts with the generalists, and accomplishment of specific tasks with the more programmatic participant.

One good thing about working for Loggly o’er here in the startup world is the ability to create paths and practices where there were none before. Pairing with the marketing team, using a portion of the presentation table to recruit participants off the expo hall floor, and sitting them down for a quick walkthrough of the product is a great way to become inspired about what you do and who you’re working for. As someone who still gets excited to travel, meet new people, and play off crowds, these sessions are always a highlight for me to conduct guerilla usability in front of my customers, peers, and my co-workers.

January 07 2014


The Creative Impact of Improvisation

Improvisation is a very old and time-tested form of theater. The earliest use of improvisation is found in records of a Roman farce performed in 391 BC. Given its long history, it’s surprising to me that in our modern world, comedy–and comedic improvisation–is considered a low-brow form of entertainment. It is generally eschewed by the erudite. But it shouldn’t be.

My own experience with improvisation spans 20+ years. And in the middle of that I took a hiatus from performing when my husband and I started a family. For four years, I did no improv. And my brain seemed to stutter to a screeching halt. I felt dull and less energetic. Creativity started taking more effort than it had previously. I felt like I was on autopilot. But I chalked that up to being a new, perpetually sleep-deprived parent. I’m sure that sleep deprivation didn’t help, but at the time I didn’t even realize what the real problem was.

Ramping up my brain

When I first came back to improv from that break, I felt like my brain was having to wade through mud to get ideas out. I looked at my fellow troupe members and marveled at how quickly they could craft a scene or throw out ideas. But after a couple of months with the troupe, my thoughts moved much more quickly. I could keep up with the rest of my team, and I suddenly felt so much more alive than I had in years.

I noticed something else. My creative process at work started to go into overdrive. I was able to generate, dismiss, or accept design ideas very quickly. It was much easier to do collaborative creative brainstorming and get dozens of ideas out because my thought processes had become accustomed to it. I felt like my mental Rolodex (here’s a link for the young whippersnappers who have no idea what a Rolodex is) was stuffed with ideas and was spinning impossibly fast; ideas were flying.

It was a wonderful feeling–like moving out of the fog into the sunlight.

The science behind creativity

I decided to do some research on this, and as it turns out, this isn’t just a fluke, it’s a proven scientific method of improving brain function.

Dr. Charles Limb, a Johns Hopkins University neuroscientist, has dedicated his research to the art of improvisation and how it increases creativity. He has a fascinating TED Talk on the topic. His studies focus on jazz piano improvisation, and he demonstrates that the same increase in creativity is seen when the subject is improvising while rapping.

A post by self-proclaimed “biohacker” Dave Asprey about Limb’s studies summed up what was found to occur in the brain while improvising:

“During improvisation, the self-monitoring part of the brain (lateral prefrontal for you brain hardware hackers out there) deactivated, while the self-expression part of the brain got activated (medial prefrontal). Literally, that means that to be creative, you have to stop picking on yourself while boosting your self-expression abilities.”

Turn off your filters

If there is one thing you get practice doing in improv, it’s in turning off your brain’s filters. In improv, there are no bad ideas, you don’t hesitate on an impulse–you must charge forward with the scene and be fearless about making mistakes.

Applying the same principles in creative work comes more naturally once your brain is trained to do it in an improvisational setting.

So how can you bring this into your own work when you don’t perform improv on a regular basis? Bring the improvisation to your team. There are simple exercises you can do in a team setting that will help break down the voice of doubt and hesitation.

You can begin very simply so that your team becomes accustomed to the idea of improvising. If the idea of finding extra time to do this is daunting, take advantage of weekly meetings (like staff meetings). Set aside one of those meetings a month to do improvisational exercises.

The pep talk

Make it clear to your team that this is an activity where mistakes are expected and even welcome. This is a safe environment for them to be silly…because when everyone looks silly, no one looks silly.

Tell them not to overthink reactions and to act spontaneously. That means listen to what the other players are saying without trying to formulate a response before they’re finished. This forces the players to practice some of the key elements of active listening.

You’ll also want to review some of the basic rules of improv with the team.

Warm up exercises

Keep in mind that in all of these games, there needs to be a coach. Someone directing the team members in what to do. The coach can participate in the warm up exercises, but there are some structures that require a “director” and the coach should fulfill that role.

  1. To get your team engaged, start with an alphabet challenge. There are many names this particular structure goes by, so I’ll leave it up to you to call it what you’d like.

    Have the team stand in a circle.
    Decide who goes first.
    The first person starts by saying a word that starts with the letter “A”, and points at another player.
    The second player must quickly say a word that starts with the letter “B”, and point at another player.
    Repeat this until the team has gone through the entire alphabet.

    This is a simple game, but it primes the brain and gets everyone on the same footing.

  2. A more complex warm up exercise is called “What are you doing?”

    Have the team stand in a line.
    The first player steps forward and begins miming a simple action. (Example: buttering bread.)
    The second player steps forward and observes the first, then asks “What are you doing?”
    The first player responds with something completely different than the action they are miming. (Example: “I’m climbing a mountain.”)
    The second player begins to mime the action the first player said–climbing a mountain in this case.
    The first player steps back to where they were in the line.
    The third player steps forward, looks at what the second player is miming and asks “What are you doing?”
    Repeat the steps above until all of the team members have had a chance to participate.

Intermediate structures/scenes

Once everyone is comfortable with the warm-up exercises, you can move on to some more complex interactions. These involve a handful of participants and the rest of the team act as the audience.

  1. This first scene is called Oracle. It requires three players to act as one entity. It also requires a “handler.” The handler should introduce the all-knowing and powerful Oracle, who can answer any question.

    Have the three players sit one in front of the other at different levels–one on the floor, one on a chair, and one either standing or on a bar-height stool.
    The handler introduces the Oracle and asks if anyone has a question for the all-knowing Oracle. If there is hesitation to ask a question, the handler can suggest a topic.
    (Example: “Today the Oracle will answer all of your questions about bacon. What would you like to know about bacon?”)
    The players answer in order with only one word each. Each player has to build on the word that the player before them said.
    Once that question is answered, the handle asks the audience for another question.

    Audience Member: Oracle, why is bacon so good?
    Player 1: Bacon
    Player 2: is
    Player 3: good
    Player 1: because
    Player 2: it
    Player 3: is
    Player 1: bad.

    The players may want to prearrange a signal that their answer is over. Something physical like waving their arms or snapping would work well.

  2. Freeze tag is a structure that requires players to create a scene based on a physical pose. It takes a little more setup than the other scenes and works best when you have no more than six players at a time. Make sure the coach has a whistle for this one.

    The players stand in a line.
    The first two players step forward.
    If there is an “audience,” ask someone to volunteer to position the two players for the initial scene.
    (Positioning rules: The position should be socially acceptable, the position should obey the laws of gravity, and the two players need to be touching. It can be a little touch–like a finger to a finger–or it can be a lot of touch.)
    If there is no audience, the coach should tell the first two players to assume a position they would if they were playing a sport. The coach should pick a specific sport, and the same positioning rules apply.
    When the players are in position, the coach blows the whistle to start the scene.
    The players must build their scene based on the initial position, but should start moving out of that position as soon as possible.
    After about a minute, the coach should blow the whistle when the players are in an interesting position.
    When the whistle is blown, the players freeze.
    The next player in line approaches the frozen players, taps one of them on the back letting them know they can get back in line, and assumes that player’s position.
    The two players then start a completely different and unrelated scene based on the new position.
    Repeat until all of the players have rotated in and out at least twice.

For more improvisational warm-ups, games, and exercises, you can look through the Improv Encyclopedia.

Remember “Yes, and…”

This handful of exercises will get your team started and help break down mental barriers to creativity. The more you do this, the less they will second guess themselves. And remember to emphasize the king of all improv rules, “Yes, and….”

There is no faster way to kill the energy in a scene than when one player says “no” to another. Forward progress is the objective. If a player tells you that you’re making a documentary on unicorns, don’t say “No, we’re not, because unicorns don’t exist.” The response should be an affirmation and a continuation.

The Benefits of Play

I’m grateful that I took a break from improv while I was a new mom. Putting the focus on my family was the right thing for me to do. And the mental impact of quitting improv taught me valuable lesson. Coming back to it has fundamentally changed the importance I place on collaboration, creative play, pretending, and imagination, both at home and at work.
The National Institute for Play cites multiple research efforts which found that pretend play “remains key to innovation and creativity.” They state that play mixed with science begets transformation.
Whether at work, at home, or on the stage, because of my continued experiences with improvisation, I bring that sense of play with me. Not only does it make life more fun, it has also helped foster an early, more mature sense of humor in my children (now elementary school age) where wordplay, puns, and imagination are a part of everyday conversation. It has also put me on a first-name basis with the principal…but in a good way.
Sponsored post
Reposted byLegendaryy Legendaryy

December 03 2013


How to Breathe Life Into Personas

Personas are essential when you are working on a project and don’t know the target audience very well. For instance, not every designer has experience in fashion or banking. Creating a model of your target audience may help you and your stakeholders feel significantly more empathy for those people.

Personas can also help you get out of the mindset of thinking about users abstractly. “User” sounds like it does not refer to real people who have desires, concerns, past experiences. When real people use your app or website, they are there to reach their goals: to buy something, to research, to register for something they need, or to get information. How can we design something helpful for them without feeling empathy?

Thinking about users as “just users” is just plain harmful. Empathy for the real people who use the website or app, on the other hand, is essential. If we have empathy, we will not design something that would make these people feel trapped, cheated, or confused.

Humane personas

Using  personas enables us to feel more empathy by creating a life-like humans we want to make happy. The problem is, most personas are not designed to make the reader care about the person. Most of them look like dossiers: name, occupation, age, sex, some descriptive text, and a Google image search photo.  Why would anyone care about a persona that looks like a PowerPoint slide?

A usual, dossier-like persona.

A usual, dossier-like persona.

We should also always keep in mind that stakeholders are also “users.” We have to make our deliverables real easy for them to understand.

I wondered: What would make my personas more humane? The bullet-point personas really made me feel ashamed as a designer. I was sure that these deliverables would not reach their desired goal which is to put me and my stakeholders into the mind of the people who use their web site. So why do them that way?

Making life-like personas

The humane speech bubble persona

What would make my personas human? I made some concepts, researched, tested, and refined again.

I started to look for a solution. As a good UX designer should,  I did some Google searching, sketched, and then fleshed it out. I went through many versions until I found one I was happy with, and response from project teams seems to be positive. I think these deliverables can be developed further, though. I call the result the Humane Speech Bubble Persona.

Where a traditional persona would list attributes in bullet points, I had the persona tell his own story, in speech bubbles.

The key bubble is the worldview. It represents  the central attribute that tells us who our person is, summarizing the person in a single bubble.

Worldview speech bubble

Worldview speech bubble

Then I added bubbles with attributes like “motivation,” “looking for…,” and “desired experience,“ which help us focus on the goals of the person. Adding the opposite of these, such as “demotivation,” “not looking for,” and “last experience,” is also beneficial. Finally, I added the persona’s questions. This helps us focus on the needs and concerns of the user.

The unsolicited insight that comes from an overheard conversation means you get useful information that wasn’t meant for you. The bubbles recreate that experience for the users of the persona.

Presenting text attributes in speech bubbles make the persona humane as well. Speech bubbles show the person speaking, in easy-to-follow sound bites. This makes the persona scannable and adds some fun to the deliverable.

Finally, to make the persona more scannable and relatable, I added pictures from the persona’s imaginary life to help us visualize the persona as a human being. The pictures represent both current as well as desired objects that the persona cares about. As well, when personas are hanging on a far-off wall, they provide an easy way to remember who this persona is, and what he really cares about. No reading necessary!


Making personas humane not only benefits you, the UX designer, but your stakeholders as well. Adding flavor to deliverables does not take a lot of effort, so why not do it? A humane persona will help us feel empathy for the real people who will use our designs and will help stakeholders accept concepts readily.  Try out the Humane Speech Bubble Persona, and let me know what you think!

For some more insight how I made this persona template, read my article on my website.

October 29 2013


Context matters

What makes a marketing e-mail or newsletter efficient? One can judge, for instance, by the number of users that opened the message or clicked on a specified element representing primary action, such as a product link or button.

Those indicators measure user engagement precisely; however, they are limited to the last phase of interaction with e-mail or newsletter. The act of clicking certain element in a marketing e-mail is a result of a longer process of identifying, assimilating, and analyzing its content. It is in those three steps that the decision is made to take action or not, and it is those three steps that are not analyzed or included in standard efficiency measurement, such as CTR or open-rate.

Therefore, click-through-rate or open-rate measures only completed processes, not taking into account those interrupted. Moreover, those parameters do not inform us about “why” a certain user decided to click or abandon the message.


One way to understand what is happening in users’ minds is to observe what they really see, which cannot be done using the traditional methods of e-mail research. Instead, we used eye tracking on a desktop computer to record the person’s gaze while looking at the e-mail message, checking which objects they looked at, for how long, and which elements, among the whole field of the vision, attracted their attention the most.

To check what kind of impact some of the characteristics of e-mails have on users, some of the stimuli were transformed by our team. For instance, we modified location of logo and the calls-to-action, changed size of prices, or flopped photos change the direction the person in the photo is facing.

Each of the stimuli used in the study had two versions–an original and a modified one. Each version was seen by 27 participants. All of the heat maps in the report are derived from the averaging of 10 second long scan paths of 27 subjects.

Observations: Testing known principles and their variations

Our different observations confirm some of the generally known design principles, such as users’ deep-rooted dislike of homogenous blocks of text.

At the same time, some of our hypotheses were disproved. For instance, reducing the length of introductory text did not result in an increased number of users reading it. In fact, introductory text was so rarely read that a general recommendation from our research is to remove it all together in favor of items that really matter.

Text and reading

Learning how to read and gaining experience in this activity shapes our perception since early childhood. In our (Western) culture, we read from left to right and from top to bottom. This becomes a strong habit and this strategy of scanning a visual stimulus is executed automatically, even if the viewed stimulus does not contain text.1

What is more, readers on the web are very selective.2 They constantly search for valuable content, but when the required amount of effort increases, their motivation plummets. Below, we describe further and illustrate those phenomena with the examples from our study.

Blocks of text

It may sound like a truism, but it is always good to have in mind that a homogenous block of text is not a good way to communicate with the Internet users.2 One can often observe in eyetracking studies that users tend to skip this kind of content, without making even the slightest attempt to read it.

Fortunately, there are some tips and tricks which can make the text more attractive to the user’s eye. First, formatting which includes clearly distinguishable headlines and leads often results in a phenomenon called F-pattern.

Fig. 1: A heat map showing an F-pattern


Readers have a strong tendency to scan headlines briefly, and they usually start to read from the top of the page. Their motivation to focus their attention on a written content decreases gradually, so you may expect that the first few headlines (counting from the top) will be read, and that the lower the headline is located, the less attention it will get.

Introduction text in an e-mail message

Reading requires time and effort, and the recipients of a newsletter want to quickly get exactly the information they are interested in (which usually means the special offers). It did not surprise us that introductory text in a newsletter would be ignored most of the time.3

But what to include in the marketing message instead of introductory blah-blah text? The answer seems obvious–more valuable content, such as the products we want to present.

Our study confirmed that hypothesis: After cutting most of the introductory text out, the amount of attention focused on it did not change much. On the other hand, the products presented in the message benefited greatly in terms of attracting users’ gaze.

Fig. 2: Scan paths. Left, without introductory text. Right, with introductory text.

Fig. 2: Scan paths. Left, without introductory text. Right, with introductory text

Properties of numbers

The next thing we wanted to focus on was if numbers caught a human’s eye. Nielsen4 suggested that numbers written as numerals are eye-catching, whereas numbers written with letters are not, because they are indistinguishable from an ordinary piece of text.

Fig. 3: Heat maps. Left, the original version with large numbers. Right, the modified version, with downsized prices.

Fig. 3: Heat maps. Left, the original version with large numbers. Right, the modified version, with downsized prices

We studied how long the participants focused their gaze on numbers, depending on their size. The difference between small and large digits turned out to be statistically significant. The average difference between small and large number approximated 200 and 400 ms for both prices depicted in the stimulus. From the psychophysiological perspective, this is a long time. The longer we fixate on an object, the deeper the processing and understanding of the visual information.5

Communication through images

Pictures: What’s worth it, and what’s not

One of the widely known phenomena which can be observed in eyetracking and usability studies is so-called banner blindness. In short, web users tend to act as if they were blind to advertisements or other types of redundant information, which can only distract them from completing the task. This adaptive mechanism applies as well to stock photos and to pictures which do not present the real products or people. Pictures without informational value may even pull the viewers’ attention away from the valuable content because they may be easily classified as an advertisement, which is usually neither informative nor relevant.

Directing users’ attention by faces

Some types of pictorial stimuli are almost always classified as important. One of them is certainly a human face. We are social animals, so we are perfectly wired to automatically read the subtle social cues, for example those connected with decoding where the attention of another human being is directed at the moment.

Fig. 4: Scan path

Fig. 4: Scan path

And example of how this reflexive mechanism works can bee seen on the picture above. The participant automatically followed the gaze of the model right after noticing her face.

In the original version of this newsletter the model looked straight forward. We have created the modified version in which the model is looking at the logo. We tested both versions with our participants, and then we examined whether there is a significant difference in the amount of time the participants fixated on the logo. In the modified version, the average time of focused gaze on the logo was significantly longer.

Fig. 5: Heat maps. Left, the original version. Right, the modified version, with gaze direction diverted

Fig. 5: Heat maps. Left, the original version. Right, the modified version, with gaze direction diverted


Our observations and recommendations are rooted in a number of studies focused on what recipients do really see while looking at advertisements in email campaigns. Some of the effects repeated in our 2011 and 2013 studies; some of them were also confirmed in studies on the perception of the e-mails and newsletters carried out by other teams.

But we should not forget that those are general laws, which, however, in particular creation may be not fulfilled due to various mitigating factors, such as the content of the e-mail, its size, and the level of the audience engagement.


1Ziming Liu, (2005) “Reading behavior in the digital environment: Changes in reading behavior over the past ten years”, Journal of Documentation, Vol. 61 Iss: 6, pp.700 – 712

2 Nielsen, J., (1997), How Users Read on the Web, Retrieved 15 June, 2013, from

3 Nielsen, J., (2007), Blah-Blah Text: Keep, Cut or Kill? Retrieved 15 June, 2013,rom Ros Hodgekiss, (2011),

Email usability: The science of keeping it short and sweet, Retrieved 15 June, 2013, from­-sweet/ ]

4 Nielsen, J., (2007), Show Numbers as Numerals When Writing for Online Readers, Retrieved 15 June, 2013, from

5 Poole, A., and Ball, L. J. Eye tracking in human-computer interaction and usability research., Encyclopedia of human computer interaction. Idea Group, Pennsylvania, 2005, 211-219.

May 28 2013


Going Beyond “Yes – and…”

My first experience in improvisational comedy was in 1989. I was a freshman at Texas A&M University. Some of the students in the theater department decided to get an improv troupe started and somehow talked me into joining them.

In the beginning, I was petrified to perform without a script. Looking back now, I can see just how much improv has taught me and how it informs the decisions I make when working with a project team to create a cohesive user experience.

There are a multitude of “rules” to improv. The one most people are familiar with is the rule of “Yes – and.” The principle behind “Yes – and” is that for a story to be successfully crafted, all players involved must agree on the premise. So if a fellow actor points at you and says “your face is green,” you accept that and move the scene forward with a green face.

What we don’t often hear about are all of the other rules of improv that can be pulled into daily work as an experience designer. What happens after you’ve said yes? What comes after the “and”?

I’ve combed through my books and through various improv websites to pull out rules I started taking for granted about 20 years ago and was surprised at just how much the regular practice of these rules has shaped my perspective when creating designs with a team or client.

Add new information

The follow on rule to “Yes – and” is add new information. Have a plan when you say “and.” You can’t move the scene forward without it. And there will be times that saying yes is very difficult. What the team or client wants is not always what you will feel is the best aesthetic, so delicately phrasing your yes’s is important.

So, if a stakeholder is telling you they want a monochromatic blue palette for their website, you answer “That sounds great – and we can use complementary color accents, like yellows or oranges, to highlight important calls to action.”

Don’t negate or deny

The opposite of “Yes – and” is “No – but.” When a project kicks off, don’t start with what the system limitations are, don’t start with the baggage of knowing that the experience needed will break corporate standard rules.

Negating is also referred to as blocking. Take time to think when your first reaction is to deny, negate, or block someone else’s ideas.

If your product owner says “we want to add social media buttons to this,” don’t tell her that’s a dumb idea. That’s a knee jerk reaction, with the operative word being jerk. Explore the idea. Think about what benefits social sharing may bring to the customer and the business.

Always check your impulses

Checking your impulses isn’t limited to cases where you want to negate or deny something. You also have to check your impulses to see if what you’re thinking aligns with the product goals. If you have design principles set out for your project, measure your impulse against them to see if it aligns with those principles.

You may have a fantastic idea, but if it’s not part of the goals of the project and doesn’t align with scenarios, personas or design principles, table that thought. Write it down for a future project where it may be a great asset.

Look beyond the words

If you’re designing experiences, you have either become or are becoming a keen observer of human interactions. Look at physical cues of people you’re meeting with. Is someone uncomfortable or unusually silent? Maybe they aren’t good at speaking out in a group setting, but if you chat with them afterwards they may offer you a wealth of insight you would have otherwise missed out on.

The same goes with usability testing. Don’t just look at how easily or efficiently the participant is getting through your flow, look at their body language. Look at their forehead – is the brow furrowed? Are the eyebrows raised? Are they tapping their feet nervously? Or are their shoulders relaxed?

Aside from just the physical, there may be underlying motivations for the way people are behaving. Try to get to the heart of the meaning behind their words and actions.

Never underestimate or condescend to your audience

Underestimating your audience is a diva move to make. That doesn’t mean you should throw around words like “affordance,” or refer to “Fitt’s law” with people who aren’t design professionals, but it does mean that you need to be careful not to talk down to them. Talking down to someone tells them that you think you’re better than they are. And guess what? You’re not.

We all have roles to play in our daily work, and one is not necessarily more important or more clever than the other. Give your “audience” respect, and you will get respect in return.

Work to the top of your intelligence

This is the flip side of not underestimating your audience. Don’t underestimate yourself. Working to the top of your intelligence means not taking the easy way out. If someone says “but that’s how we’ve always done it,” challenge the status quo.

Push yourself every day to do something better, to learn. Keep up with the blogs and articles about UX practice and theory. Engage your colleagues in meaningful, actionable discussions about the work you’re doing.

Trust your partners

Every project you work on comes with partners: front end developers, project managers, stakeholders, information architects. Trust them to do their jobs. They got where they are for a reason.

In return, you should expect them to trust you to do your job. If they don’t, then that’s an important conversation to have with your partners. Help them understand why they need to trust you.

And most important of all, trust yourself. Your experience and your expertise led you to where you are today. You need to trust in your own talent and skill. Because if you don’t trust in yourself, you can’t possibly expect others to trust you.

Do try this at home (or work)

With every new venture you have to start somewhere. I was petrified as a teenager trying improv for the first time. I can remember it very clearly. But now improv is second nature to me. Public speaking is not an issue. I was never a shy or quiet person, and improv has given me more confidence and tools to work with.

That didn’t happen over night. It happened with repeated practice. Take these rules and try putting them into practice in your daily routine. Three months from now, see what changes this has brought to your projects, clients and project teams. You’ll be pleasantly surprised.

April 09 2013


The Shallow Dive

At a recent job, my department faced large budget cuts. When the dust had cleared, I found I had become a UX group of one. This didn’t come with a corresponding slowdown in work – in fact, following a major rewrite of our call center application, our department was already struggling to keep pace with a backload of business initiatives. Cuts slashed our BAs, our development group, and our QAs, yet everyone remaining was being asked to speed up.

I needed to find a way to work faster and smarter and decided to address inefficiencies in my design process. As I did so, a couple of key concerns stood out for me:

Get critical design decisions made as early as possible: To go from an exploratory design to a final solution, numerous decisions needed to be made by the client. To elicit those decisions, I needed to give the client wireframes or prototypes that provided a clear context. The earlier these decisions were made, the faster I could complete the detailed design.

Reduce the client’s dependence on high-fidelity wireframes: I had routinely been asked to make painstaking changes to an early set of high-fidelity wireframes, only to discard those pages as we moved towards a final solution. Frustrating? You bet. Instead, I wanted to drive the design in the manner that Bill Buxton described in Sketching User Experiences: The fidelity of a prototype or wireframe should reflect its stage of refinement. This meant introducing low-fidelity items into the process.

Diving In

The concerns above dovetailed nicely, and to address them I formalized an early design stage I call The Shallow Dive.

Instead of attempting to achieve a final design solution, The Shallow Dive is an early UX analysis phase that is solely concerned with identifying design issues. The aim of this phase is to identify key elements and decisions that will influence the detailed design of the project.

Rough draft wireframe

A first, rough draft of wireframes is refined with the development group and then discussed with the client.

To start, the BA and I do a first-wave analysis of all of the screens and workflows that might be affected by the project. Then I create a first, rough draft of wireframes. We then refine these with the development group.  After discussing the wireframes with the client, the resulting decisions are carried forward into the detailed design.

The types of things that we look for might include:

  • What is the optimal hierarchy on each page?
  • What information is required to be carried from step-to-step of a multi-step flow?
  • What options need to be presented immediately, and what can be hidden?
  • Can we remove some non-critical information from the initial display?

Goal #1

The sole goal of The Shallow Dive is to speed the transition into a detailed design phase.

A number of things could slow this transition down. Lack of clarity in requirements may confuse translation into screen designs. Requirements that look good on paper may suffer when visualized. Without proper insight into the context of use, direction and priorities may be unclear.

To this end, within The Shallow Dive we also:

  • Identify and resolve key decision points affecting the detailed design.
  • Resolve any ambiguities encountered when the requirements are translated into screen designs.
  • Identify and document any usability issues that may appear.
  • Identify any user research needs.


This approach has worked well. It gets the client’s project manager into the spirit of iterative design right away. Since the first set of wireframes is deliberately rough and clearly emphasizes one or more design issues, the PM ‘gets it’ and understands the process of chipping away towards an ultimate goal. The PM shows those rough wireframes to their management, who become acclimated to using them to address a few key points, rather than solve all aspects of the project. If suggestions are made about an item that I don’t think is important at the present time, I make a note to ‘fix it in the mix’ and address it in the final design phase.

The Shallow Dive has some key advantages. Critical decisions are made earlier in the project, reducing the need for multiple iterations of detailed wireframes. This eliminates wasted time and shortens the design effort. Targeting the entire project allows us to present a comprehensive list of questions to the client at once, allowing for more effective use of the valuable face time with management. As well, the client gets experience in evaluating rough designs, making it easier to share ideas.

But most of all, the client accepts that design takes place in stages and doesn’t demand a comprehensive solution from the get-go. And that, my friends, is a little slice of heaven.

March 26 2013


Site Speed and Usability

Did you know usability tests have shown that the maximum number of seconds a user is willing to wait, on average, before abandoning a web page, is 8.6?

If that number surprises you, it should. The study took place in 1994.

The bar is exponentially higher now for people involved in website user experience design and development when it comes to load speed. Here’s a quick look at the state of affairs.

Slow speeds are a real usability challenge. According to software and monitoring experts at Gomez and Akamai, most users (up to 73%) have encountered a site that was too slow, crashed, froze or otherwise didn’t perform.

Your visitors’ expectations are high. A sizeable 47% of consumers expect a page to load in 2 seconds or less, and 40% of people will abandon a page that takes more than 3 seconds to load.

Slow load speed can be a costly challenge. These sources estimate that a 1-second delay can lead to a 7% drop in conversions, meaning that an e-commerce site doing $100k daily would experience a $2.5M loss in sales on an annual basis tied to 1 second in load speed.

If you’re curious about the impact of load speed on conversions, and want to learn about users’ expectations for mobile browsing vs. desktop browsing, KISSmetrics has built a stellar infographic on the topic.

Mozilla ran a study to test a similar concept: what happens if the development team combines files and rearranges the source to make the Firefox home page load 2.2 seconds faster? You guessed it. Conversions increased dramatically. Firefox saw a 15.4% lift in browser downloads.

If all of this weren’t compelling enough, you should also know that organic search results can be negatively affected by slow load times. If you run search engine advertising, you’re familiar with quality score—Google’s determination of how ‘relevant’ your ad is—and you know it impacts the per-click price of your ad. Landing page speed is part of the quality score determination, too.

You get the point. The need for speed is great, and there’s a lot at stake.

What can you do to improve load speed?

There are a lot of solutions for improving how quickly your site loads. Some are simple and quick to implement, and others are tougher to tackle. Here’s a strategy to start moving your site in the right direction.

Run speed tests. Use Google’s PageSpeed Insights tool. See what easy-to-implement suggestions it spits out and heed the recommendations.

Then run your site through the Pingdom speed tool. How many requests have to be done to load your site? Are there tracking scripts that might be outdated or aren’t needed anymore? Can you consolidate any of the other requests?

Knock out the low-hanging fruit changes. Some of the recommendations you might receive include things like:

● Minimize HTTP requests.
● Resize and optimize images.
● Optimize multimedia.
● Convert JavaScript behavior to CSS.
● Use server-side sniffing.
● Optimize JavaScript for execution speed and file size.
● Convert table layout to CSS layout.
● Replace inline style with CSS rules.
● Minimize initial display time.
● Load JavaScript wisely.
● Create a dedicated landing page for mobile.

Install plugins to simplify your process. Your content management system might have plugins available that’ll make your life easier. For example, here are a couple of popular WordPress plugins that help with load speed in various ways.

W3totalcache improves site performance by improving caching with respect to the browser, page, objects, database and more. To learn more about this, you can read up on configuring the W3 total cache plugin.

WP—Especially if you’re a blogger, you probably use plenty of images, and images can take considerable time to load. This plugin reduces image file sizes and improves performance by compressing the files.

WP Optimize—This plugin allows you to clean up and optimize your database, especially if you’re a blogger with significant archives.

When in doubt, simplicity is key. Don’t be afraid to gut components that increase load time and A/B test simpler versions of the page against their predecessors. You may be surprised at the impact of a faster loading page, even if it suddenly has less of the stuff you once considered critical.

Toby Biddle is a seasoned website usability expert and CEO of Loop11, a tool for unmoderated online user testing.

Footnotes and sources

1 Nielsen, J. (1994). Usability engineering. London: Morgan Kaufmann.
2 You can learn about the Mozilla site speed case study here.

January 08 2013


Interviewing Executives and SME Stakeholders

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Senior executives

Ideally, there is at least one executive involved who has cross-functional authority and can balance the perspectives of both marketing and engineering; you need this person to make critical decisions, such as what’s worth waiting a little longer for. These are usually the most critical stakeholder interviews, because the way other team members approach product development depends on the views of the people at the top.

It can be difficult to get on a senior executive’s schedule, particularly if the executives regard the product’s design as a secondary concern. If they seem reluctant to spend the time, point out the kinds of strategic decisions that will be made in the course of the design work. However, most executives are more willing to spend this kind of time than people expect.

The concerns of senior executives may include any of the concerns mentioned above for marketing, sales, or engineering, as well as a common concern that they can’t get their subordinates to “see the big picture.”

What do we need to know that you don’t think other members of your team have said?

Senior executives often have a vision or perspective that others in the organization don’t. If they’ve shared that vision much at all, you will have heard it already from multiple people, but some executives communicate about their vision less than they think they do.

We know that both timeline and functionality are important, but if you had to choose one, what would it be?

When there seems to be some controversy about schedule, it’s usually because senior executives are asking to their teams to make omelettes without breaking any eggs. Mention the controversy, then ask what timeline they want you to design for and whether they would rather go to market with an incomplete product or delay shipment to get a product that meets more user needs. (Some designers frame this as “do it fast or do it right,” but it’s best to suspend this kind of judgment; sometimes, doing it “right” means shipping at a certain time to get critical revenue in the door, so tradeoffs have to be made.)

Subject matter experts

If you are working on a consumer product or a business product that involves common work or life activities, you probably won’t need domain experts to help you understand what you see in your research. For products in complex industries, though, subject matter experts (SMEs) are incredibly helpful to have around—so helpful that you might want to hire a consultant to spend a few hours here and there, if there is no expert already on the product team. Even in-house designers with a lot of experience working on certain products can benefit from the perspective of people with deep industry expertise, though they may be able to skip some of the following questions. In-house SMEs are usually part of a product management or professional services group.

A subject matter expert isn’t just someone who was a user (or did a similar job) once upon a time—it’s someone who has broad and deep industry experience and who understands industry best (and worst) practices. If your product overlaps a couple of disciplines, it’s best to have an SME in each; for example, when designing a device that delivers intravenous medication to patients in a hospital, we found it helpful to have the perspectives of both a pharmacy expert, who had a thorough understanding of the drugs, and a nursing expert, who had a thorough understanding of clinical practice.

Beware of getting presumed SMEs who are a little outside their expertise, though—for example, a surgeon who spends his time in the operating room is not an expert in how nurses do their jobs on the hospital ward.

Unless they’ve worked with you before, SMEs will be more concerned than anyone else that you won’t be able to understand their incredibly complex world, since it took them many years to get where they are. They usually wind up surprised at how quickly immersion in the usage environment can educate the design team. However, it’s important to be clear that good research techniques will let you develop a working vocabulary and high-level understanding very quickly, but you will be absolutely reliant on the SMEs for their detailed knowledge.

Spend a couple of hours with SMEs before the user interviews to get some background. Get definitions of terms, ask about best and worst practices, common processes, and regulations. If you’re talking about processes, ask the SME to diagram them on the whiteboard or do this yourself, using your sketches as a discussion tool.

Specific topics will vary by domain, but here are some typical topics to cover with SMEs:

What are the typical demographics and skills of potential users, and how much do these vary?

This information is handy for planning your interview sample, as well as for assessing how typical your actual interviewees seem to be in these respects.

What distinctions in user roles and tasks would you expect us to see?

A SME may be able to tell you about likely differences, such as tasks that vary based on seniority or skill levels that differ with geography. They probably won’t be able to point out all of those factors that make people behave differently, but they should at least be able to give you enough background to help determine how large an interview sample you need.

What sorts of workflows or practices do you think we’ll be seeing in the field?

Some SMEs will describe only the best practices in their industry, while others are very good at pointing out where reality tends to deviate from what people are supposed to do. This kind of discussion is a great way to think about topics you’ll want to explore in user interviews. However, avoid getting into tremendous detail or spending more than an hour or so on this, because you will still want to look at user behavior from a fresh point of view. A certain amount of ignorance helps you ask the naïve questions that can lead to important insights.

Other product team members

In theory, some organizations place QA and support on a par with marketing, sales, and development, but in practice, these organizations seldom have much influence over product direction. However, they may have a variety of useful insights, and at a minimum, they will be able to answer two important questions.

An experienced QA manager can often tell you how solid the engineering team is and can point out process holes that are currently leading to problems. The support or customer service team can tell you where users are most often encountering problems today, whether this is based on tech support calls for software or common failures for hardware—either could mean a flaw in the current design. In some companies, there are other groups that can provide useful information, as well, such as the training staff or technical writers, who may be able to identify where users most often get confused with the current products. Regulatory experts are also indispensable for medical products.

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.


A Stakeholder Interview Checklist

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

A Cheat Sheet For Interviewing Stakeholders

If you need a little help in your stakeholder interviews, tape a copy of this summary inside the front cover of your notebook.

Things to watch out for

  • Presumed constraints—ask why they are constraints
  • Jumping to solutions—ask what problem the solution would solve

All stakeholders

  • What is your role in this project?
  • What did you do before this?
  • What is this product going to be?
  • Who is this product for?
  • When is the version we’re designing going to be released?
  • What worries you about this project? What’s the worst thing that could happen?
  • What should this project accomplish for the business?
  • How will you, personally, define success for this project?
  • Is there anyone you think we need to speak with who isn’t on our list? Who?
  • How would you like to be involved in the rest of the project, and what’s the best way to reach you?

Marketing stakeholders

  • Who are your customers and users today, and how do you want that to be different in five years?
  • How does this product fit into the overall product strategy?
  • Who are the biggest competitors and what worries you about them?
  • How do you expect to differentiate this product?
  • Using a few key words, how do you want people to see your brand (both the company brand and the product brand)?
  • What is the current state of the identity, and can we see a style guide (if there is one) and examples of it applied to materials?

Engineering stakeholders

  • What technology decisions have already been made, and how firm are they?
  • How large is the development team assigned to the project, and what are their skills?
  • Would you draw a diagram and tell me in lay terms how the system works? (existing products only)

Sales stakeholders

  • Who is typically involved in the purchase decision?
  • Why do customers buy a product like this one, and why this one over competitor’s?
  • When you lose sales, what are the most common reasons?
  • What things do customers complain about or ask for most often, and why?

Senior executives

  • Questions similar to those for marketing stake-holders, plus:
  • What do I need to know that you don’t think other members of your team have said?
  • If you had to choose between going to market on schedule with a flawed product, or going to market late with a solid product, which would you choose? (If there seems to be some conflict on this point)

Subject matter experts

  • What are the typical demographics and skills of potential users, and how much variation in these is typical?
  • What distinctions in user roles and tasks would you expect us to see?
  • What sorts of workflows or practices do you think we’ll be seeing in the field?

Other product team members

  • QA: What problems do you currently see in development?
  • Support or customer service: What problems do you see most often?
  • Training or technical documentation: Where do users most often get confused today?

All parts of the chapter

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.


Project Management for Stakeholder Interviews

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

With good planning, most of your stakeholder interviews should fit within three or four days. Don’t plan on more than six interviews in a day, since they require a lot more energy than most people expect—you have to absorb what people are saying, figure out what the implications are, lead an effective interview, and take thorough notes all at the same time. A quick lunch and the occasional restroom break are essential. Plan on a short break after every couple of interviews to chat with your teammates, if possible. This table shows an example schedule.

Monday Tuesday Wednesday 8:00 Kickoff meeting Simon Parker (European sales) 8:30 9:00 Cristina Walker (clinical SME) Nothing scheduled—debrief, review materials 9:30 10:00 10:30 Ellen Kent and Ed Lieberman (product managers), walk through existing system Maria Torres (QA manager) Marty Long (mechanical engineer) and Jay Adachi (electrical engineer) 11:00 11:30 Lunch and debrief Noon Lunch and debrief Lunch and debrief 12:30 Vijay Gupta (GUI lead) and Adam Matievich (lead architect) 1:00 Anders Haglund (sales VP) Collin Smith (CEO) 1:30 2:00 Ron LaFleur (products VP) Cynthia Woo (corporate marketing) Debrief, review schedule with Kate Riley (project owner) 2:30 3:00 Debrief Debrief Gunter Vering (professional services) 3:30 Tim Walsh (director of product management) John McIntyre (support manager) 4:00 Robin Sachs (regulatory issues) 4:30 Debrief, review schedule Debrief, review schedule

Try for at least a couple of the most critical stakeholders near the beginning of your schedule. If a few of the others need to be worked in between user interviews, that may not be a problem, but it’s preferable to finish stakeholder discussions first. That way, you’ll be aware of all the assumptions, opinions, and open issues you need to address in the user research.

When You Can’t Interview Stakeholders

The approach outlined above works well when you have an officially sanctioned project with support from the management team. If you don’t, how can you get some of this information? First, consider trying to get some of these meetings anyway; you may be surprised at how willing some executives are to spend time with you if you ask for help. Send them a persuasive, thoughtful email about how what they know could influence the design and how design decisions can affect business issues. Consider giving them a compelling article or short, interesting book on the subject. Seriously, try anything that won’t get you fired, because their involvement is ultimately necessary for the project to succeed. The one thing that won’t work is whining that you’re being excluded—instead, show them something so impressive they’ll see the value of including you for themselves.

If you simply cannot get access to the right people, see if you can get access to relevant documents they’ve created—white papers, memos, presentations, or whatever you can find. Build relationships with people in their departments so you can at least get indirect information. Above all, don’t give up—keep looking for opportunities to get them involved. Otherwise, they may very well involve themselves later, often with unfortunate results.


Goal-Directed design isn’t just about accomplishing user goals; a product or service that doesn’t also accomplish a business goal is a failure. Never shortchange your stakeholder research, even if it means compressing your time with potential users. Always:

  • Identify the full range of stakeholders and meet with each
  • Take advantage of the expertise that’s available
  • Learn about hopes, fears, beliefs, and goals
  • Avoid taking assumptions at face value
  • Remember that you’re not just asking questions—you’re also building essential relationships

Once you have a solid understanding of the business, you’re ready to move on to research with potential customers and users.

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

September 27 2010


The Stranger's Long Neck

Show Time: 33 minutes 42 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

Gerry McGovern has recently published The Stranger's Long Neck - How to Deliver What Your Customers Really Want.

Ireland’s Gerry McGovern shares a few of the key ideas in his recent publication The Stranger’s Long Neck – How to Deliver What Your Customers Really Want. Mr. McGovern, who will be teaching a Masterclass series in Canada on the importance of task management this November, discusses several of the key findings in his new book, including:

Trading with strangers

- The customer is a stranger. On the Web, the customer isn’t king—they’re dictator. When they come to your website, they have a small set of tasks (long neck) that really matter to them. If they can’t complete these top tasks quickly, they leave.
- There is an existential challenge going on right now between organization-centric and customer-centric thinking. Customer-centric thinking is winning.

From Long Tail to Dead Zone

- The Long Tail theory says that the Web allows you to sell more of less, that we are seeing the decline of the blockbuster and the rise of the niche.
- The Long Tail is often a Dead Zone of extremely low demand and hard to find, poor quality products.

The rise of the Long Neck

- The Web is exploding with quantity but quality is still relatively finite. Quality is the ‘long neck’; the small set of stuff that really matters to the customer.
- Understanding and managing the long neck has never been more important.
- Remember that the customer’s long neck—what really matters to the customer—is rarely the organization’s long neck —what really matters to the organization.

A secret method for understanding your customers

- A unique voting method that identifies your customers’ long neck.
- Developed over 10 years, with over 50,000 customers voting in multiple languages and countries.
- Used by the BBC, Tetra Pak, IKEA, Schlumberger, Wells Fargo, Microsoft, Cisco, OECD, Vanguard, Rolls-Royce, US Internal Revenue Service, etc.

Organization thinking versus customer thinking

- Case study that shows how car company managers think differently about how customers buy cars to how customers themselves think.
- Explanation of how to frame the task identification question.

Deliver what customers want—not what you want

- Case study of Microsoft Pinpoint, a website to help businesses find approved Microsoft IT vendors and consultants.
- What’s the top task of US small and medium businesses when it comes to IT? Security.

Measuring success: Back to basics

- Why traditional web metrics such as page views, number of visitors, etc., are often misleading
- Observation-based technique to measure online behaviour.
- The key metrics of task measurement: completion rate, disaster rate, completion time

Carrying out a task measurement

- The benefits of remote measurement
- How to run an actual measurement session

This podcast has been sponsored by:

iTunes     Boxes and Arrows Podcast theme music generously provided by Bumper Tunes

Publishers of world class content for students, researchers, and practitioners in the UX and HCI fields. To learn more visit

From concepts to rich prototypes and detailed specifications, all in one tool. Get your free 30-day trial at

The design behind the design
Boxes & Arrows: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there.

September 13 2010


So You Wanna Build a Library, Eh?

Modular Web Design book coverThe following article is an abridged version of Chapter 7 of Nathan Curtis’s 2009 book, Modular Web Design published by New Riders. The book’s first half addresses how to modularly break down your design, build it back up, and communicate in new and interesting ways. With those design techniques in hand, the book then drills into how to organize and build a library, teach it to others, and establish a process for maintaining it for an organization.

Legos are so freakin' awesome!!! Design patterns and modular components are effective techniques for designing and building long-lasting, consistent experiences. You may reach the point where you ask yourself “Is it time to build a library for our team?”

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. It takes time and effort to get off the ground, can trigger significant and uncomfortable organizational change, and comes with an ongoing maintenance cost. In some cases, libraries are not the answer and yes, sometimes libraries fail. Nobody wants to invest the time, effort, and personal capital only to have nothing to show for it.

Therefore, precede any kind of library build out with a period of discernment. Before you dive, ask yourself and your teammates the following eight questions to gauge whether a library is right for you.

1. Why Do You Want Create a Library?

What is your primary rationale for building a library? What motivates you?
At the top of nearly everyone’s list is usually one of two benefits: efficiency or consistency. Some value speed through reuse: get design done faster, be more productive, save time, save money! Others see opportunities for governance and consistency, using the library as a baseline to sustain a design system over time.

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial.

Beyond efficiency and consistency, other benefits that drive teams include:

Memory: A destination to record and refer to all the design decisions made in creating a large-scale experience.

Portability: Designers come and go. Project priorities change. A library should make you more nimble in shifting resourcing and focus.

Vocabulary: Establish and promote common understanding that includes terms you use for items, page types, and even deliverables.

Authority: Provide a more credible resource on which to make design decisions, prioritize efforts, and easily refer to conventions.

Predictability: Have a foundation to discuss and more closely approximate the impact of a design decision.

Collaboration: Amp up collaboration in your organization to trigger conversations, share knowledge, and learn together.

2. Are You Building the Right Kind of Library?

When it comes to libraries, teams usually find themselves choosing between a library of patterns or components.

A design pattern is a solution to a recurring problem. Patterns offer principles to follow and avoid specifics like style, editorial guidelines, page location, and finalized code. Libraries of design patterns are ideal for teams that design many experiences, such as Yahoo’s team that designs products with unique visual systems that adhere to a larger, common brand.

A component is a chunk of a page design. Experiences can reuse components for navigation (such as header, footer, and local nav), content (such as video players and page titles), and more. A component library is ideal for organizations that have built a system of modular HTML and CSS, and these teams can complement the code library with a collection of reusable design assets for wireframes or comps.

Choosing between patterns and components may not be an either / or question. In fact, one team built libraries for both patterns (for example, Tabs) as well as components (for example, tabbed product details, tabbed content module, tabbed search results, and so on). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.

Consider a pattern library if your team has:

  • Many design systems that are intentionally different or will not be reconciled into a single component library.
  • Capability to document patterns more specific than public libraries like Yahoo Design Patterns,, and
  • Known opposition to prescriptive approaches, but a willingness to use common guidelines.

Consider a component library if your team has:

  • A specific visual design system, including grid(s), layout, color palettes and typography.
  • Many reusable components (page “chunks”) within that system.
  • Diverse groups across an organization that must work together using that system.
  • Interest in and capability of sustaining that design and code system across groups, projects and time.
  • Strong, centralized influence to create, deploy, and maintain a library (or plans to centralize influence via a library).
A comprehensive library of design standards doesn’t end with design patterns and modular components. A team could consider … include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

Finally, a comprehensive library of design standards doesn’t end with design patterns and modular components. Instead, a team could consider expanding their repertoire to include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

3. Is Your Experience Ready for a Library?

Ok, so you’ve got dreams of efficiencies, consistency, standards, and more. However, just because you’ve built a website, that doesn’t automatically imply that you should build a library. In fact, there are plenty of websites for which a library won’t net any benefit. You should take a long, hard look at your design system to ensure it warrants a library.

Scale: Libraries can be invaluable to large, distributed teams supporting many products or a site with thousands – or millions – of pages. On the other hand, if you are a small and tight-knit team constantly communicating across cube walls, then there’s no need to codify standards. Heck, there’s no need to document anything at all – just get real and build stuff.

Relevance: Rarely do experiences of any scale contain no reusable elements. However, some site areas – like an e-commerce checkout or an account management portal – may be unique, built once, and not duplicated again short of a redesign. Why standardize something that’s never reused?

Stability: Be careful not to standardize an experience too soon. A design system should stabilize before you invest in codifying layouts, grids, typography, patterns, and components.

Disparity: Instead of one simple set of grids, styles, and reusable chunks, you may have multiple, distinct design systems. Do you merge them into one library? If now, is it worth it to create distinct and potentially overlapping libraries?

4. Is Someone Ready to be a Librarian?

Just because you’ve built a website, that doesn’t automatically imply that you should build a library.

Building and sustaining a component library takes an evangelizing advocate. That person may be you, or someone you manage or work with. Almost always, the librarian wears many hats:

Leader: You’ll promote a new way of thinking, shepherding participants into common practice and evangelizing the techniques, benefits, and spirit of the library.

Target: You’ll be a lightning rod for the library, and even the cause of controversy in a design organization. Others may point to you as the standards police that constrains them from being creative.

Writer: You’ll be an author, or at least a contributor and reviewer of other’s contributions, for items like guidelines, library cheat sheets, and blog posts.

Teacher: You’ll teach principles and basic fundamentals about what’s where and how to use it. Help requests can be disruptive, and you’ll have to be patient, determined, and flexible.

5. Is Your Design Team Ready for a Library?

A library can transform how a team operates. Gone are the days where every project is a blank canvas where a designer creates a creative and original work of art. Instead, designers are equipped with helpful starting points as a framework in which to operate. Those constraints can be simultaneously welcome and controversial.

Above all, your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. Templates with grids, libraries, styles, and pre-made page chunks don’t turn designers into robotic automatons. But designers often react that way. You’ll have to convince designers that library starting points can focus creativity.

Other team attributes that influence library readiness include:

Size: How big is your design team? The larger the team, the more likely techniques, styles and deliverables vary. Libraries and templates can get your team synched up and communicating more consistently.

Overlap: How much do designs contain overlapping patterns and components? If your team is designing towards a common experience, a library can be a key part of a holistic strategy.

Distribution: Is your team spread out geographically? Standard design assets can mitigate impacts of reduced face-to-face collaboration.

Adaptability: Will your team be able to adapt to design practices that involve a library?

Stability: How stable is your team? Do designers come and go often? Learning library details is an investment with a return that increases the longer each designer uses it.

Advocacy: Do you have team members that are jazzed about or knowledgeable of reuse? Are they willing to be partners or champions?

6. Is Your Organization Ready for a Library?

Your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel.

You’ll need to have a pitch that explains the library in simple and concrete terms. What is it? How does it work? What does it mean to me? These questions hint at the profound impacts a library can have:

Workflow: Design libraries impact at least two critical workflows: how you produce a solution for each project and how you maintain assets, guidelines, and documentation across projects.

Collaboration: Do key team members – such as engineers and designers – have a common foundation to communicate on?

Documentation: You got to make it easy for people to refer to, find, learn, and integrate reusable assets into their own practices, whether via a component ID annotation on a wireframe, a PDF’s link to online documentation, or consistent HTML comments in your code.

Timing: When change is in the air, there may be opportunity to insert a library into the discussion and approach. Can you time the expansion of your library to dovetail with when your experience are already undergoing significant change?

7. Is Management Ready to Support a Library?

None of your planning and efforts will matter if you lack management support. They must vocalize a public belief in your effort as well as pony up time, money, and resources. It’s your duty to communicate a plan – and the return on that investment – to sell your management on why a library matters.

Unfortunately, even when the library is otherwise a good idea, management support sometimes wavers in instances like:

Lack of Priority: It can happen to the best of teams. You get your top talent together, you start roughing out a framework, and then projects hit. You get distracted. It’s up to management to carve out sufficient time for you, or else the library becomes stale and ineffective.

Insufficient Hardware and Software: It’s up to managers to ensure that designers have the right hardware and software installed so they can use the design assets. My confusion turned into empathy when I sat at a designer’s desk and watched for TEN MINUTES as the software tool launched on his out-of-date laptop. My query of “This is unacceptable. Haven’t you asked for an update?” was met with “You can only ask so many times” and a shrug.

Leadership and Evangelism: Ensure management is on message. Prep them with simple ways to communicate library value and help them avoid undermining you with explanations like “the library is another good idea, but if it doesn’t work for you, shouldn’t disrupt your own personal approach if you feel your way is more effective.”

Background Support: Public declarations are important, but so are the back-channel efforts. Your managers need to open doors to connect you with key players and partners. Knowing what doors to open is a two-way street, so help your managers understand the obstacles and why you need help.

8. So, Are You Really Ready to Build a Library?

Take a deep breath, because you’ve got a fun ride ahead.

So, your design system is stable, you’ve got some champions backing you up, and you know just what your organization needs. You are ready to put yourself on the line. You believe.

Then take a deep breath, because you’ve got a fun ride ahead.

Creating a UX library diagram
Diagram of How to Create a UX Design Library (PDF)

Up next, you’ll want craft a plan and read all you can from all the best authors and online resources. You then discover, organize, and prioritize what goes in your library. You’ll setup a platform for managing your catalog and publishing your standards. You may even equip one or more software tools with a library of reusable assets so that your team can create better design and deliverables, faster.

It’s time to build a library.

April 11 2010


IA Summit 10 - Dan Roam Keynote

IA Summit 2010

This year marks the 11th annual Information Architecture Summit. Our theme is meant to inspire everyone in the community—even those who aren’t presenting or volunteering—to bring their best ideas to the table.

As busy practitioners, we rarely have the chance to step back and think about the future of our field—we’re too busy resolving day-to-day issues. By gathering and sharing practical solutions for everyday challenges, we can create more breathing room to plan for what’s to come.

Subscribe to the Boxes and Arrows Podcast in iTunes or add this page to your account:

iTunes     2010 IA Summit theme music generously provided by Bumper Tunes

|Day 1 Keynote – Dan Roam | “Day 2 Keynote – Richard Saul Wurman”: |
Additional podcasts will be posted as available over the coming weeks.

Day 1 Keynote – Dan Roam

Dan Roam shares his unique visual-thinking approach that helps solve complex problems.

In his day one keynote from the 2010 IA Summit, Dan Roam—founder of Digital Roam Inc and author of the best-selling Back of the Napkin: Solving Problems and Selling Ideas with Pictures—shares his unique visual-thinking approach with a receptive crowd in Phoenix. Transcending language barriers, his approach helps solve complex problems through visual thinking, and has helped resolve challenges at many businesses: Microsoft, Wal-Mart, and eBay to name a few.

Note: As you might imagine, This presentation is VERY visual. As a result, the best way to view this presentation is to download it “with the visuals”: Roam.m4a or subscribe to the B&A “iTunes feed”:

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

These podcasts are sponsored by:

MAD*POW logo
At Mad*Pow, they leverage the disciplines of Human Factors, Psychology, and Visual Design to create engaging experience that maximize customer acquisition, increase attention, and reduce costs.

ASIS&T logo
The American Society of Information Science & Technology: Since 1937, ASIS&T has been THE society for information professionals leading the search for new and better theories, techniques, and technologies to improve access to information.

IA Summit 2010
The IA Summit: the premier gathering place for information architects and other user experience professionals.

The design behind the design
Boxes & Arrows: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there.

Transcript of Dan Roam Keynote from Day 1 of the 2010 IA Summit in Phoenix, Arizona.


Announcer: In this day one keynote address from the 2010 IA Summit, Dan Roam, founder of Digital Roam, Inc. and author of the best selling book, “Back of the Napkin: Solving Problems and Selling Ideas with Pictures,” shares his unique visual thinking approach. Transcending language barriers, his approach helps solve complex problems through visual thinking and has helped resolve challenges at many businesses including Microsoft, Wal Mart and eBay. I hope everyone enjoys the broadcast. Cheers.

Jennifer:  Our keynote speaker today, Dan Roam, has inspired a revolution in sketching. Sketching is a technique that allows our hand to help our brain think, making our technology more about humans, and taking back design and communication from machines. Going straight to the computer or the slide deck, locks in our thinking. We need to set our minds free. This is important for us because we have complex problems to solve in our work and we can do this with pictures. Please give Dan Roam a warm welcome.


Dan Roam: Thank you. Thank you, Jennifer. Thank you very much. Thank you all for coming. You know I always say that, I always thank everybody for coming, but the reality is, I want to thank all of you for inviting me to come and share some of my ideas with you. I wanted to start this morning, with a little bit of a story. About four years ago, as a matter of fact, I was checking in my calendar, four years ago, almost to the day, I was working as an IA and a user experience lead at a company out in San Francisco, at Razor Fish out in San Francisco, and one day I had just a horrible meeting with the sales team of the company. I don’t mean to point a finger at Razor Fish, it was a wonderful company, but I had a really horrible meeting. And I thought, “I’ve had enough of this. I’m going to go do something else. I’m going to go write that book that I’ve been thinking about for so long.”

But the fact is, you know, I’ve got a family, I’ve got two kids, I’ve just moved to San Francisco, things cost a lot of money, I have no idea how to write a book. So I thought, “Well, I’m going to call a couple of friends of mine, colleagues of mine who have written books and find out what it takes.” So I called a guy named Steve Krug, who wrote a book called, “Don’t Make Me Think,” I’m sure everybody’s familiar with “Don’t Make Me Think.” “Don’t Make Me Think” is without a doubt, the best book on web usability ever, but I also think it’s one of the best books ever just on thinking.

And I called Steve and I said, “So what do you do to write a book?” And he gave me a lot of advice, he told me about agents, publishers, proposals. A whole bunch of good insights. And then he said, “There’s this other guy that you should call who a few years ago co-wrote a book which is the book on information architecture.” He said, “You should call my colleague Lou Rosenfeld, because Lou will be able to give you a whole lot more information about what it takes to actually write a book.” So I had never spoken to Lou, I called him up and I said, “Lou, you know, I want to work on this book.” And Lou was full of all kinds of ideas again, about agents, good or bad, publishers, good or bad, how do you do it.

So the fact is, here we are now, four years later, and I went ahead and I did write that book and the book has been very successful. It’s been very exciting, “The Back of the Napkin,” has done really well, which is wonderful, but the reality of it is, the success of the book is largely due enormous credit back to Lou and the information architect community because this is where I come from.

So about three or four months ago, Lou sent me an email asking if I would be interested in giving a talk at the Information Architect Summit and I said, “Absolutely.” I mean, this to me is like one of the most perfect opportunities to share this idea because in a way, I spend a lot of time talking to organizations that I don’t know anything about. And it’s kind of a scary thing, and we’ll go through several examples of that, so it’s very nice to be able to come and talk to a group of people where I at least like to think that we share an essential base of information of where we come from and where we’re starting from.

And that is not often the case when, I’ll, let me put it this way. The best part about writing a book, I know there are probably a lot of people in here who have done books. How many people here have written books and had them published? I know there’s a lot of people I’ve been meeting. Well I want to give all of you an enormous hand [applause] because I know what’s involved. It is an extraordinarily difficult thing. Writing the book itself, in my opinion is no fun at all. Writing the book is you’re alone, and you’re in your room with your computer or your drawing or whatever, it’s a very lonely process. But the best part about it is after you’ve done the book, then you get invited to go give talks. And then you get to share your idea with all kinds of companies and organizations.

So over the last, three years now, I really have had this extraordinary opportunity to share these ideas with this really incredibly array of businesses and organizations. And as I was mentioning before, in most cases I’ll go in and I don’t know a whole lot about these companies when I show up. So one recent example, this was already two years ago. I am no aeronautical engineer, but I had to go, a chance to go and give a workshop at Boeing, up in Seattle. And it was phenomenal for me because what I ended up doing was being able to spend about half a day with the project managers that are building, that are behind the 787, the new dreamliner that just had its first flight a couple of months ago.

It was magnificent because they explained to me, how do you build what is arguably the most sophisticated, advanced, meticulous machine that has ever been conceived and the amazing part is that it’s being built simultaneously in something like 23 different countries at the same time. And in 16 different languages. How do you build something that is both that big, that new, is built down to tolerances of less than hundreds of thousandths of an inch in 16 different languages? Well the answer is very simple, you do everything with pictures. Everything is being done with pictures. And I thought, “That was really interesting.”

More recently, another organization, one that I know absolutely nothing about but I had a chance to go in and address was the United States Senate. So the Senate, the New Policy Committee of the United States Senate, about a year ago, gosh, it’s a little more than a year ago now, asked me to come out and give a similar workshop. And I don’t have a background in politics, I think, I’d like to think that I have a vague understanding of how Washington, DC works. I know there are a bunch of people here from Washington, DC and I think you’ll agree with me that nobody really knows how Washington, DC works. I came out of this after, it was a wonderful session, I learned a tremendous amount, I’ll admit at the end, I still have no idea of what the Senate really does, but again, the motivator there was: Is it possible to find ways to communicate issues about complex policy through this use of simple pictures?

And I think that the answer is yes. And I think many of the people in the Senate now think that the answer is yes, too. So in the end, what I wanted to share with you is that I have a very simple proposition that I make to all of these different businesses and organizations. And it goes like this. No matter how good everything may be in our lives, or in our work, there is something that we all do have in common which is that not everything is perfect. I mean we all do have some problems.

Well the proposition that I’d like to make is very simple, and it’s this: Whatever our problems are, we can solve our problems with pictures. I mean this completely, it’s a very simple statement but I know it to be absolutely true. We can solve our problems with pictures. Now the reason I can say that as superficial as that sounds, and say it with such incredible conviction because I know it is true is because I have never seen this process not work.

That is to say, every single time people are working together on something, on addressing some problem or challenge or trying to understand a concept, and someone starts drawing out what the other people are talking about, every single time it helps everybody get together on understanding what the problem is. And more often than not, by virtue of creating that simple picture, everybody starts to then see, not what the problem is anymore, but already begins to see what the solution is going to be. It’s already inherent in the picture that you’re creating. We’ll talk more about this in detail.

But I also recognize, and I’m willing to guess that with an audience like this, I’m just going to go out on a limb and guess that probably for most of you what I’m saying right now is not really a surprise or is probably not very new. I’m going to guess that in a room full of information architects, if my experience is the same as yours, we probably are the people who spend the greatest amount of time of just about anybody trying to understand what is the nature of this big problem that the client has brought to us and we do it more often than not by really drawing things out.

I’m not talking about drawing beautiful pictures. I’m talking about maps, schematics, concept models, mind maps. How do I get all these ideas together in a way where I can see them? But that is not the nature of the audiences, what I’ve just said, is not the nature of the audiences that I’m usually talking to. Project managers, financial executives, CEOs. I’ll say, “We can solve problems with pictures,” and they look at me cross‑eyed, they say, “What are you completely out of your mind?”

What they’ll often to say, if they think that through, the really clever people will say “Dan, OK, I’m going to play with you for a moment. Let’s assume you’re right. We can solve problems with pictures. Let’s break that down into three component questions. Which problems are we talking about? Which pictures are we talking about?” And then the third most contentious of all, “Which people are we talking about?” You know, namely, who is going to do this, “Because let’s face it, you know, I’m not visual.” I like those three questions, and in fact, those three questions are really going to be the underpinning of everything we’ll talk about for the next hour or so.

And I’m just going to run through them. Here’s the Cliff’s Notes, super fast, executive summary answer to all three of them. “Which problems are we talking about?” Any problem. Think about it like this: Any problem that we have the ability to articulate at all, we have the ability to articulate infinitely more clearly through the use of pictures, which brings us to question number two. So “Which pictures are we talking about?” I mean, if these pictures are going to help us solve any problems we can conceive of, they must be really sophisticated pictures, right? That must require at a minimum years of training, and probably some really sophisticated and expensive computer software to create, right? Well, you know where I’m going. The answer is absolute not. The pictures are bone-headedly simple.

Now, back to what I had said a little bit earlier. Everybody should be sitting on a napkin. If you’re not, look under your bum and see if you can find a napkin, there should be a napkin somewhere around there. What I’d like you to do, does everyone have, we asked this once before, is there anybody in here that doesn’t have a writing instrument? OK, volunteers. Lou? You don’t have a pen. That’s excellent. Yay for the information architects.


All right, if anybody doesn’t have a pen, we have volunteers who will happily give you a pen. What I’d like you to do for a warm up exercise, we’re going to really work out this napkin, we’re going to use it several times.

So, just, the pictures are if you can draw a square, and how many of you don’t know this, and you can draw a circle, and you can draw an arrow connecting them, and the most challenge of all, of course, I’d like everyone to try, draw a little stick figure. Make it a happy stick figure. If you can draw those things, you can draw every picture that we’re going to talk about, which automatically answers this third question. “Now, who’s going to do this, because I’m not visual.” Yes, you are. Everybody is going to be able to do this. Let me just throw out a couple of data points right from the beginning for anybody who might still be a holdout against this idea that pictures can help us solve problems.

Of all the neurons in our brain that are processing incoming sensory information, so that is to say the entire capacity that we have for understanding the world around us through all of our senses for bringing the information in. Let’s do it with a picture. This is our entire sensory capacity. What percent of that is visual? Three quarters of those neurons is focused on vision. It is arguable and there are neuroscientists who do argue this that it could be said that if you take all of the capacity of our brain to do anything, the one category of stuff that we have the greatest capacity to do of anything is to see.

More of our brain is dedicated to that than any other single thing that we do. Vision is fundamentally what we’re about. I mean, for people who might still be holding out and saying “Oh I’m not visual,” let’s keep the bar really low. If you’re visual enough to walk into the room and sit down without falling down, you’re visual enough, because the process of doing that, the extraordinary process of doing that already tells us how amazing this system is that we have. So there you have it. Any problem, simple pictures, everybody.

Now, one of the things that I have learned, and this was not, this is not in my original book. This is in the unfolding book, the second book that came out, because this was something I learned in giving this talk or talks like this many many times, is I’ve been looking, and people have been bringing to me these underlying reasons, these unwritten rules of why visual problem solving really does work. And I’m going to take you, I’ve identified four of them, and I want to take you through two of them today. They really kind of represent the understructure of what it is we’re talking about.

Unwritten visual problem solving rule number one says this: “Whoever best describes the problem is the person most likely to solve the problem.” So the idea is this. If one of us were to go running into the boss’s office and say, “Oh my god, the sky is falling ‑ give me money to fix it,” they’ll probably throw us out. But if we went into the room and we said, “Look. I’ve created this map and it identifies who’s involved in this particular problem, how many of them are there, where are these things involved or these things involved, how do they overlap, when do they intersect and how do they intersect.” All of a sudden, the solution to the problem is probably going to be already very clear. So the mercenary subtext to this rule is, and this is absolutely true, “Whoever draws the best picture gets the funding.”


Dan Roam: I’m going to give you a couple of scary examples of this being true. Before I do, I want to do a quick little usability test, because for later on this will be important. Is there anybody in particular in the back of the room who cannot read the slide? This is the smallest text we’re going to have on any slide and there will be some later on that we’ll need to read. So if anybody’s having trouble reading this slide, please move up to the front if you can. Even bring a chair. Because we will need you to be able to read at least that size, so a little quick usability test. Now I want to give you an example of this rule. “Whoever draws the best picture gets the funding,” and it goes far deeper than that.

I want to start by just taking a little trip from where we are here in Phoenix. I live out here in San Francisco, so I flew here yesterday. We’re going to fly out to Washington, DC, but before we do that, does anyone want to know, guess, can anyone imagine why I’m using a Southwest Airlines napkin as my route map? If you know, don’t tell us. Because the greatest back of the napkin business success story of all time took place in 1967 back in San Antonio, Texas. There’s some people here from Texas, yes? There’s a few people from Texas, yeah.

All right, well back in 1967, two guys are sitting in a bar. The St. Antony’s Club in San Antonio. And they’re talking about a business idea. And one of the guys ‑ and I swear this is true. His name is Roland. Roland takes his ‑ we don’t know what they were drinking, but we knew what he drew because they saved the napkin. He said, “Look, here’s Texas. We have Houston down here. We have Dallas up here. And we have San Antonio over here. Why don’t we make an airline that just connects those cities?” And then he drew the triangle of fate.

That’s the kind of picture I’m talking about. That back of a napkin sketch became the basis for Southwest Airlines. Southwest Airlines was started on the back of that napkin. Southwest has gone on to be the most profitable and financially successful airline in history. To this day, it is the most financially successful airline in history. And in fact, dozens of other airlines, from jetBlue to Easy Jet over in Europe to Ryanair have all copied the Southwest model, all of which began with this very simply picture on the back of the napkin. So that’s why I like to use this napkin.

Anyway, back to DC, I was asked as I mentioned before to come out to the US Senate and give a talk. So it was the new policy committee. And before going to give the talk, as I hope all of us would do, I went in and tried to do some research so I could say I have lots of examples from business and information architecture about the use of simple pictures helping solve problems. But I need to find something from politics. But I couldn’t really find anything. I was doing my research, but I found something else that was really interesting and I want to share it with you.

This is a map of Mt. Vernon. This map was drawn, the date’s right up there, in 1776. Mt. Vernon, of course, was George Washington’s estate. Does anyone want to guess who might have drawn this map? It was George Washington’s estate. George Washington drew the map. I didn’t know this. George Washington was trained as a map maker, a surveyor, and a cartographer. And in his notebooks, they’re full of his sketches. I thought: “That’s pretty interesting, let’s continue this line of thinking.”

So here’s another one. This is White House stationery, this is actually Oval Office stationery. Someone is drawing a picture of a boat. It looks like a chessboard with an eraser, a flag that says “NATO” on it, blockade Cuba in a circle. Does anyone want to guess who might have been drawing these pictures? This was JFK. That’s right, John F. Kennedy was drawing these pictures during the Cuban Missile Crisis. These are the doodles that were taken from this notebook as he was talking on the phone, trying to avoid nuclear Armageddon.

Here’s an interesting one. Anyone want to guess what President might have drawn this? And what could that fellow have been thinking? Nixon, absolutely. Very good.

This was Richard Nixon. There have been studies done, sort of forensic IQ tests going back in time, trying to decipher what would have been to unearth, what would have been the IQ of various Presidents. It turns out that Nixon is probably one of the smartest people from an IQ perspective who’s ever been in the White House. But clearly that guy had a lot of issues.


Dan Roam:  You’ve really got to wonder what does that picture represent? Well now here’s a nice easy one.


Dan Roam: Who might have been drawing these pictures? That’s right. This was President Regan and I swear that was taken when he was in one of his cabinet meetings. Those were the pictures that he was drawing at that particular cabinet meeting.


Dan Roam:  So I thought that was very interesting. Those were nice pictures, they’re kind of funny, they’re kind of interesting. After the talk, a guy named Doug Steiger, who’s the head of new policy for the Democratic side of the senate‑‑came up to me and said, “Dan, great talk. Thank you. But I’m going to tell you the best political back of the napkin story ever.” He told me the story and I have checked it out. It’s absolutely true. It involves a guy who is an economist back in the ‘70s named Arthur Laffer, who was with USC. But he was a consultant in Washingto,n DC in the ‘70s. So Laffer is sitting in a bar again, in DC, with two other guys from the administration, that time President Ford administration. Again, we don’t know what they were drinking but we do know what they were drawing. They got talking about taxation. Laffer on his napkin drew the following picture. It’s a simple X‑Y plot, same thing many of us have drawn thousands of times, I’m sure. On the horizontal axis he plotted out the percent tax rate that the US Government is going to charge us on our income from 0% up to 100%. On the vertical axis, he plotted out the amount of money that the government actually collects in taxation from lots and lots of money down to no money.

He said, “OK. So guys,” and it was all men at that time, they’re all sitting at the bar, the boy’s club. He says, “Think about this. If the government charges 0% income tax, how much money is the government going to make? 0%.” He said, “But think about this, if the government charges us 100% income tax, how much money is the government going to make? Also zero, because no one will work.” If we have to pay 100% of our income back as tax, what’s the point? I’m not going to work at all. So then he drew something which became known as the Laffer curve. He drew a curve and said, “In fact there is some curve that connects these and isn’t it interesting that at some point, reducing the rate of taxation actually increases the amount of money that the government collects.”

Now the guys who were with him at the table found this fascinating. “Take us through that again.” Reducing taxes increases government collections. Wow! They really liked that. “Can we take that napkin?” He said, “Absolutely.” These two guys took it back with them to their boss. They were both chiefs of staff of President Ford. They gave him that napkin. They said look at this idea. That napkin made its way into the hands of the Republican National committee and into the hands of the Regan economic team. That napkin became the basis of Reaganomics, of supply side economics. The idea particular being, reducing the rate of taxation in particular for the most wealthy increases activity in the market and increases the amount of money that the government actually collects.

That napkin sketch became the basis of Reaganomics. Regan, as much as I may make fun of him with his doodles, when someone would come to him and say, “Wait a minute. Tell me this again. You’re reducing taxes in order to increase revenue for the government? How does that work?” He would draw that picture, pretty convincing picture.

Now, the interesting thing is that these two guys who were sitting at the table with Arthur Laffer that night are these two guys.

Who says a simple sketch on the back of a napkin does not have extraordinary influence? It absolutely does. Whoever draws the picture gets the funding. Whoever draws the best explanation, of the idea is the one that people will believe. Why? Because it’s simple. I can understand it.

Now the Laffer curve, ever since has been debated endlessly. Where is the curve? Is the fundamental assumption correct? Doesn’t matter. He drew the picture. That’s the picture that wins.

Now, moving along, we are obviously in a new era. Who might have drawn this picture? Exactly right. President Obama drew this picture. Turns out, our President can draw extraordinarily well. It turns out also that our President is left handed. Now that by and of itself doesn’t mean anything. But we do know that there appears to be some correlation between people who are left‑handed and may be more spatial in their thinking.

Get this, I just did this math the other day. Five of the last seven US Presidents have been left handed. That is a really crazy number. Five of the last seven. Regan was a forced righty. He was naturally left handed. But through education, at that time was forced to become right handed. So Obama, Clinton, Papa Bush, Regan and Ford were all left handed Presidents. Pretty remarkable when you think about it.

So the question I have… Regardless of your feelings about our present administration might be, I think everybody can acknowledge, and I have said this, all over the country, everybody agrees that President Obama is one of the greatest public speakers that anybody’s ever seen. There’s no question that verbally, he’s one of the most articulate and passionate conveyers of information and thoughts we’ve ever had.

But the question I have is given the fact that he can draw, and draw extraordinarily well, why is it that he’s not drawing pictures to help explain some of the extraordinarily difficult problems that we’re facing? Whether it’s the economy, whether it’s global climate change, whether it’s Afghanistan. All of these challenges, and in particular I want to focus for a few moments on healthcare. This is not going to become a political conversation, I promise you.

Regardless of where you may fall on the political spectrum around your feelings of this healthcare so called debate that has taken place over the last year‑‑the intent from all people involved could not have been the anger and anxiety that we have seen exhibited in the last few months. By no stretch of the imagination could this have been the intent.

This horrible anger, that’s splitting the country around healthcare just doesn’t make any sense. I think the real problem, and I know this is true, the real problem is not so much accepting a lunatic fringe all over the place, accepting that the problem isn’t that people disagree with what’s being said in Washington. The problem is that people don’t understand what is being said in Washington.

We all know healthcare passed. How many people in here are confident that they understand what the new healthcare bill actually says? We’ve had this battle that’s become in some people’s mind, the virtual new civil war regarding healthcare. But nobody understands what the actual legislation is about. That is the fault of our elected officials. Why is President Obama not drawing a picture? We’ll talk this through in great detail.

Instead, I want to know what it is that DC is actually conveying to us in terms of their information. Talk about information architecture. This is the actual house bill passed back in October. The house healthcare bill. You can download all of these things online. I downloaded it. I said this represents this enormous shift in the way American government is handled that will impact all of us. This is an important piece of government documentation. Someone must have the vision. I use that word intentionally. The vision of what this healthcare reform is about. What does it actually look like? Why are we changing what we have now? Good or bad as it may be for something else. There must be a picture.

Well, I thought, “This is an important government document. So of course, nobody is going to put a picture, a sight map, a mind map on the fist page.” So I continued looking and no, there are no charts or diagrams or maps or vision documents, images anywhere in the first eight pages. Not in the first 64 pages.


Dan Roam:  Not in the first 200 pages. Nowhere in the 1,447 pages, there’s not a chart, there’s not a graph, there’s not a sight map. There’s not a single diagram that says this visually is what it means to shift from this particular model to this particular model. This is an unreadable document. Nobody can understand it.

Is it any wonder that [laughs] some people would claim we’re on the verge of civil war about this. Because nobody actually understands what’s in it. I thought, putting my money where my mouth is, what would happen if someone tried to draw some pictures of what this healthcare debate is actually about? Now, I thought, I’ll do it. Why not? I have worked with healthcare companies in the past as a consultant. I know just enough to be really dangerous but the good new is I have met healthcare consultants who know a lot.

So I called one of the best, one of the smartest consultants I’ve ever worked with, a guy named Tony Jones, that Jennifer, you would know, who is a health care consultant, he’s an MD and an MBA, pretty interesting fellow, pretty interesting mix. Tony’s office is down in LA. I said, “Tony, I’m flying down there. I’m bringing along copies of the legislation,” this is about seven months ago, now. “And we are going to lock ourselves in your office with the white boards and we are not leaving until we’ve created a set of simple pictures that explain what is the business of health care in America today, what is the actual legislation that’s being debated, not about killing grandma and death panels, but the actual legislation that’s being debated, and how does that map into how the model might change.”

And so we did that. And I’m not going to take you through the whole thing, but I want to show you a couple of pictures that I excerpted from that document.

One of them, was this picture, which kind of lays the base out and says the number one thing we all need to understand baseline is that health care in America, unlike any other developed economy on earth, remains a business. It is all a profit driven business, that is in our DNA and that is what people at the end are really arguing about is whether health care should be a business or should it not. It boils down to that. But the real issues is it’s not just one business, it’s two businesses that are completely distinct.

One of those businesses is the business of the providers. These are the doctors and the hospitals and the pharma companies. Businesses that make money by making people healthy. At the other end is the business of the payer. These are the insurance companies. These are the organizations who make their profit by handling the payment of all of the money through this system. These two businesses hate each other because as a tax paying employed citizen, I am the only source of money going into this system. There is no other money miraculously being created. As an employed, tax paying person, I am the only one putting money into the system.

The doctors, the providers want more of my money to be able to do good things with that money and to earn a profit, fair enough, that’s what we do, and the health care companies want more of my money to be able to do good things and earn a profit because that’s what we do. It is getting so bad that I am running out of money, my business is failing because there’s not enough money to provide both sides in this equation, so government decides it’s time to step in and help. And to do that through regulation. And as you look at all of the legislation that was being debated, ninety five percent of it did not focus, anywhere on the doctor, on the provider side of the equation. All of the reform was focused on the insurance side of the equation. We’re going to reform the insurance companies.

In hindsight, I believe had the White House called this not “Health reform,” but “Insurance reform,” it would have passed without anyone batting an eye in a few months because everybody hates their insurance company.

In the end you could take all of the legislation that was being debated and map it onto a very simple spectrum from completely private, not restrictive, unregulated, unlegislated, private insurance, which is what the conservative side really wanted, all the way through a purely government owned, national health service kind of a model, which is never what the White House wanted. The White House initially wanted to have a private insurance supported by a public option as well. And you could map all of the legislation across this spectrum.

Now what we’ve ended up with, what has just passed is something like this. Health insurance companies are no longer able to throw you out because of pre‑existing conditions, or because you hit a limit, so what’s happened is that some of the regulations have been taken, have been put on them but there is no government option. So in the end that’s what we’ve ended up with. It’s debatable whether that’s a good thing or a bad thing but at least something.

So the long story short, I don’t want to go any further than that, is to say, I created that presentation about health care, I posted it on SlideShare, you all know SlideShare, it’s gotten a quarter of a million downloads. Now, that’s nothing compared to Lady Gaga’s new video or something, but let’s face it, this, now get this, this is a PowerPoint document about health care. What could be more boring on earth?

Yet we’ve got a quarter of a million downloads of people. And the comments are saying, regardless of where they come in on the political spectrum and believe me the comments come in from all sides of the political spectrum, some of them are scary. They all say at least, “Thank you for having clarified through these simple pictures what the essentials of the health care debate are actually about. Now that we understand what we’re debating, now we can eviscerate each other. At least now we know why we’re trying to kill each other. Thank you for clarifying that, now we know why.”

So it got picked up by the Huffington Post and then the Washington Post and then I get a call from Fox News. Now I had been on Fox before and yes, it’s Fox, now, I live in San Francisco‑ I know there’s someone here, from looking through the list of attendees, there are at least two people here who are from the Fox network so I need to be careful what I say.

I think in San Francisco that we have this sort of electromagnetic pulse signal that we send out that blocks the Fox signal from coming into the city. I don’t think it works all the time, but I’ve got to admit, I love going on Fox because they’re the people who like the drawings. So Fox asked me to come on in a prime time, this is remarkable, they gave me seven minutes on prime time, 5:00 PM. Eastern Standard Time, on Fox Business Channel to explain with my pictures to the Fox audience the essentials of American health care. And I thought, “This is magnificent. How wonderful is that?” We had a good time and people understood it, I think.

So then I get a call. Does anyone know where this is? Yeah. So then I get a call from the White House Office of Communication saying, “Dan, we have to talk.” You know, so I went to the meeting and it didn’t actually take place in the White House, it took place in the coffee shop across the street. It’s all very, you know, sort of, “All the President’s Men,” cloak and dagger sort of stuff. Because it turns out that the White House cannot hire consultants.

Has anybody every worked with the White House? Anybody here who’s had experience working with the White House? It’s very difficult for the White House to hire consultants because of issues around transparency, we want to make sure that every contract is vetted appropriately and it’s very challenging.

So what’s been happening is, we have started some discussions on how it might be possible to use these kind of simple pictures to clarify policy, not so much with the White House but through, interestingly enough, some of the government departments. And the two departments that I was told and have been helped a little bit to get into that are the most open to this kind of innovative thinking are the Department of Defense and the Department of State.

So I’ve had a little bit of an opportunity to work with the Department of Defense and I’ve got to tell you, it’s fascinating. It’s really interesting. Because these are the people, when I talked about bigger problems, I mean, the problems that need to be addressed are in some ways a little bit beyond the scope of what I remember as a consultant typically would be the scope of a problem that a client would bring to me. And it’s pretty fascinating to be involved in that a little bit.

So the question becomes, you know, why is it, if we have all these Presidents who are not drawing who could, why might that be? And I’m not going to buy the answer that it’s because we’re not visual. We’ve already proven that President Obama is visual, we know that. We know everybody’s visual. So why is it that the communications that come out of Washington are so difficult to understand? I mean there’s probably a lot of reasons, but here’s one thing that I’ve come up with.

We’re going to do a test here, in a moment. I have found in something like, 450 meetings or something, that in doing the test that we’re about to do, it does turn out that pretty much everybody falls across a very simple spectrum in terms of how we approach problems from a visual perspective. What I’ve found, I’m going to give you the result first and then we’ll do the test and see how the test matches to the result. What I tell you now will have zero impact on how you actually take the test.

What I have found is that in any meeting, it doesn’t matter what the industry is, what the level of people’s position within the company is within the meeting, whether they’re executives or newbies, you find that in any meeting, typically about 25 percent of the people, you get this really nice bell curve distribution, about twenty five percent are what we’re going to call a “Black pen person.”

Now just to give you a little, very quick overview. A black pen person, we black pen people are the ones who can’t wait after the meeting’s started, we can’t wait to run up to the white board and start drawing out ideas. And say, “Wait a minute, is this what we’re talking about?” And we know who we are.

About 50 percent of the people are what I’m going to call a “Yellow pen person,” a highlighter. These are, we are the people, we yellow pen people, who are sitting there watching this other person drawing and we’re kind of inspired by what we’re seeing. Our mind starts moving thinking, “Oh, there’s something there,” and we, every single time, invariably, it’s always the same, we stand up and say, “I can’t draw, but,” and then we say, “Do you mind if I add something?” What happens is, that’s why I call these like the highlighters, the yellow pen people, are really good sussing out in someone else’s drawing the area that’s really interesting to explore, and then we’ll maybe create our own little picture over here of that area and say, “This, I think, is worth pursuing.”

Now we’ve got a great combination between the two, between the black and the yellow pen people of creating this picture that is both big picture and starting to get into some of the details.

Well, for those of you with a statistics background, you’ll notice [laughter] that we’re missing about 25 percent of our people, we red pen people. And we are the ones who are watching these other idiots up there at the white board thinking, “You know, frankly this is all a bunch of crap because they’re so grossly oversimplifying the problem, they’re probably making it worse.”

I don’t mean to point a finger because we all wear these different hats at different times, but we red pen people are the ones who really do have the greatest grasp of the details and the facts. It really bothers us. It’s just horrible to see these simple pictures being created that are missing so many of the nuances and the important critical details.

But what did we remember from before? The person who draws the picture wins. We’ve got to get these red pen people. We have to participate. So here’s what we’re going to do now. We’re going to do a test. On your napkins what I’d like you to do is follow along with me for a few minutes as we’re going to do a test.

What’s going to happen is I’m going to ask you a series of questions. Here’s why in that usability test I wanted to make sure that everybody was able to read the projector. If there’s anybody who can’t read that size of type, I’m going to need you to move up to the front. We’re going to go through a series of questions.

I will pose a scenario like this one that says, “I’m in a brainstorming session in a conference room that has a white board.” Then I’ll present you a series of possible answers. What I’d like you to do is read through the five possible answers, pick the one that’s closest to what you would do, and write down that number on your napkin.

My wife used to be an art director at “Cosmopolitan Magazine,” and I always like to think of this for anybody who’s ever read “Cosmopolitan Magazine.” This is like the “Cosmo Sex Quiz.”


Dan Roam: Here’s the scenario. Here’s what we’re going to do. So think about it like that only without the sex part.


Dan Roam: So again, Question #1. I’m in a brainstorming session. There’s a white board. Here’s what I do. And I’ll give you a minute or so for each one. Does anybody need any more time? Are we all good? We go on to the next one? Someone hands me a pen and asks me to sketch out a particular idea.



Dan Roam: I saw a gentleman yesterday who had this beautiful bandolier. Who’s the gentleman with like 46 markers? That thing’s amazing. I saw it from the elevator from the 10th floor coming down. It was beautiful. Is that bandolier here in the room? Can we show it? Whoever has that, would you mind showing us what you have?

Hmm? Not here?


Dan Roam: All right. Well, does anyone know who’s the guy who has it?

Jennifer: Jess McGraw.

Dan Roam: Jess?
Jennifer: Jess McGraw.

Dan Roam: Find Jess. Jess, are you here? Oh. You don’t have the bandolier with you?

Jennifer:  The pens.

Dan Roam: Your pens? Everybody, I want you to accost this man later on and take a look at this.


Dan Roam: All right. Are we getting through here? Anybody need more time? A couple more seconds? The next scenario. Someone hands me a complicated spreadsheet and asks me to look it over. OK. I’m going to press on. Just a couple more. Traveling home from a conference, perhaps even this conference, I’m in the airport. I run into someone who I saw at the conference and they say, “Oh, I forget. Your name? Yes, Mary. And what do you do again?” I…? Explaining what I do. Explaining what my job is now.


Dan Roam: And you know what? As of this morning we’re going to change question number three to now say, “I pull out my iPad.”


Dan Roam: All right. We have one more to go. Everybody good? This is an easy one because we’ve all been there. I’m an astronaut floating in space. The first thing I do is…? Keep your comments to yourself. For now. You know who I’m talking to. As you go through that, we’re going to total these up. We’re now done with our test. But before we do, and there’s someone in the room who already said it, so I want you to be very quiet. By a show of hands, how many people noticed something odd in the sequencing of those questions? Raise your hand if you did. OK, so a quarter of the room.

The person who shouted it out, what’s the problem with the sequencing of the questions? There is no Question E. There was no Question E. We went from D to F. Now the reason why that is is because I was asked to come and give a two day conference at Pfizer out in New York. This was a couple years ago now.

Day One I was going to talk to the business strategy people, and on Day Two I was going to talk to the project management people. And on the flight out, I was going through the presentation one more time. I was doing exactly what you’re not supposed to do: sit on the plane going through my PowerPoint.

I thought, “This is just too long.” So I just started pulling pages out. And one of the pages was one of these questions. But I didn’t think to renumber the sequence. So I pulled E, threw it away, and didn’t think to renumber it.

The first day again was with the business strategy people. We did the test. We blew through it. Nobody said anything. The next day was with the project management people. As we were going through it, when I jumped from D to F, everybody in the room said, “Wait! Where’s E?”


Dan Roam: And I thought, “This is more important than the test itself!” The business strategy people, none of them either noticed or cared that there was no E.


Dan Roam: And the project management people, we could not move on until we’d resolved [laughter] the issue of the missing E. I think that’s more telling. So here’s the deal. What I’d like you to do is add up your numbers, and we’re just going to do a quick show of hands. Add them all up. How many people identified themselves as a “Black pen person?” OK, we’ve got, oh, I’d say it’s about a fifth or a sixth of the room. Let’s call it five percent. How many people identified themselves as a “Yellow pen person?” OK, it’s a lot. Let’s go to the other end. How many people identified themselves as a “Red pen person?” OK, it’s roughly…wait! Those hands didn’t stay up very long. It’s OK to be a red pen person.


Dan Roam: I’m a red pen person half the time. You should see what the editor’s like. So I’d say that it’s less. It’s maybe 10 percent. But we still get a distribution, so we get something like this. It’s a little bit less. It’s a little bit bigger and then a little bit less like that. Now here’s the scary thing. Why is it that nobody in Washington, DC draws pictures? It goes back to our educational system. I gave this test. I have given this test, as I mentioned, hundreds of times now and the answer is always some kind of distribution as we’ve seen. Most people are in the middle, and then you get some spread out over the sides, with one exception.

It blew my mind, and I swear to God that this is true. I gave a talk to the NEA, the National Education Association. Teachers and academic administrators, 150 people in the room. Every single person, the same test you just did, identified themselves as a “Red pen person.”

Our educational system! And who knows what is the cause and effect here? Where is the finger to be pointed? We don’t know. But what we can derive from this is in this limited test, highly invalid, highly suspect, but nevertheless compelling.


Dan Roam: If our teachers and our academic administrators 100 percent believe that a picture is not a particularly valid way to convey an idea, and that is wildly off from the distribution of how we actually believe we should solve problems, no wonder we’re afraid to draw. No wonder from the age of six no one is encouraged to continue to use visual problem solving as a viable way to test intelligence. The SAT test includes critical reading, writing, and math. Your determination of whether you’ll get into your university has absolutely nothing to do with your ability to visually solve a problem, absolutely nothing to do. No wonder that by the time people ascend to the level of leadership, this is not going to happen.

And that is an enormous mistake because what it means is every time when we finally do get pictures in a business meeting, they all look like this. Why is it that given this broad range of visual talents and abilities that we have, when it comes time to communicating in a business setting this is what we always get?

In all fairness for those of us in the room, when it comes time to visual communicating, this is often what we generate. How many people have ever made a picture that maybe looks something like that? My beautiful site map that I labored over for weeks, and then I showed it to the client and they ran out of the room?


Dan Roam: Now I debated heavily whether I show you the next picture or not. I’m going to show it to you. This is a picture I don’t like. This happens to be the poster that all of us were given. I didn’t know that until last night. Who am I sitting with at dinner but Dave Gray, of X‑Plane who’s company made the poster. I’m thinking, “Oh God! I love this picture. I love to look at it. It’s beautiful and wonderful. It does absolutely nothing to me to explain how a website gets made which is what the picture’s about.” I think the type of pictures that I’m talking about, this is not what we want to be doing. Now, I ran, I told Dave I was going to show it anyway. He said that was OK. Is it still OK that I show it? OK.


Dan Roam: It’s beautiful, make no mistake. I have made pictures like this and I love doing them. But I’ve got to realize that it’s same with my beautiful sight map that I worked on for so many days. The intention, at the level I’m talking about, this is not every level but at the level that I’m talking about now, is to communicate ‑‑ to get what’s in my head into your head in the fastest, most efficient and most believable way possible. If I wanted to explain how a website got made, I would not do something like this. What I hope I would be able to do one day is to make something that’s very simple. So again, point being this simple picture on the back of a napkin. Now, for the rest of this session, we have about half an hour to go. I want you on your napkin to follow along with me as we figure out a way to draw a simple picture, a napkin picture of any problem that we can conceive of.

Here’s how we’re going to start. This is the way we start. Every back of the napkin problem solving picture, every single one, we don’t think about what our in‑goal’s going to be. No. Nor do we think about how would I even start. We remove that from the equation. We start always the same way. Just draw a circle. In the upper‑left hand corner draw a circle. This is the way I recommend starting every picture no matter what it’s about. Draw a circle and then give it a name.

In this particular case, call it “Me.” For a little extra credit, go ahead and make it look like me or you. Then we draw a second circle and make this one bigger and kind of fluffy down here in the middle. We’re going to label this one “My problem.” Now what’s happening is by virtue of our making these simple drawings on that napkin, and our being able to see them, a whole bunch of channels, neurobiologically speaking, in our brain are now opening up that would not have opened up if we just talked about it.

If I told you, “Imagine a relatively small circle at the upper left hand side of your page with a label ‘Me’ under it, and now imagine a bigger circle in the middle that’s called ‘My problem’,” an entirely different set of neurons are firing than are when we draw the picture. When we can actually see it and talk about it. We’ve now got all cylinders firing. What our brain really loves to do, and this is why PowerPoints so often do fail, our brain more than anything else gets excited when it understands something. The same kind of endorphins and dopamine that fire off when we get really excited are the same ones that fire off when we understand something.

When we suddenly have that “Oh my God, I get it!” moment, it’s like a shiver goes down the back of our spine. Our brain wants to understand. When someone gets up in front of us and starts to present something, we really want to get it. So our job as the communicator is to eliminate every thing from what we’re showing that’s going to stop the person from getting it. Because we want them to understand it.

So our brain is now ready by drawing these simple little pictures. We want to know what the connection between them is. Why is one bigger than the other one? What’s the next circle going to be? Our brain is already primed and ready to go and with our brain primed I want to stop and tell you a quick story. This is a story… The summary will be a picture that shows how all of this stuff works.

This is a story about two more business people. This is a guy named Ron Walton who is the son of Sam Walton and is the chairman of the world’s largest corporation, otherwise known as Wal Mart. This is Peter Seligman, who is the head of Conservation International, the world’s largest conservation organization. Now, by rights, these two guys should have nothing to do with each other. They should probably, according to our business beliefs, probably hate each other. Because one wants to consume and sell and the other wants to conserve. Well, the two of them are very good friends. The reason for that is because they both like to track outdoors with their family. They like to spend a lot of time traveling outdoors.

One time when they were on a trip, not planned, they happened to meet. This was up at the Northwest Passage. Both of them were on different expeditions that were looking at the ice pack and they met. They started traveling together because they hit it off. Peter Seligman started taking Rob Walton’s family to places where you could see, you could literally see, the impact that humanity has had on the planet in terms of climate change.

So one of the places again, that they continued to visit is Northwest Passage where for the first time in recorded history, the ice has broken up. You can now sail through it without having to stop, which you couldn’t do before, or though go down to the Amazon rain forest, which we talk about, we talk about deforestation. But they would go and look at it and they will see it. Of course, the intent here from Peter Seligman’s side was to motivate the Walton family to understand that there is a connection between human consumption and our impact on the planet, and to see it. Well, it worked.

Because after some of these trips, Mr. Walton said to Mr. Seligman, “OK. I get it. I want the Walton foundation… We’re going to give you 40 million dollars as a start to do whatever you want with at Conservation International.” Mr. Seligman said, “I don’t want your $40 million. I mean that would be lovely. But I’d like something else from you. I would like you a commitment from you that you will at least think about instilling within your organization to the degree that you can some sort of understanding of what environmental sustainability might mean.”

“You’ve got the world’s biggest company. You’ve got the world’s most complex supply chain.”

“You’ve got the world’s best ability to be efficient in delivering products to market. What would happen if you started to make every little step, somewhat more sustainable?”

Mr. Walton said, “OK. I’ll try it. But the guy we have to convince is Lee Scot.” He’s the CEO of Wal Mart or at least he was up until six months ago and he left on a good note. Because he was generally considered to be a pretty successful CEO. Let’s face it, in the end of the day, Lee Scot doesn’t answer to the environment, he answers to his share holders. If whatever he decides to do isn’t profitable for them, it’s not going to fly. So he’s the guy that we really need to convince.

So they did a test project, a pilot project, ‑where they said, “OK. What’s a product we can make that’s environmentally sustainable, that we can test to see if it’s profitable or not?” So they made organic cotton Yoga wear, believe it or not. That’s what Wal Mart decided to do. So they created a new line. They went out and they bought almost the entire organic cotton crop of Turkey which is the world’s largest provider of organic cotton. They made Yoga wear and sold out in three months at enormous profit. So they’re certain he’s convinced, from a business perspective‑‑being more environmentally aware actually could work.

Then in 2005, Katrina took place, wiping out New Orleans. As we all know, FEMA was not particularly agile on its feet in responding to that catastrophe, but Wal Mart was. Wal Mart was down there instantly, with hundreds and hundreds of truck loads of food and water that they were sending down and the way that, at least, Scot described it. I met him and he gave a talk. This is a couple of years ago. Now it was pretty inspiring. He said, “These are our people. If you look at the citizens of New Orleans, these are the life blood of an organization like Wal Mart. This is where we’re from, this is who we are. We are not going to let our own people go down.” So on their own, purely philanthropically, I believe that, they just sent materials, truck loads, food, water, building materials, you name it. They were the first responders to help people out in New Orleans until the federal government kind of got its act together.

What Lee Scot was saying at this talk is, “Why can’t we be the company that we were during Katrina? Why can’t we do that every day? And I don’t mean giving stuff away, but I mean being that thoughtful about what we do.” So he decided to go ahead and make Wal Mart become a flagship company for environmental sustainability. Depending on whether you like Wal Mart, you believe it. Or whether you don’t like Wal Mart, you think it’s all a bunch of crap. It’s a bunch of green washing.

Now let’s face it, there are two kinds of people on earth. There are people who love Wal Mart and there are people who hate Wal Mart. And they will never mix, and they will never change their mind. So what Wal Mart said is, “Look we’ve got to come up with a simple message to explain what environmental sustainability does actually mean from our perspective.”

They put out a tender to a bunch of PR companies and design organizations and what not. I had a friend at Wal Mart who handed me a copy of the RFP. The problem is all Wal Mart has is a tremendous amount of data. It’s not emotionally sexy, it doesn’t make any difference to you, we can’t understand it. So I said, “Why don’t we…,” in my response, “just create a set of pictures that make the data visual, so that we can understand it at a root level.” And among other things, “Why don’t we make a simple little model of the Wal Mart supply chain that actually shows how it all works and it’s too big to understand on a global basis. So let’s make an essentially like a little scale model. Like I would have made as a kid that just is a sliver of the entire supply chain. Then we can look at it in more detail and understand what would work.”

This was my proposal to them and I won the contract based on these little drawings. So in the end that’s what we did. We built this beautiful little 3D model that this is all of the aspects that make Wal Mart operate, from stores to transport to production to disposal and all of that. Then that model, you could break up into these different layers. Each layer represents a different aspect of environmental sustainability from carbon output to electricity consumption.

Then from those models you would be able to build visuals that people could understand. So instead of a big table of data that no one understands, this is how much CO2 is put up by Wal Mart around the world on a comparative basis. So you can suddenly see how much CO2 is put up in the United States versus how much is put out in Japan versus the UK.

But the point I wanted to make is that those were not the pictures. I love those. Those were a little bit like the X‑Plane pictures. In fact I was always inspired by X‑Plane, these beautiful little 3D models. But I realized in hindsight, those were not the pictures that mattered. The pictures that mattered were the pictures that we were drawing in the executive meetings. These extraordinarily simple little sketches, that said, “Wait a minute, if we break it up into these layers and each layer we can come up with some way of visually showing if this is how much we consume today, this is what we’ll consume tomorrow.”

This is the picture that actually made the difference because this is the picture that the decision maker’s really got. Which brings us to our second unwritten rule of visual problem solving. The more human your picture, the more human your response. Which really means we like to look at things that match the way our mind sees. I want to do a little test of this for a moment. Then I’ll run quickly through helping you figure out the rest of our napkin picture. Hopefully leaving enough time for a little bit of Q&A.

There are going to be four pictures that I’m going to show you. They’re all very simple. They’ll look very much like this one. I’d like you to look at this picture for a couple of moments and just see what you see. Now I’m going to move to the next picture. This is A. I now want to show you picture B. This is B. I’m going to move back and forth. This is not a test. I want people to really see what’s going on here. I want you to notice that some things have changed. I’m going back to A now. This is picture A and this is picture B.

Does everybody see that somethings have changed? How much time do you think might have passed from picture A to picture B? Is it a day? A few seconds? A few minutes, OK. Now I’m going to show you picture C.


Dan Roam: Something obviously has happened. Now I’m going to show you picture D. Something else has happened. How much time do you think might have passed between picture C and picture D? A few hours, OK. That’s all that we’re going to do for that little test. But as were through what just happened? A pretty amazing thing just happened. Look at how simple these pictures are. They’re nothing but some stick figures drawn in black. There’s no color. There’s no shading. There’s no drop shadows. There’s no 3D effects. There’s no color at all.

And yet, as extraordinarily simple as these pictures are, we just saw every major fundamental aspect of our visual processing system kick into action. It takes such an extraordinarily limited amount of information for us to activate every major processing center that we have. What I mean by that is as we learn more about the neurobiology of vision, we’re beginning to understand that vision is an extraordinarily complicated process, “Duh!” The more we understand about it, the more complicated it becomes. But there are a couple of things that we do know. Vision works as both a serial and a parallel process. That is to say the amount of information that is out there for us to process every second is overwhelming to our brain. We don’t have the capacity to process everything that’s out there.

So what our system has evolved is to be able to split up the entire work among a number of different work streams. So one of those work streams is called the “What pathway,” and this is the real name. It’s called the “What pathway.” Another work stream is called the “Where pathway.” Another one is called the “How pathway.”

One could make the argument, and I’ve had this argument with a handful of neurobiologists. They’ve all agreed that it’s fundamentally correct. One could make the argument that essentially the way we see the world is we break it up into six different work streams.

We process most of them independently and simultaneously. Then we stitch them back together in order to create the entire picture of the world that we see in front of us. There’s a reason why I’m telling you all of this. It’s something that I like to call the “6 by 6” rule. It tells us this, “To create a picture of any problem that we can conceive of we do not need to know how to draw hundreds of different kinds of pictures. We need to draw how to draw six.”

The rationale is if our vision system already breaks the world up into six different streams for processing, all we need to do to convey an idea is make one picture that taps into each one of those streams, shows that stream the information it needs to create the whole picture. Now we’re going to go through this on a napkin for the rest of our time.

I’m going to do this fast. We’ve got about 10 minutes more to go. Then I’ll leave time for some Q&A. So we’re out of here by 10:15. But back to our napkin now. What I’d like you to do is slice our problem up into six slices. Just like a pizza. We don’t have to think of our problem as one big scary thing that we can’t understand. We’re going to slice it up into six different slices exactly the way our visual system does and break it down into pieces.

The first one is the who and the what. This is what’s triggered by the what pathway. What the what pathway does is that it recognizes the things in front of us. It says, “Oh, that’s Dave. Oh, that’s a light. That’s a door.” Think about this as the nouns of our world. That’s what the what pathway does. It identifies the things that we see in front of us. The picture that we would draw to represent that slice is just a simple portrait. What I mean by that is, “Here’s a man. Here’s a woman. Here’s a car. Here’s a box.” Just a little simple portrait. The most basic thing that we need. Just enough information for us to understand what is the thing that we’re describing. That’s pathway number one.

Here’s an example. This is something called the “Wong Baker faces scale.” This is used in emergency rooms. This is developed by two doctors for use in places where there may be a language problem or people may not be verbal at all. The doctors trying to diagnose what’s wrong with this patient and they can’t communicate verbally. Well the doctor points to a part of the patient’s body and the patient points to… This very simple portrait conveys a tremendous amount of information. The simpler it is the more information it actually conveys. The more essential it is the faster we tap in to what is the difference between this and this.

Here’s a very simple little portrait. This represents a visual description of the second most important financial decision that most Americans will make. You’re wondering what I’m talking about? Well, am I going to buy an automatic or a manual? Very simple little picture. How’s that for manual?

Slice number two, the how much pathway. Doesn’t know what things are, it’s triggered by what things are because then it starts to count them, loves to count. We’re really good at counting. We’re really good at counting up to five. For most all of us, if we were to take and make little piles of things, pennies or marbles on the floor, and then look at them, the maximum number that most of us could look at and know how many it was without counting would be five. Our mind is really happy with that. Because once we get to six we have to stop and count. Our mind, remember it’s trying to process everything as fast as it can. It doesn’t like to stop and have to count it wants to just see it.

So what the how much pathway is doing is it’s trying to make guesstimates of quantity. That’s what it is doing. So the picture that we would draw if we want to reflect the how much statement, or how much is a chart, a visual representation of quantity. That’s what charts are for. So here’s a chart. This happens to show the price of tea in China.

Here is a little pie chart and yes I think pie charts are just fine. Dr. Tough Tea will have to argue that later. This is a little chart that shows the typical break down in a meeting, in a typical meeting, of how people go about solving problems visually.

The where pathway now. Slice number three. This one’s really cool. It has no idea of what anything is. But it knows where everything is. Completely distinct pathway separated by 30 million years of evolution from the part of our brain that identifies what an object is, the part that knows where it is. Has no idea what stuff is but it knows what its proximity to me is and it’s proximity to something else.

The image of what you can imagine this would look like, has anybody ever seen like a sonar scan picture or a radar scan? You don’t know what the objects are but you see shades of gray that indicate how far away they are? That’s kind of what our where pathway sees. Doesn’t know, doesn’t have a clue that that might be a person, that that might be Dave, but it knows there’s something 3‑ feet away from me, slightly below me, not moving towards me, “I probably don’t need to run.” That’s what our where pathway does.

The picture that we would draw to reflect a where problem is a simple little map. So say here’s my home, here’s the river and here’s where the treasure is buried. A simple little map that shows where things are located. A map can show where all the pieces fit, a map, of course, can show, we know this, talking, preaching to the choir here, a map can show where all the pieces fit within an organization or within a site map, we make maps all the time.

But think about what a map is doing, it’s doing one thing, it’s showing us where things are. A Venn Diagram? It’s just a map. It’s not showing a geographical region but it’s showing a conceptual region. Where do these ideas overlap?

When? Things now get really interesting, slice number four. We’ve come all the way around here. Now, the when pathway is pretty complicated because it’s keying off everything that’s come before. Dave, I’m going to single you out one more time. Would you do me a favor? Would you just stand up? This will be real easy for you. I’d like everybody to look at Dave Gray from “Explain,” thank you Dave, you’re doing a great job so far.


Dan Roam: Now, I’ve just identified what you are. Forgive me for calling you a “what” but that’s what my brain says. That’s “Dave,” we know that. Now our where pathway for all of us is also kicking in saying, “OK, Dave is that proximity away from me.” Now Dave, would you walk over here and then walk back and then sit down, that’s all you need to do. Now watch Dave as he does this. You may go back. Thank you. And sit down. Dave, thank you.


Dan Roam: Now what we just saw is a demonstration of our when pathway. Here’s what it does, it turns out that the number one way we recognize the passage of time is by what we see. Our what pathway said, “Dave,” our where pathway said, “There,” then a minute later, or at some other point it said, “Wait a minute, the what has moved, the where is different.” Now, is that a different what? Is that a different Dave? I don’t think so. The only thing my brain can deduce that happened is time must have passed, welcome to the fourth dimension. We see the fourth dimension all the time. We see time all the time. In fact, it turns out, if we go into a sensory deprivation tank, you know, we’d lose sense of everything right away, but if we just close our eyes and we’re in a quiet room, all of our senses impact us, but vision is the number one, one of the first things to go is our sense of time. If we don’t see what’s changing their where, we lose our sense of when. Does that make sense?

Pretty cool. So the picture that we would draw when we face a when problem is one we’re all familiar with, we just draw a timeline. When is one thing happening in relation to one other thing happening. Which one comes first? And which one comes after? I’m kind of a space geek, so here’s a nice picture of a where picture, you know, JFK says in 1961, “We’re going to the moon.” We’re going there. Pretty good vision statement. I mean everybody can see it every night, we know exactly where we’re going. If only health care were that simple. You know, we’re going there.

That’s wonderful as a where picture unless you happen to work for NASA, in which case the question becomes, “We’re going to do it before the end of the decade. We’re going to do it by 1969.” You say, “When? When are we going to do that?” Well, all of a sudden the project managers better start kicking in with their Microsoft project and their timelines and their Gantt charts. Because now we’re going to say, “When does everything need to happen in order for us to reach that particular deadline?”

So now we need a when picture. We need a timeline. And yes, there are lots of different kinds of timelines but they all show the same thing, when do things happen? We can look at that one for awhile. If you want to confuse people, put your timeline in a circle, I’ve all seen us do it, I’ve done it enough times myself. A sure way to get a client to just fade off is to create a circular timeline and then we review it, and then we iterate and then we review it and then we iterate.

We’re getting near to the end, because we’re just going to sneak in under our timeline, so this is perfect. Slice number four. Our brain is really working at this point. It’s combining everything we’ve seen up to this point to try to deduce cause and effect based on what we have seen. The whats in their various how muchs, in their wheres, are moving over when to allow us to start to deduce cause and effect.

What I mean by that is, what we’ll notice is, if dog sees birds, dog will run to birds. And if dog intersects with baby carriage, parents will panic. And that’s the picture that we saw in C. I don’t know how many of you noticed it, but I noticed this because I’ve done this before. Every single time I go for picture A to B to C, which is the one where the dog hits the baby carriage, everybody goes, “Oh.” We’re doing that from stick figures. We have an emotional response from stick figures. I mean holy smoke, what did we just trigger? Well, we triggered our cause and effect. We triggered the how.

Now a how picture, if the problem we want to describe is how does something work? We could summarize it by saying, “What will happen if I push this button?” What will I trigger if I push this button? What series of events? How will this flow? How will the system respond if I push this button?

The picture that we would draw, of course, is a little flow chart. This happens, which triggers this, which triggers this or if not, then that. A visual representation of how something works. And you’ll notice, with each one of these we’re getting increasingly complex in what we’re deducing and what we’re saying about the world.

The first three, all took place simultaneously. What it is, how much of it and where it is, are all happening at the same time. Then they get put together with when, over time and then we start to build this bigger picture.

Here’s a very simple little flow chart of how the human brain works. Sensory information comes in, goes into our reptilian brain, it gets processed and we act. We take certain behaviors based on what our senses have taken in. We humans, with our very sophisticated, fancy neocortex up on top are able to do a whole lot more fancy and sophisticated analysis and be able to execute a whole lot more sophisticated behaviors. Unless we’re talking about health care, in which case it goes like that.

The last slice, the why, combines all of the previous and this is when our intellect really starts to kick in and say from everything I’ve just seen in those little pictures, what rule can I derive? Why is the world the way it is? The picture that I would draw, is a very simple one, well in this case, what I’ve been able to deduce from those, that A, B, C, D picture of those stick figures is, I guess dogs really love birds but birds don’t love dogs.

I’ve been able to come up with a very simple visual equation that describes why the way the world is the way it is. So the picture that we would draw, there’s actually two, I’ll give you the simple one because we’re out of time. Had we had more time, I’m going to break that thing. The simple one is we draw an equation. What I mean by that is it’s the same thing as drawing our little picture of dog loves bird, bird does not love dog. The equation I like to draw is this. Very simple picture, square plus triangle equals circle. A very simple little visual equation that summarizes everything that we’ve seen up to this point.

Now I’m sure some of you are saying, “Dan, by what possible stretch of the imagination does square plus triangle equal circle?” Well, all of us know that triangle means delta which means change, so a square plus change gives me a circle, so there, you’ve got it.

We are now done. We’ve gone all the way around our little problem pie. If I don’t destroy my iPhone I’ll see that we’ve got about seven more minutes to go. There are two routes we could go now. We’re going to do this by a show of hands. I have a five minute story I could share with you to summarize all of this, or we could call it a day right now and use the rest of our time for Q&A.

How many people want to hear one more story and I just keep going on? And how many people want to do some Q&A instead? I’m going to share one more picture and I will go through this fast because let’s test the model, all six, with one big question, “Why does visual thinking matter?” Some of you have seen this before, so you’re going to have to go along for the ride one more time.

We’re going to go through all six slices, starting at the beginning, “what” all the way through “why” to try to understand why visual problem solving is so good for us.

What is visual thinking? Well, it’s a biological neuro-chemical vision science process by which we make sense of the world around us through our visual system. That’s what visual thinking is. Fine, enough of that.

How much visual thinking do we have? You already know the answer, because I told you.

If this is our total capacity to process incoming sensory information, let’s fill it in for vision, and you know when to tell me when to stop.

We’re seeing a lot of stuff. Boy, are we seeing a lot. We see a lot, more than we hear, and that’s where we’ll stop. Our entire processing capacity, that’s how much goes to vision.

How much do we use in a meeting?


Dan Roam: Blah, blah, blah, blah. “No, you’re wrong, sir!” Where did visual thinking begin? Now we’re on slice number three.

How many people know where visual thinking began? It began in France. I do not lie. Visual thinking began in France, at least as far as we can prove.

“What is he talking about?” Everybody’s heard of the caves of Lascaux. How many people have heard of the caves of Chauvet? Not so many people.

The caves of Chauvet are really cool. So what we’re going to do is zoom in to south central France, not far from the caves of Lascaux. If we continued zooming in, we would eventually come to this beautiful river that has cut out in the central mountainous region of southern France. If we continue down this river, we would come to this incredibly beautiful natural bridge which has been there for tens of thousands of years.

For hundred and hundreds of years, people have used this as a place for recreation. In fact, you can see there’s little kayaks down here. I don’t know if they’re scale, but this is pretty good. This is a kayak down here about that big. There’s another one here. People swim here at the beach. For thousands of years, people have been going to this place, and they think it’s beautiful. And it is.

But in 1993, very recently for the first time, a spelunker named Monsieur Chauvet discovered the entrance to a cave hidden on the back side of that arch. And he started with his team to explore that cave, and they were eventually able to map out in an incredibly complex series of caves that as they did their carbon dating, were far older than the Lascaux.

What they were able to find in there are a series of unbelievably beautiful pictures that people had been drawing.

And this is just one wall, this is one part of the wall. These four horses here, I don’t even want to draw on top of them, they’re so beautiful. These four horses were drawn over a period of about 800 years. People kept coming back to this cave for 800 years, drawing similar pictures… Those four horses…

To this day I defy anyone to draw a better picture of a burro than that.

Here’s something interesting. We’ve got a rhino. Who in southern France would have seen a rhino? Pretty wild. I mean, these bulls are incredible.

So when did this begin? How old are these pictures? I’ll give you a meaningless number, since we’re good at five.

32,000 years ago is when those pictures were drawn. And as I say, it appears from carbon dating that people continued to go back beginning 32,000 years ago for the next 800 years to the same cave and draw throughout all of those walls these unbelievably beautiful pictures.

Now, we know that human life actually began in Africa, and we have been able to find shards of things, but in terms of actual human markings that are clearly an intentional human marking, the oldest that we’ve been able to find are these at the cave of Chauvet 32,000 years ago. These are are the oldest representations we have of humans making markings.

Now I thought, 32,000 years… Again, it’s a meaningless number. I really wanted to understand how long ago that is, so I thought, let’s look at time in a different way. Let’s not think about it in terms of years. Let’s think about it in something that we humans understand. Let’s think about it in terms of generations.

So I made a little chart, which is my all time absolute favorite picture that I’ve ever drawn.

Let’s say each little character represents one generation. And let’s just say that on average, a generation from one mother to one child throughout all of human time has been roughly 25 years.

I mean, we can debate it may have been 15, 20, whatever. But let’s say roughly 25 years. So instead of talking about years, let’s talk about generations, because that’s something we can all imagine.

For myself back to my mother to grandmother to my great grandmother, and I wanted to map out how many generations have there been in 32,000 years. Very few. This takes us back to Columbus. 1492. That many generations. That many grandmas and grandpas. That’s it. All the way back to the time of Columbus.

I could draw it in one line. I could count it on two hands. Holy smoke. That’s not a long time ago at all.

Let’s go back a little bit further. Let’s go back 2,000 years to the beginning of the numbering system of years that we have now, to the time of Jesus Christ. That’s how many grandmas and grandpas there have been.

This was breathtaking to me. I always thought history was long. I thought 2,000 years was a long time. It ain’t nothing. That’s how many generations have been since the time of Christ.

Now let’s continue all the way back 5,000 years to the beginning of recorded history.

So here we’ve got Caesar here, five generations before Jesus Christ. Socrates here. We’ve got Muhammad up here. We’ve got the Buddha, the original Gautama Buddha right here. We’ve got Nefertiti, representing the height of the Egyptian empires here. We’ve got Abraham back here. We’ve got the beginning of recorded history, 3,000 B.C. That is it.

You know, it’s amazing to me. You’ll watch “Star Wars,” and they’ll talk about the Jedi Knights have ruled the universe for thousands of generations. No. There are no thousands of generations. That’s how many generations have existed since the beginning of recorded history. It’s 200. I can count that. That’s it.

I don’t know how you feel. I start crying when I look at this. History is so short. The only reason I was able to get that is because I drew it in a picture. I swear I’m going to start crying.

So then I thought, OK, but I want to go back 32,000 years. That takes us 5,000 years back. Let’s go back 32,000 years. How many grandmas and grandpas have their been and their babies since 32,000 years, since the first time that anybody we’ve found made a mark on a wall, drew a picture.

By the way, this is the beginning of, of course, as best as we can find, spoken written language. Takes us back.

So if I compressed everything in this picture into one line, that’s how long it would take us back.

Now let’s keep going. This takes us back 16,500 years back to the caves of Lascaux. Here’s when Lascaux was, and if we complete the whole picture, that’s how far we go back to Chauvet.

Every one of those little dots represents one grandma to one mother to one daughter, all the way through. I was just blown away. That’s it. We really got to get our health care figured out. We’ve got to take care of this planet. It’s not very long that we’ve had it.

Anyway, how did it begin? We’ve only got two more questions to go.

Well, evolutionarily speaking, we first had a reptilian brain stem that was able to process a little bit of fundamental visual information. That’s where much of our “where” pathway is. Crocodiles are really good at knowing where stuff is. They have no clue what anything is, but they know where it is.

Then we’ve got this limbic brain on top of that that allows us to have emotional responses to what it is that we were seeing, and make maybe more emotional decisions about how we would react.

And then we got this fancy old neocortex on top that allows us to do really sophisticated visual processing.

Our last question now. Why did visual thinking begin? So we wouldn’t get eaten.
And my last question for all of you is, why does visual thinking still exist?


Dan Roam: So we won’t be eaten.


Dan Roam:  Oh boy, we are right at the end of time. Thank you so much. I really appreciate you staying through the whole thing.




March 31 2010


Case study of agile and UCD working together

Large scale websites require groups of specialists to design and develop a product that will be a commercial success. To develop a completely new site requires several teams to collaborate and this can be difficult. Particularly as different teams may be working with different methods.

This case study shows how the ComputerWeekly user experience team integrated with an agile development group. It’s important to note the methods we used do not guarantee getting the job done. People make or break any project. Finding and retaining good people is the most important ingredient for success.

The brief

In 2008, we were tasked with resurrecting a tired, old, and ineffective site. It was badly out of date, and the information architecture was decrepit to both users and search engines.

The old

Our goals were:

  1. Make content visible and easy to find
  2. Create an enjoyable and valuable user experience so users would return
  3. Increase page impressions to bring in ad revenue
  4. Allow site staff to present more rich media content
  5. Give the site more personality and interactivity

The UX team created personas from ethnographic studies, online surveys, and in-depth interviews with users. The data gave us a clear idea of the user’s needs and wants. We also gleaned data from analytics that told us where users engaged and where the bounce rates were highest.

At this point the development team maintained the site with an agile process. They created features for the new site in parallel to ongoing site maintenance, but this work was outside the normal maintenance sprints. The new site was considered as an entirely new project with a separate budget and scheduled into longer term.

Boundary Spanner

As the User Experience team gathered data key team members were recruited. The diagram below shows the key team members needed to produce this large scale site, their specific concerns, and their methodologies.

Boundary Spanner

To bring these teams and disparate elements together requires a launch manager or ‘boundary spanner’. Rizal Sebastian wrote about boundary spanners in Design Issues in 20051. The boundary spanner needs to be aware of the individual issues the project faces. He need not know the detail but needs to know the cultural context of the collaborative environment.

Do people get on with each other? Are communication lines clear? Are there any personality clashes on the team. To throw developers, interface designers, business analysts, SEO experts, and usability guys together and expect them all to gel is optimistic but unlikely. It also requires those people devote all their time to just one project and that is unrealistic for a large operation where several projects are underway simultaneously.

They are more than a project manager because the user— and not the project—is at the heart of their concerns. He is responsible for delivering and continually developing a quality product. He is not just monitoring the features on a checklist. The user is at the center of all decisions on the design and development of the site. This is the only way you can ensure the user will be heard throughout product development – to employ somebody who listens to user voices and never forgets what they said. They must also ensure that SEO and business requirements are satisfied, and a well-defined strategy is in place. The boundary spanner owns and clearly communicates the vision until the whole team understands.

The boundary spanner’s strength is that they are core to the product and not a department or team known for their skillset (like a UX team for example). In many cases it is a product manager, but in this case it was the website editor who was responsible for synchronizing the teams.

Defining a process

To assist this user focused approach, the IAs produced set of deliverables that ensured the launch manager’s vision could be realized and developed.

Defining a process

Diagramming the process using a concept model engaged key stakeholders with the project by communicating the vision of what the UX team would achieve with the speed and clarity of an elevator pitch.

Information gathering

A content audit revealed broken links, redundant content, and poor usability plagued the site. It also revealed how much content became lost the second it moved from the home page. The high value research papers were impossible to find.

30 interviews, 20 ethnographic studies, and 950 responses to an online survey. created six personas. With the content audit, personas, and business objectives (what we wanted them to do on our site), we began creating the taxonomy.


During this project we were very fortunate to work alongside the web analytics manager who provided insight into user behavior, including high bounce rates from visitors arriving from search engines. He also provided a scorecard that showed where the site failed in terms of traffic and user engagement. We knew what users were searching for, and pretty quickly could tell why they were not finding content we knew we had.

Analytics screen showing overlay on the new website

By looking at web metrics we were understood usage patterns and popular and unpopular areas of the site. The depth of information enabled us to quickly formulate a plan.

Persona driven taxonomy

As we knew our user base were industry experts, we also knew their vocabulary was related to specific areas of their markets.

The taxonomy was created by gathering as many industry sources (websites, journals, white papers), breaking these down into unique elements, and clustering these elements together to form categories for our content.

The interface used to manage the CW taxonomy

The CW taxonomy formed the basis of the navigation, content categorization, and highlighted areas for future development. It also ensured our search results served up related content in context.

Search results displayed contextual related content

We defined four main areas by looking at the community of users.

ComputerWeekly Concept

News was an obvious requirement, defined by their particular area of interest within the sector. The need for knowledge was evident, and we created an in-depth research area where case studies and white papers could be easily accessed. Tools and services, RSS, email news alerts, and newsletters reflected user needs to be kept up to date and in tune with their specialization.

Finally, although the CW community was secretive and did not divulge information amongst their peers, they were very interested in expert opinions. This need gave rise to much more integrated blog postings.

Interface development

The navigation scheme defined the elements of the page the users would use to move to other areas in the site. It clarified the naming of those items on the page.


We then considered the prioritization of information and content for each page, and this facilitated the production of wireframes that represented the culmination of all research, showed the interface and interactions for elements on the page, and were a working document that changed as we iterated the design.

Core and Paths

We used Are Halland’s method for ‘designing findability inside out.’2

  • Prioritize and design the core – Satisfy user goals using prioritized content and functionality.
  • Design inward paths to the core – Consider how users will arrive at the page from search engine results, facets, menus, search, RSS, aggregation, email, etc.
  • Offer relevant outward paths from the core – Ensure that the site delivers both user and business goals through clear calls to action and completion of interaction tasks.

For, we focused on the cores for the home page, a channel level homepage, and a news article page and looked at key content such as lead news story and the editor’s picks or the best from the web aggregated from external sources. The key functionality and supporting content also had to be included and prioritized on the page.

Next we considered the inward paths, which are the channels that our users are likely to utilize to arrive at the page.

Inward paths

Inward paths included search engines, blogs, bookmarks, syndication, aggregators, RSS, and email subscriptions. Considering inward paths helped us focus on the marketing channels we needed to drive users to the relevant type of page. It also focused on the keywords and themes that users are likely to use and helped us optimize pages for search and online marketing campaigns.

Finally we designed the outward paths that helped users complete online tasks for our business objectives.

Outward paths

These outward paths include:

  • Newsletter sign-up
  • Inline links to related articles to drive page consumption
  • Sharing, printing or emailing of news articles
  • Related content types such as video or audio
  • Stimulating community participation in forums or blogs
  • Contextual navigation to aggregated content or the editors best bets
  • Subscription to an RSS feed
  • Prioritizing the content

Prioritizing the Content

Once the wireframes had been approved, the content was organized so the most commercially valuable and user focused content was pushed to the top of the page. As the design went through user testing, certain elements changed, as with any iterative process, but through team collaboration, the solution remained true to the initial vision from concept to design delivery.

The development cycle

The wireframes were handed over to creative, and they began designing the interface and graphic elements. The development group released some functional elements to the old website before the relaunch.


These agile methods allowed the old site to feel the benefits of the new widgets. However, as the site changed so radically in the new design, we still had to release the site in an old style ‘big-bang’ manner. This is perhaps where agile has its problems as a methodology for new launches. It’s focus on many small releases is a great tool to implement incremental changes but not for a completely new site.

As the html flat pages were passed to the team, the SEO requirements were defined and built into the site. By the time the site launched it, had been through four major pieces of testing.

Development Timeline

A holistic solution

Providing user experience deliverables like the concept map and wireframes ensured more comprehensive requirements were delivered to the design and development team. This approach addressed marketing, editorial, sales, and business requirements next to the needs and wants of the user. The vision was aligned with an achievable delivery from the IT team that ensured we delivered the site we wanted to give the user.

The new

The core IA work enabled the new site to be future-focused and versatile. The structure and design of good sites should be able to adapt to change.

User-centered design and agile can work alongside each other but what is more important is having people who can tie all the loose strands of a website design and development cycle together. The concept map, wireframes and the IA strategy document that listed the rationale behind the design decisions helped ensure the product vision was correctly communicated to the development team, so the product that was developed through their agile processes was in line with the overall product vision.

1 cookieSet=1&journalCode=desi


February 01 2010


Bringing User Centered Design to the Agile Environment

When the exciting opportunity to work in a post-bubble startup arose, I jumped to take it. I had the luxury of doing things exactly as I thought right, and for a while it was truly fantastic. I built a team with a dedicated user researcher; information architect; interaction and visual designers and we even made a guerilla usability lab and had regular test sessions.

Unfortunately, the enthusiasm I had for my new job waned after six months when an executive was appointed Head of Product Development—who insisted he knew SCRUM1 better than anybody. As the Creative Director, I deferred authority to him to develop the product as he saw fit. I had worked with SCRUM before, done training with Ken Schwaber (author1 and co-founder of the Agile Alliance) and knew a few things from experience about how to achieve some success integrating a design team within SCRUM. This required the design team to work a “Sprint” (month long iteration) ahead of the development team. But the new executive insisted that SCRUM had to be done by-the-book. Which meant, all activities had to be included within the same sprint, including design.

Requirements came from the imagination of the Head of Product Development; design was rushed and ill-conceived as a result of time pressure; development was equally rushed and hacked together, or worse, unfinished. The end of Sprint debriefing meetings reliably consisted of a dressing down of the entire team by the executives (since nobody had delivered what they’d committed to i.e. they had tried to do too much, or had not done enough). Each Sprint consisted of trying to fix the mess from the Sprint before or brushing it under the carpet and developing something unstable atop the code-garbage. Morale languished, the product stank, good staff began to leave… it was horrible.

This is an extreme example of where SCRUM went bad. I am not anti-Agile although I’ve been bitten a few times and feel trepidation when I hear someone singing its praises without having much experience with it. Over the last eight years, I’ve seen Agile badly implemented far more often than well (and yes, it can be done well, too). The result of this is mediocre product released in as much time as it would have taken a good team to release great product using a waterfall approach. In this article, I will describe Agile and attempt to illuminate a potential minefield for those who are swept up in the fervor of this development trend and want to jump in headlong. Then I will present how practices within User Centred Design (UCD) can mitigate the inherent risks of Agile and how these may be integrated within Agile development approaches.

Where did Agile come from?

Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. At the end of each step, we have something built that we could release to the market if we choose to and therefore it can assure some speed to market where waterfall methods usually fail. Agile prefers to work out how to build something as we go, rather than do a waterfall style deep dive into specification and then finding out we can’t build parts of the spec for some reason e.g. a misjudgment of feasibility, misjudgment of time to build, or changing requirements.

A group of developers such as Kent Beck, Martin Fowler and Ken Schwaber got together to come up with a way to synthesize what they had discovered was the most effective ways to develop software – The Agile Alliance was born. It released a manifesto2 to describe its tenets and how it differs from waterfall methods.

Agile can be thought of as a risk-management strategy. Often developers are approached directly by a client who does not know what a user experience designer, information architect or user interface designer is. Roles such as these usually interpret what clients want and translate it to some kind of specification for developers. Without this role, it’s down to the developer to work out and build what the customer wants. Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want. As such, it is a coping mechanism for a client’s shifting requirements during development as they begin to articulate what they want. To quote the Agile Manifesto’s principles “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Why do people rave about it?

At the heart of what makes Agile attractive is the possibility of quicker return on investment for development effort, because we can release software earlier than we would have otherwise. In the short term, this is typically borne out. In the long term it can be too, though only when the team hasn’t fallen victim to temptation (more on that later).  Agile is also good at generating momentum because the iterations act as a drumbeat to which the team marches toward manageable deadlines. The regular "push" to finish a sprint ensures that things move along swiftly. Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.

Because it emphasizes face to face contact for a multidisciplinary team, Agile tends to encourage contribution from different perspectives. This is generally a positive influence on, pragmatism, innovation and speed of issue resolution. The team is empowered to make decisions as to how requirements should best be met.

The Minefield

In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.

Mine 1: An unclear role for design

In the best cases of business approaching developers to build some software, some of those developers may have design skills. But that’s not a particularly common scenario. Many developers have also had bad experiences with designers who don’t know what they’re doing. It took a long time for the design profession to come to grips with designing for complex systems and there is still a deficit of expertise in this field. “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?

Mine 2: The requirements gathering process is not defined

Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.

According to Ken Schwaber, SCRUM intends to be a holistic management methodology and leaves space for activities other than programming to occur within the framework of iterative cycles. But when organizations adopt SCRUM, too often the good parts of a waterfall process like research and forming a high-level blueprint for the overall design become the proverbial baby thrown out with the documentation bathwater. As the Agile Manifesto says, “Working software over comprehensive documentation.”2 Many latch onto this and don’t want to do any type of documentation that might outline a vision, even if in a rudimentary sense.

Mine 3: Pressure to cut corners

Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision. This can and does lead to impulsive design. So, what’s wrong with that? Well, nothing if you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.

Some assert that there are plenty of examples of best-practice interfaces to copy out there. So, why reinvent the wheel? Surely we can save time that way? Sometimes they’re right, but how will we know which best-practice interface works best in context with the user’s goals, with no time to test with the user? How can we innovate by copying what already exists? Before Google reinvented internet search, other search engines assumed a status quo which behooved the user to learn how to form proper search queries. It was institutional knowledge among the other search engines that this is how searching was done and customers simply had to learn to use it. Most people’s search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what they’re looking for, not learn how to drive a search engine first. I’m not suggesting the other search engines could not have done what Google did sooner, but I am pointing the finger at a mentality which meant they missed the opportunity. Interestingly, Google is not known for its designers. It’s mainly a development house, but lots of those developers can clearly put a design hat on too.

There is absolutely nothing wrong with using Agile to produce results quickly; that is, if you don’t intend to release them on your poor, unsuspecting user without some usability testing. Just don’t be fooled that this is going to save you a lot of time if you want your new product to be right, because you will have to iterate to arrive at an appropriate solution. Alan Cooper has argued that this creates a kind of ‘scar tissue’ where code that has to be changed or modified leaves a ‘scar’ that makes the foundations of the program unsound.4

Mine 4: The temptation to call it “good enough”

Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can. Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that we’ve already got a version of? Or shall we develop something new instead? Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.

Typical Agile Development

Mine 5: Insufficient risk-free conceptual exploration time

Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. An argument used by some Agile practitioners asserts that a working example of a solution is the best way to validate whether it is the right one through exposure to the market. This ‘suck it and see’ approach bypasses an activity called “concepting.” Concept activities dedicate time to sketching different solutions at a high level and validating them in the rough with users before digging into detailed design or code. “Suck it and see” would have us just build it, launch it and see if it flies. This way, we’ve wasted time building something we will probably have to take apart or rebuild. The counter argument is: if it took as long to build as it would have to research and design before laying a line of code, then we break even. This statement is a stretch in practice because development itself usually does take longer than well-managed design research and conceptual exploration. Also, there has to be some level of design regardless  of which methodology is used, and this adds days to the timeline.

Mine 6: Brand Damage

Let’s just say that design and research takes the same amount of time as development for argument’s sake. In the worst case, we completely miss the mark with the non-researched and designed solution and we have to start all over again. Then we’re back to the same total duration after developing it a second time, but there’s no guarantee we’ll get the solution right the second time either. All the while we’ve repeatedly foisted a botched product design on our users and adversely affected our brand. Many companies succeed on the back of their reputation for producing consistently appropriate products and services. When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make. Software creators that fall victim to the temptation of "good enough" and fail to innovate through conceptual exploration put their companies revenues at risk. In a competitive market, repeated failure to meet user needs well leads to serious brand and subsequently financial repercussions, as other companies who do get it right take the business.

Agile is good for refining, not defining.

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

User Centered Design

UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.

Uncovering requirements to form a strategy

User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements. When we practice UCD end-to-end, we pretend we know little. Little about what the solution to a problem should be; little about what the problem actually is because assumptions close us off to new possibilities. We prefer to allow some design research to create a viewpoint and then form a hypothesis as to what we might build. In this regard, we cross into the realm of product managers, producers, program managers, business analysts and the like, trampling toes with gay abandon and meeting resistance all around. Facing confinement to defining the boring old business need (distinct from the user or customer need), these folks would prefer we constrain our UCD work to usability testing on designs meeting the requirements they set out. They’d prefer we stick to just helping with development… and if we can do that quicker using Agile? Wahey!

Typical UCD Waterfall

Is it always appropriate to do extensive research before starting design? That’s a good question and one that Jared Spool’s Market Maturity Framework5 helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet user’s needs with it is all we can afford to do. Once we graduate out of this "Raw Iron" stage into "Checklist Battles" focused on getting the right features and then beyond, research is a core ingredient to putting our feet in the right place.

After researching what the user and business requires, we can make the “Strategy” tier of Jesse James Garret’s Elements of User Experience3which underpins everything we do during the project. Do this well, and you really shouldn’t come up with something that’s fundamentally wrong. Agile doesn’t account for this beyond a planning phase (i.e. iteration zero), which may well define a strategy of sorts. But does it really define the correct strategy? Surely, that’s created through careful consideration of three things:

  1. Empathetic qualitative research that uncovers the user’s context, needs, goals and attitudes i.e. user requirements. Cooper suggests that the customer doesn’t know what they want and advocates a role of interaction designer as requirements planner.4 This would avert building to the wrong requirements in the first place, but the time to do this must come into the development lifecycle somewhere. It involves talking to users, preferably visiting with them in their environments to create experience models and user personas.
  2. A thorough appreciation of what else in the big wide world exists in terms of products, features and technology that can be emulated somehow (not necessarily addressing a similar situation to ours).
  3. A clear articulation of the business problem, objectives, success measures and constraints. Business people sat in a room discussing what they think should be done must be informed by all these things if the right strategy is to emerge. Agile doesn’t preclude that kind of consideration, but it does not mandate it either.

JJG's Element of UE

Concept Development

If we manage to built something usable and reasonably intuitive without research or strategy, did we succeed? Most MP3 players fit this bill but none took off like the Apple iPod. Leaving interface usability aside, the iPod had a service concept behind it which included digitizing, replenishing and managing your entire music library with iTunes. This was part of the iPod concept from the outset and in combination with good marketing and design, continues to eclipse the competition over seven years later. But that concept needed to be sketched and iterated at some point. If we don’t explicitly build this into our Agile methodology, we can miss that thinking time.

Holistic Design Concept

The best of both worlds

UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go. 

Best of Both Worlds

A shared vision of the interaction fundamentals

In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. This produces something rudimentary to test with users to see if we got the big picture right. Following this roadmap sketched on the back of research and concepting prior to development activity, ensures consistency and cohesiveness when each component is coded separately to each other later. In many cases, the concept will need iterating to accommodate lessons from the journey. But we’ll at least have some indication of direction at a macro scale. Then, when in the midst of Agile iterations working out the details alongside our developer brethren, a level of expertise and experience is required of the designer because what we design will be built before we’ve had a chance to second-guess ourselves. Domain knowledge and an understanding of interface paradigms that work is also a big help. But to build new projects from scratch without a shared vision is a mistake.

Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort. Sometimes most of the product will be done this way and that’s fine so long as developers and designers are still working together and talking every day. The first development iterations are an important time for the developers to lay the architectural foundations based on the vision. Designers should use this time to get a jump on any high-priority tricky interfaces so the development team isn’t waiting for something meaty to start on when it comes time to build features.

Most important to success, the business needs to accept that some things won’t be right the first time around and commit to iterating them prior to release i.e. not be led into the temptation to release something that’s not right yet.


In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.

1. Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle

2. Manifesto for Agile Software Development

3. The Elements of User Experience by Jesse James Garrett

4. Extreme Programming Vs. Interaction Design. Interview with Kent Beck and Alan Cooper

5. The Market Maturity Framework is Still Important – Jared Spool

December 23 2009


5 Steps to Building Social Experiences

Nowadays everyone wants social in their sites and applications. It’s become a basic requirement in consumer web software and is slowly infiltrating the enterprise as well. So what’s a designer to do when confronted with the requirements to “add social”? Designing social interfaces is more than just slapping on Twitter-like or Facebook-like features onto your site. Not all features are created equal and sometimes a little bit can go a long way. It’s important to consider your audience, your product—what your users will be rallying around and why they would want to become engaged with it and each other, and that you can approach this in a systematic way, a little bit at a time.

These concepts derive from a book I wrote recently with Christian Crumlish, “Designing Social Interfaces”: They are quick and easy things to remember when infusing social into your site. Each points offers some simple suggestions and points to consider when designing. Potential design patterns are recommended (and linked to) as examples for what could be done in your interface as you design and grow your service. Keep in mind that your context will dictate different specific solutions but the questions and concepts to think about will still be applicable.

Step 1 – What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?

Most people are drawn to a site based on their particular interests, in hopes of learning more or meeting others like themselves. They may be looking for information or they may have information to share. They have a passion—such as making handcrafted jewelry or taking landscape photographs—and at some point, they will want to share that with other people. That passion, that thing that people rally around is often referred to as the social object. It’s the object around which conversations emerge and thrive.

Remember that sometimes, the social object is a person – or the conversations between people. But don’t forget history (remember Friendster? or SixDegrees?), if the only thing to do is build a profile, people will eventually go somewhere else to have conversations or to do things around objects of interest.

Step 2 – Give people a way to identify themselves and to be identified.

This can be as simple as an “attribution”: line when contributing and signing content.

Attribution of a comment on flickr
Attribution of a comment on flickr

It could be an “identity card”: that shows a little bit about the person and is attached to every thing they do or can be as robust and complex as a “full profile”: that is linked from all their contributions. The method can start out simple and grow over time.

Identity or Contact card as seen on FriendFeed
Identity or Contact card as seen on FriendFeed

It’s important to give people credit for their words and contributions. It helps others recognize their friends and disambiguate them from other people with the same name and builds a “reputation of quality”: or lack thereof for their participation on your service.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing.

Public display of relationships allows viewers to find others they might know by allowing them to browse contacts for the person whose info they are viewing. Module shown from MyBlogLog
Relationship module shown from MyBlogLog

Once you have given people the ability to identify themselves, allow them to “find each other”: and claim their tribe. “Relationships”: make the world go round and online it’s no different.

Step 3 – Give people something to do.

Provide a path for participation so lurkers as well as early adopters can be engaged at the level of effort that is appropriate for them. Things like ratings (“1-5”: or “thumbs up”: are easy ways to get low participation people involved by letting them quickly register their opinion with little effort.

Thumbs up and down ratings for restaurants on GoodRec let people quickly register their opinion with little effort
Thumbs up and down ratings for restaurants on GoodRec

Allow them to “share items”: they find interesting with their friends or family and “curate and collect their favorites”: The latter requires a little bit more effort, but lets your users have ownership over what they find meaningful.

Flickr allows users to
Flickr allows users to “favorite” images they like and collect them for display to others.

At the other end of the spectrum is full authorship of content with “reviews”:, “comments”:, “blog postings”:, and “wiki entries”: all the way through to participation as a moderator or guide in your service.

Wikimedia allows collaborative editing of content on sites built with the software.
Wikimedia allows collaborative editing of content on sites built with the software.

Start simple, with light features, and gradually add more complexity if it is really needed. Keep the structure flexible enough for your users to mold and adapt to their needs. In the book, we discuss several principles related to this including “Deliberately Leave Things Incomplete”:, which reminds designers to allow features to emerge from the community behavior rather than forcing behavior to fit the UI and “Strict vs. Fluid Taxonomies”: which merges a strict taxonomy like your site navigation with user generated groupings and organization with features like Groups, Message Boards, Tagging, etc.

Allowing behavior to guide your features and giving your users ownership of the structure make the site much more personal for them which in turn encourages repeat and longer term usage.

Step 4 – Enable a bridge to real life (groups, mobile, meetings, face-to-face).

Don’t be afraid to build in tools that allow your users to bring their community into the real world. In many online groups, a majority of people know each other personally.

Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.
Upcoming shows local events and allows people to add events to their calendar and view events their friends are interested in.

Providing tools to help plan face-to-face meetings and then archive those happenings will strengthen your site and the community. Consider incorporating “geo” features like “GeoMapping”:, and “GeoMashups”:

Additional features might entail creating “subspaces (groups)”: and coordinating real time “face-to-face meetings”: and gatherings among users of your service.

Meetup lets people affiliate with groups of interest and the site helps coordinate real life - in person meetings and gatherings between members.
Meetup lets people affiliate with groups of interest and the site helps coordinate real life – in person meetings and gatherings between members.

Step 5 – Gently Moderate. Let the community elevate people and content they value.

This can be through simple things like ratings or “reputation labels”:

Reputation labels on the intranet at Yahoo!.
Reputation labels on the intranet at Yahoo!

The community can help you surface contributions of quality which in turn should help attract future participants and will help keep the interactions lively. This process also helps push bad quality content down and out of sight.

Keep an eye on the community, participate yourself, welcome people as they join, set yourself up as a role model.

Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.
Hunch founder, Catarina Fake, acts as a role model for the community being built on the site.

Notice who is passionate and who is potentially causing trouble. Conversations should run their course. Let the “community moderate itself”: and provide tools to allow them to do that, like allowing them to mark content as spam or block trolls or “report abuse”: Step in only when necessary.

Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.
Report Abuse is available on every comment in Yahoo! Answers and allows users to moderate the content quality.

Make sure people are aware of the “terms of service”: and “license”: implications of content they create – both as it relates to your site as well as what they can permit others to do with their content.

Go out and get started

These are a few of the things to consider when building a social application or when adding social features to an existing site. There are a lot more features and concepts available within the social ecosystem but these should get you started and will build a good foundation from which more robust and complex features can be added to.

It is important to remember that you don’t have to do it all at once. You can apply features sparingly and let the community tell you when you need to expand. Consider the bare minimum while fleshing out your infrastructure. Add complexity as your community grows and scales. Remember that you are building a container for activity and conversation and that you don’t have to have everything figured out. The people will create their own paths of interaction making their own meaning and experience.

December 05 2009


Tree Testing

A big part of information architecture is organisation – creating the structure of a site. For most sites – particularly large ones – this means creating a hierarchical “tree” of topics.

But to date, the IA community hasn’t found an effective, simple technique (or tool) to test site structures. The most common method used—closed card sorting—is neither widespread nor particularly suited to this task.

Some years ago, Donna Spencer pioneered a simple paper-based technique to test trees of topics. Recent refinements to that method, some made possible by online experimentation, have now made “tree testing” more effective and agile.

How it all began

Some time ago, we were working on an information-architecture project for a large government client here in New Zealand. It was a classic IA situation – their current site’s structure (the hierarchical “tree” of topics) was a mess, they knew they had outgrown it, and they wanted to start fresh.

We jumped in and did some research, including card-sorting exercises with various user groups. We’ve always found card sorts (in person or online) to be a great way to generate ideas for a new IA.

Brainstorming sessions followed, and we worked with the client to come up with several possible new site trees. But were they better than the old one? And which new one was best? After a certain amount of debate, it became clear that debate wasn’t the way to decide. We needed some real data – data from users. And, like all projects, we needed it quickly.

What kind of data? At this early stage, we weren’t concerned with visual design or navigation methods; we just wanted to test organisation – specifically, findability and labeling. We wanted to know: * Could users successfully find particular items in the tree? * Could they find those items directly, without having to backtrack? * Could they choose between topics quickly, without having to think too much (the Krug Test)1? * Overall, which parts of the tree worked well, and which fell down?

Not only did we want to test each proposed tree, we wanted to test them against each other, so we could pick the best ideas from each.

And finally, we needed to test the proposed trees against the existing tree. After all, we hadn’t just contracted to deliver a different IA – we had promised a better IA, and we needed a quantifiable way to prove it.

The problem

This, then, was our IA challenge: * getting objective data on the relative effectiveness of several tree structures * getting it done quickly, without having to build the actual site first.

As mentioned earlier, we had already used open card sorting to generate ideas for the new site structure. We had done in-person sorts (to get some of the “why” behind our users’ mental models) as well as online sorts (to get a larger sample from a wider range of users).

But while open card sorting is a good “detective” technique, it doesn’t yield the final site structure – it just provides clues and ideas. And it certainly doesn’t help in evaluating structures.

For that, information architects have traditionally turned to closed card sorting, where the user is provided with predefined category “buckets” and ask to sort a pile of content cards into those buckets. The thinking goes that if there is general agreement about which cards go in which buckets, then the buckets (the categories) should perform well in the delivered IA.

The problem here is that, while closed card sorting mimics how users may file a particular item of content (e.g. where they might store a new document in a document-management system), it doesn’t necessarily model how users find information in a site. They don’t start with a document—they start with a task, just as they do in a usability test.

What we wanted was a technique that more closely simulates how users browse sites when looking for something specific. Yes, closed card sorting was better than nothing, but it just didn’t feel like the right approach.
Other information architects have grappled with this same problem. We know some who wait until they are far enough along in the wireframing process that they can include some IA testing in the first rounds of usability testing. That piggybacking saves effort, but it also means that we don’t get to evaluate the IA until later in the design process, which means more risk.

We know others who have thrown together quick-and-dirty HTML with a proposed site structure and placeholder content. This lets them run early usability tests that focus on how easily participants can find various sublevels of the site. While that gets results sooner, it also means creating a throw-away set of pages and running an extra round of user testing.

With these needs in mind, we looked for a new technique – one that could: * Test topic trees for effective organisation * Provide a way to compare alternative trees * Be set up and run with minimal time and effort * Give clear results that could be acted on quickly

The technique—tree testing

Luckily, the technique we were looking for already existed. Even luckier was that we got to hear about it firsthand from its inventor, Donna Spencer, the well-regarded information architect out of Australia2, and author of the recently released book “Card Sorting”:

During an IA course that Donna was teaching, she was asked how she tested the site structures she created for clients. She mentioned closed card sorting, but like us, she wasn’t satisfied with it.

She then went on to describe a technique she called “card-based classification”:, which she had used on some of her IA projects. Basically, it involved modeling the site structure on index cards, then giving participants a “find-it” task and asking them to navigate through the index cards until they found what they were looking for.

To test a shopping site, for example, she might give them a task like “Your 9-year-old son asks for a new belt with a cowboy buckle”. She would then show them an index card with the top-level categories of the site:

She would then show them an index card with the top-level categories of the site.

The participant would choose a topic from that card, leading to another index card with the subtopics under that topic.

 The participant would choose a topic from that card, leading to another index card with the subtopics under that topic.

The participant would continue choosing topics, moving down the tree, until they found their answer. If they didn’t find a topic that satisfied them, they could backtrack (go back up one or more levels). If they still couldn’t find what they were looking for, they could give up and move on to the next task.
During the task, the moderator would record: * the path taken through the tree (using the reference numbers on the cards) * whether the participant found the correct topic * where the participant hesitated or backtracked

By choosing a small number of representative tasks to try on participants, Donna found that she could quickly determine which parts of the tree performed well and which were letting the side down. And she could do this without building the site itself – all that was needed was a textual structure, some tasks, and a bunch of index cards.
Donna was careful to point out that this technique only tests the top-down organisation of a site and the labeling of its topics. It does not try to include other factors that affect findability, such as: * the visual design and layout of the site * other navigation routes (e.g. cross links) * search

While it’s true that this technique does not measure everything that determines a site’s ease of browsing, that can also be a strength. By isolating the site structure – by removing other variables at this early stage of design – we can more clearly see how the tree itself performs, and revise until we have a solid structure. We can then move on in the design process with confidence. It’s like unit-testing a site’s organisation and labeling. Or as my colleague Sam Ng says, “Think of it as analytics for a website you haven’t built yet.”

So we built Treejack

As we started experimenting with “card-based classification” on paper, it became clear that, while the technique was simple, it was tedious to create the cards on paper, recruit participants, record the results manually, and enter the data into a spreadsheet for analysis. The steps were easy enough, but they were time eaters.

It didn’t take too much to imagine all this turned into a web app – both for the information architect running the study and the participant browsing the tree. Card sorting had gone online with good results, so why not card-based classification?
Ah yes, that was the other thing that needed work – the name. During the paper exercises, it got called “tree testing”, and because that seemed to stick with participants and clients, it stuck with us. And it sure is a lot easier to type.
To create a good web app, we knew we had to be absolutely clear about what it was supposed to do. For online tree testing, we aimed for something that was: * Quick for an information architect to learn and get going on * Simple for participants to do the test * Able to handle a large sample of users * Able to present clear results

We created a rudimentary application as a proof of concept, running a few client pilots to see how well tree testing worked online. After working with the results in Excel, it became very clear which parts of the trees were failing users, and how they were failing. The technique worked.

However, it also became obvious that a wall of spreadsheet data did not qualify as “clear results”. So when we sat down to design the next version of the tool – the version that information architects could use to run their own tree tests – reworking the results was our number-one priority.

Participating in an online tree test

So, what does online tree testing look like? Let’s look at what a participant sees.

Suppose we’ve emailed an invitation to a list of possible participants. (We recommend at least 30 to get reasonable results – more is good, especially if you have different types of users.) Clicking a link in that email takes them to the Treejack site, where they’re welcomed and instructed in what to do.

Once they start the test, they’ll see a task to perform. The tree is presented as a simple list of top-level topics:
In Treejack, the tree is presented as a simple list of top-level topics.

They click down the tree one topic at a time. Each click shows them the next level of the tree:
In Treejack, each click shows them the next level of the tree.

Once they click to the end of a branch, they have 3 choices: * Choose the current topic as their answer (“I’d find it here”). * Go back up the tree and try a different path (by clicking a higher-level topic). * Give up on this task and move to the next one (“Skip this task”).

In Treejack, the participant selects an answer.

Once they’ve finished all the tasks, they’re done – that’s it. For a typical test of 10 tasks on a medium-sized tree, most participants take 5-10 minutes. As a bonus, we’ve found that participants usually find tree tests less taxing than card sorts, so we get lower drop-out rates.

Creating a tree test

The heart of a tree test is…um…the tree, modeled as a list of text topics.

One lesson that we learned early was to build the tree based on the content of the site, not simply its page structure. Any implicit in-page content should be turned into explicit topics in the tree, so that participants can “see” and select those topics.

Also, because we want to measure the effectiveness of the site’s topic structure, we typically omit “helper” topics such as Search, Site Map, Help, and yes, Contact Us. If we leave them in, it makes it too easy for users to choose them as alternatives to browsing the tree.

Devising tasks

We test the tree by getting participants to look for specific things – to perform “find it” tasks. Just as in a usability test, a good task is clear, specific, and representative of the tasks that actual users will do on the real site.
How many tasks? You might think that more is better, but we’ve found a sizable learning effect in tree tests. After a participant has browsed through the tree several times looking for various items, they start to remember where things are, and that can skew later tasks. For that reason, we recommend about 10 tasks per test, presented in a random sequence.

Finally, for each task, we select the correct answers – 1 or more tree topics that satisfy that task.

The results

So we’ve run a tree test. How did the tree fare?
At a high level, we look at: * Success – % of participants who found the correct answer. This is the single most important metric, and is weighted highest in the overall score. * Speed – how fast participants clicked through the tree. In general, confident choices are made quickly (i.e. a high Speed score), while hesitation suggests that the topics are either not clear enough or not distinguishable enough. * Directness – how directly participants made it to the answer. Ideally, they reach their destination without wandering or backtracking.

For each task, we see a percentage score on each of these measures, along with an aggregate score (out of 10):
Showing Treejack results with a percentage score of each measure and an aggregate score.

If we see an overall score of 8/10 for the entire test, we’ve earned ourselves a beer. Often, though, we’ll find ourselves looking at a 5 or 6, and realise that there’s more work to be done.

The good news is that our miserable overall score of 5/10 is often some 8’s and 9’s brought down by a few 2’s and 3’s. This is where tree testing really shines—separating the good parts of the tree from the bad, so we can spend our time and effort fixing the latter.

To do more detailed analysis on the low scores, we can download the data as a spreadsheet, showing destinations for each task, first clicks, full click paths, and so on.

In general, we’ve found that tree-testing results are much easier to analyse than card-sorting results. The high-level results pinpoint where the problems are, and the detailed results usually make the reason plain. In cases where a result has us scratching our heads, we do a few in-person tree tests, prompting the participant to think aloud and asking them about the reasons behind their choices.

Lessons learned

We’ve run several tree tests now for large clients, and we’re very pleased with the technique. Along the way, we’ve learned a few things too:

* Test a few different alternatives. Because tree tests are quick to do, we can take several proposed structures and test them against each other. This is a quick way of resolving opinion-based debates over which is better. For the government web project we discussed earlier, one proposed structure had much lower success rates than the others, so we were able to discard it without regrets or doubts.

* Test new against old. Remember how we promised that government agency that we would deliver a better IA, not just a different one? Tree testing proved to be a great way to demonstrate this. In our baseline test, the original structure notched a 31% success rate. Using the same tasks, the new structure scored 67% – a solid quantitative improvement.

* Do iterations. Everyone talks about developing designs iteratively, but schedules and budgets often quash that ideal. Tree testing, on the other hand, has proved quick enough that we’ve been able to do two or three revision cycles for a given tree, using each set of results to progressively tweak and improve it.

* Identify critical areas to test, and tailor your tasks to exercise them. Normally we try to cover all parts of the tree with our tasks. If, however, there are certain sections that are especially critical, it’s a good idea to run more tasks that involve those sections. That can reveal subtleties that you may have missed with a “vanilla” test. For example, in another study we did, the client was considering renaming an important top-level section, but was worried that the new term (while more accurate) was less clear. Tree testing showed both terms to be equally effective, so the client was free to choose based on other criteria.

* Crack the toughest nuts with “live” testing. Online tree tests suffer from the same basic limitation as most other online studies – they give us loads of useful data, but not always the “why” behind it. Moderated testing (either in person or by remote session) can fill in this gap when it occurs.


Tree testing has given us the IA method we were after – a quick, clear, quantitative way to test site structures. Like user testing, it shows us (and our clients) where we need to focus our efforts, and injects some user-based data into our IA design process. The simplicity of the technique lets us do variations and iterations until we get a really good result.

Tree testing also makes our clients happy. They quickly “get” the concept, the high-level results are easy for them to understand, and they love having data to show their management and to measure their progress against.

You can sign up for a free Treejack 2 account at “Optimal Workshop”:


1. “Don’t Make Me Think”:, Steve Krug
2. Full disclosure: As noted in his “bio”:, O’Brien works for Optimal Sort.


Sketchy Wireframes


When it comes to user interface documentation, wireframes have long been the tool of choice. However, using traditional diagramming tools like Visio, OmniGraffle, and InDesign, most wireframes today look the same as their ancestors did from a decade ago – assembled with rigid, computer-drawn boxes, lines and text. While these artifacts have served us well, they can also be slow to produce, burdened with unnecessary detail and give a false impression of “completion.”

To compensate for the drawbacks of traditional wireframes, many practitioners put aside the computer in favor of simple pencil sketches or whiteboard drawings. This speeds up the ideation process, but doesn’t always produce presentable or maintainable documentation.

There is a growing popularity toward something in the middle: Computer-based sketchy wireframes. These allow computer wireframes to look more like quick, hand-drawn sketches while retaining the reusability and polish that we expect from digital artifacts.

The same wireframe in sketchy and traditional representation.
Caption: The same wireframe in sketchy and traditional representation.

The Traditional Wireframe Problem

Throughout a project lifecycle, wireframes can be used for different purposes depending on the stage. In the early stage, wireframes act as a tool for exploration and concept development, when sweeping changes are expected and encouraged. As the project continues, parts of the wireframe begin to be “locked down” as functionality is reviewed and “signed-off.” During this process, wireframes can become a confusing hybrid of conceptual ideas and finalized functionality. By the end of the process, wireframes can turn into a highly detailed functional specifications document.

The problem here is that traditional computer wireframing tools, like Visio, OmniGraffle or InDesign, lay out drawings as hard-lined boxes, lines and fonts. As a result, wireframes look the same regardless of which stage of completion the wireframe is representing. Early-stage, conceptual wireframes look identical to late-stage, functional specifications. This differentiation becomes especially murky in the middle of the project, where conceptual and final elements are comingled on the same page.

Sketching to the rescue?

To compensate for the drawbacks of traditional wireframing, some designers ditch the computer in favor of hand sketching. An informal poll by (as of 8/24/09) showed 22% of respondents identifying sketching as their primary tool for wireframing. Hand-sketching of wireframes, proponents argue, allows for faster expression of ideas and freedom from artificial confines of diagramming software. Sketches don’t require the same level of detail, and can be produced faster than traditional computer-based wireframes, allowing for a more iterative design process.

Why not sketch…

If hand-sketching has so many advantages over computer-based tools, why don’t we all ditch our mouse pads for sketch pads? There are four major reasons:

  • Drawing ability – Wireframes are essentially presentation tools, and not everyone may feel that their drawing skills are “presentable.” In team environments, there can be a wide range of drawing skill levels… from the “can’t draw a straight line” people to the “can’t put down their sketchbook” people. This leaves a disparity in the quality of sketched deliverables produced by the team. Many organizations feel it’s best to standardize their deliverables by forcing everyone to use the same tool.

  • Perception – When people become accustomed to seeing fully fleshed-out wireframes, introducing sketchy may be a challenge. Some may see the architect as suddenly becoming “sloppy” or “lazy.” In these cases, it is critical to sell the benefits of sketchy wireframes to stakeholders and opinion leaders.

  • In situations where wireframes are intended to live past the initial concept stage and turn into functional specifications documents or user guides, hand-sketching is not the most appropriate method. Hand-drawn sketches give the wrong impression of flexibility at later stages of development when the interface has already been “locked down.”

  • Reusability – Hand drawing is great for getting ideas down quickly. However, when wireframe documentation is lengthier than a couple of pages or when the documents must be re-worked over a long period, sketching loses its speed advantage and becomes a burden. In an electronic medium, changes can be made across pages and documents very quickly.

  • Prototype flexibility -Many practitioners prefer to go directly from hand-drawn wireframes to interactive prototypes, bypassing the more traditional wireframe process. However, in many situations, wireframes are used to generate interactive prototypes for proof of concept and/or usability testing. Hand-sketched wireframes are excellent for paper prototyping, but the amount of work involved increases quickly if they need to be scanned into the computer and converted into interactive prototypes. For on-screen prototypes, it is much easier to start with wireframes that are already in an electronic format.

Enter the computer-generated sketch

To compensate for the problems of both traditional and hand-sketched wireframes, certain programs allow you to create the look of hand-sketching with no drawing ability required, while retaining all of the benefits of a digital tool:

  • The style gives the impression of a work-in-progress, yet still retains a “polished” feeling that aids in acceptance by the workplace

  • Components are easily reusable for longer documents
  • Wireframes can be re-purposed for interactive prototyping

Sketchy Wireframes in Action

I discovered the need for computer-based sketchy wireframes while working on the website redesign of a well-known print media brand. I found myself presenting wireframes to executives, who would critique them in the same manner that they would a print-spread: with a heavy focus on fonts, text placements and graphic treatments. Despite frequent disclaimers that the wireframes were for high-level discussion purposes only, each presentation would drift into fixations of irrelevant details. To accommodate them, I found myself spending countless hours polishing the wireframes to look beautiful, when I should have been spending time on concept development and user testing.

To make matters worse, as we removed features from the wireframes that were determined to be “out of scope,” we continued to receive requests to bring them back, right up until the end of the project. Clearly, the wireframes were not helping to convey the right message.

On the next project, I generated the conceptual-stage wireframes using sketchy Visio stencils created by Niklas Wolkert. I began all of my wireframe presentations with an explanation of why the wireframes looked like sketches: they were intended to be malleable, rough outlines. I also prepared the executives for the next phase by telling them that the sketchy look of the wireframes would be removed as decisions became “finalized.”

Comparison of the sketchy wireframe stencils by Niklas Wolkert (right) and traditional ones by Henrik Olsen (left) at Image credit: Henrik Olsen.
Caption: Comparison of the sketchy wireframe stencils by Niklas Wolkert (right) and traditional ones by Henrik Olsen (left) at Image credit: Henrik Olsen.

The improvement in the executives’ perception of the process was immediate. The boxes and lines of the wireframe no longer had to look perfect, and the hand-drawn fonts couldn’t possibly have been mistaken for an intentional design. The executives, feeling less compelled to fix the visuals, were free to talk at a high-level about architecture and strategy. As the project transitioned from concept to execution, I removed out-of-scope features and converted the style from sketchy to traditional. This virtually eliminated later-stage requests for functionality that had previously been removed.

The reaction to computer-based sketches

Having used computer-based sketchy wireframes on a number of projects, I’ve found many ways that they can decrease confusion with teams and stakeholders:

  • Clients and Executives - People in this group typically want to push projects forward as quickly as possible. Consequently, the more “finished” the wireframes look, the faster they will expect to see the finished product. You can do yourself a disservice by making your wireframes look more complete than they are. To quote Kathy Sierra, “How ‘done’ something looks should match how ‘done’ something is.”

  • Programmers - Programmers who see traditional wireframes too early in the process may misinterpret their functionality as “signed-off.” Don’t be shocked if you hear frantic questions like “Did we agree to this?” Programming requires meticulous attention to detail, so programmers read wireframes with an eagle eye. Consequently, they may expect a level of specification from wireframes that isn’t appropriate in the early stages.

  • Designers - Designers make their living with their visual creativity, and they resist anything that could constrain it. Consequently, in situations where designers must work with wireframes created by someone else, designers can perceive them as a creative straightjacket, or worse, as a threat. A sketchy representation can help reduce friction by removing unnecessary details and adding a certain amount of “fuzziness” to the wireframes, thereby giving designers more leeway in interpreting the look and feel of the interface.

  • Users - In my research, I’ve found that users who are asked to comment on traditional wireframes can be intimidated by an overly finished look and feel. This is mirrored by a general consensus in the usability industry that the “less done” a demo looks, the more comfortable users feel with giving feedback. Where traditional wireframes can elicit comments like “I don’t like the font on those words,” sketchy wireframes are more likely to elicit comments like “I don’t know what those words mean.”

Computer-Based Sketchy Tools

There are now a number of programs that are capable of generating computer-based sketchy wireframes. However, in working with them, I’ve found that many of them are missing what I have identified as four essential capabilities necessary to be considered a “complete” sketchy wireframing tool:

  1. Ability to Draw New Sketchy Shapes -
    These days, many components of user interfaces are standardized into stencils that can be dropped onto wireframes to build them out quickly. While this can be a real time saver, not all UI problems can be solved with prepackaged stencils. In fact, one could argue that the best use of wireframes is to illustrate new concepts that have not become standardized. Many tools use pre-built, sketchy-looking stencils to allow designers to create sketchy wireframes. However, at some point you will need to create new shapes that aren’t available in your set, and a true sketchy tool must enable you to create new ones in the same sketchy style.

  2. A sketchy tool should allow you to draw.  These were created in Visio using custom line styles. This tutorial tells you how.
    Caption: A sketchy tool should allow you to draw. These were created in Visio using custom line styles. This tutorial tells you how.

  3. Easy Conversion from Sketchy to Traditional Style -
    Sketchy wireframes are a great tool for encouraging creativity, exploration, and collaboration. However, at some point, your blue-sky, creative ideas fall away and you are left with what you are actually going to build. In environments where wireframes morph into spec documents and user guides, those rough lines and hand drawn fonts must be converted to a more finished, traditional style to avoid the impression that your technical documentation is still changeable.
    Does this mean you have to go back and re-draw all of your sketchy wireframes with straight lines? Not if you can avoid it. Fortunately, certain programs allow you to convert your existing sketchy lines and fonts to traditional style without having to recreate them.

    Some software automatically converts from sketchy to traditional lines.
    Caption: Some software automatically converts from sketchy to traditional lines.

  4. Realistic Lines -
    It’s always been difficult to approximate the look and feel of true hand-drawings using software tools, but some do it better than others. The quality of drawings generated by a computer-based sketchy tool could have an impact on whether the wireframes are perceived as “conceptual” or just plain “sloppy.” These are the 3 major components needed to completely represent hand-drawn styles in wireframes:

    • Wavy Lines – No human can match the rigidity of a computer’s lines. Adding waviness and movement to lines humanizes them.
    • Varying Line Weights – When drawing conceptual wireframes, there are often areas of the screen that have yet to be explored. One way to represent this is to fade out lines as they enter these areas.
    • Smudging and smearing – These effects help to reduce focus on unimportant areas of the wireframe.

    These lines, created in Fireworks with a graphite line texture, could hardly be mistaken for true hand-sketches.
    Caption: These lines, created in Fireworks with a graphite line texture, could hardly be mistaken for true hand-sketches.

    These lines, created in Illustrator, are much closer approximations of true sketching.
    Caption: These lines, created in Illustrator, are much closer approximations of true sketching.

  5. Prototype Flexibility – For those who prototype their products, speed and efficiency of workflow is a critical issue. In this case, the benefits of creating a sketchy look and feel will become irrelevant if doing so increases the time needed to create prototypes. Fortunately, some tools allow themselves to slip naturally into the process by generating interactive prototypes that maintain the sketchy look and feel.

  6. In interactive sketchy prototype created in Visio and imported into Axure.
    Caption: In interactive sketchy prototype created in Visio and imported into Axure.

Comparison of Computer Based Sketchy Tools

Software developers are starting to recognize the importance of computer-based sketchy wireframes, and there is a growing assortment of tools to create them. This is a quick breakdown of how each of the major tools matches our criteria for a complete computer-based sketchy tool:

ShapesEasy Conversion Realistic LinesPrototype FlexibilityBalsamiq1










Expression Blend 3





Fore UI




































None = No Support

Partial = Partial Support

Full = Full Support

  1. Assumes prototype flexibility using a 3rd party program called Napkee
  2. Assumes use of custom line styles, as demonstrated in this tutorial


As the industry evolves, there is a growing trend toward hand-drawn styles, as evidenced by an expanding amount of literature and workshops on the subject. This is a positive step in the evolution of our field. Sketchy wireframes allow practitioners to guide creativity and problem solving in the early stages of projects, rather than getting lost in a sea of documentation. Hopefully, this trend will continue as software manufacturers focus on enhancing their tools for creating computer-based sketchy wireframes.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...