new design fundamentals Ebook free download pdf pdf


1 year ago
Full text


The New Design

Fundamentals A Curated Collection of Chapters from the O’Reilly Design Library









The New Design Fundamentals A Curated Collection of Chapters from the O’Reilly Design Library

  The ability to design a good user experience is increasingly important

today, and yet bad design is everywhere. Many UX and UI designers lack

the fundamental skills needed to guide users through an app or website

without effort or confusion. The O’Reilly Design Library provides the knowledge and advice you need to build your skillset and stay current with the latest trends—whether you need to help your client gain a competitive edge, or design interfaces for critical services.

This free ebook gets you started. With a collection of chapters from the

library’s published and forthcoming books, you’ll learn principles and practices for improving—and justifying—your decisions. This ebook includes excerpts from these books:

Information Architecture For the Web and Beyond

  Available in


Chapter 1. The Problems that Information Architecture Solves

Chapter 2. Defining Information Architecture Designing with Data

Improving User Experience with Large Scale User Testing

Available in Chapter 1. Why Does Data Matter? Designing Social Interfaces Principles, Patterns, and Practices for Improving the User Experience Available in


Chapter 1. Mommy, What’s a Social User Experience Pattern?

Mapping Experiences Aligning for Value Available in Chapter 1. How Bad UX Killed Jenny Articulating Design Decisions Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience Available i

  • – Fixing a Hole (Lennon-McCartney)

  What we’ll cover:

  • The dematerialization of information
  • The challenges of information overload and contextual proliferation
  • How information architecture can help people deal with these challenges

    Marla was in the mood for The Beatles. She walked over to the shelf where she kept her

    LP records and looked through her collection. Fortunately, Marla was very organized: her

    record collection was neatly sorted alphabetically by the artist’s name. Alice Cooper, Aretha Franklin, Badfinger… and there, next to her Beach Boys albums, were The

    Beatles. She pulled the Sergeant Pepper’s Lonely Hearts Club Band vinyl disc out of its

    sleeve and onto the turntable, and relaxed as the music started. For most of our history, the information we interacted with has existed in a one-to-one relationship with the artifacts that contain it. Marla had only one Sergeant Pepper’s album, and if she wanted to listen to it she needed to know exactly where it was on the shelf. If she was traveling and didn’t bring her record with her, she couldn’t listen to it.

    Because the information (the music) was physically embedded in containers (vinyl discs),

  and she only had one copy of each, she had to define “one right way” to organize her

records. Should they be ordered alphabetically based on the artist’s first name, as shown

in Figure 1–1, or their last name? What about albums in which the composer mattered more than the performer, as in her copy of Holst’s The Planets? Then there were compilation albums, containing music by many artists. Should they be listed under

“Various Artists”? And when she bought a new album, she needed to remember to store

it in the right place in the collection. It all got very complicated very quickly. Perhaps she

shouldn’t bother with organizing them at all… but then she wouldn’t be able to find them

easily when she was in the mood for a particular artist.

  Figure 1–1. Marla’s music is embedded in physical objects–vinyl records–so she must choose how to organize them on the shelf

Now meet Marla’s son, Mario. Instead of vinyl discs, Mario’s record collection consisted

of compact discs (CDs). Because the music in the discs was stored digitally, he could now randomize the order in which the songs are played. He’d been promised that the music would also sound better, and the discs would last longer than the previous

technology. It was great! However, even though the music was stored digitally, his plastic

discs were not that different from his mother’s collection: the music was still tied to the


individual physical discs that contained it. He still had to choose whether to organize the

discs by the artist’s name or the album’s name; he couldn’t do both. But then, in 2001, Mario got an iMac. The colorful computer’s advertising campaign

invited him to “Rip, mix, burn” his music–in other words, liberate it from the plastic discs

that contained it and get it into his computer (“Rip!”). Once there, it would sound just as

good as the CDs, but now he could explore it any way he pleased: he could browse his collection by artist, genre, album title, song title, year produced, and more. He could

search it. He could save backup copies. He could make playlists that combine the music

from various albums (“Mix!”) and record it onto blank discs that are starting to become popular (“Burn!”) to share with his friends. (Much to the chagrin of the people who produced the music.) As shown in Figure 1–2, Mario was no longer limited to the one-to-one relationship between information (the music) and containers (the discs) that his mother had to deal

with. He was no longer constrained to deciding between sorting the albums alphabetically

by artist name or album name; he could now do both simultaneously. He could make multiple, perfect copies of his songs, and bring them with him on his laptop when he traveled. Mario stopped thinking of his music as something tied to its container. It had dematerialized.


Figure 1–2. Being digital, Mario’s music collection can be organized in more than one way and can live in

multiple devices simultaneously

Hello iTunes

  The tool that Mario used to do all of this, iTunes, is shown in Figure 1–3. Digital music had been around for a long time before iTunes, but this was the first time that many people encountered it in the mainstream. Originally a third-party application called SoundJam, iTunes was acquired by Apple in 2000 to become the default music player

included with Macintosh computers. In its initial release, iTunes served a clear purpose: it

allowed Mario to create and manage a music library for use in his own computer. (“Rip,

mix, burn”.) He spent a long weekend importing and organizing his collection of 40 CDs

into his Mac, and put them away for good. From now on, his music would be all-digital.

  Figure 1–3: iTunes 1.0 browsing by Artist and Album. Image:

The first version of iTunes had a few distinct modes–for example, there was a “ripping”

mode that showed progress when the user was extracting music from a CD into the

computer–but its focus was clearly on allowing people like Mario to find and play music

from their own collections. As a result of this reduced feature set, it had a very simple

user interface and information structures. Mario loved it, and playing music became one

of his favorite uses for his Mac.


However, iTunes started to become more complex over time. Each new release of the app

introduced amazing new features: smart playlists, podcast subscriptions, Internet radio station streaming, support for audiobooks, streamed music sharing, and more. When Apple released the iPod, Mario rushed to get one. iTunes was now about more than just

managing music on his Mac: it was also about managing the library on his portable music

player. In 2003, Apple introduced the iTunes Music Store. Now Mario could enter a

separate mode within iTunes that allowed him to purchase music, using a categorization

scheme that was different from the one he used to organize his own library. By 2005, the

iTunes Music Store had more than 2 million songs available, a far cry from the 40 albums

that Mario had in his collection to begin with. But Apple didn’t stop there: soon it started

selling TV shows and then movies through the (now renamed) iTunes Store. TV shows,


“department” had its own categorization scheme: rock, alternative, pop, hip-hop/rap, etc.

for music, kids & family, comedy, action & adventure, etc. for movies, and so on. iTunes was not just where Mario listened to and organized his music anymore. Now it was where he went to:

  • Buy, rent, and watch movies
  • Buy, rent, and watch TV shows
  • Preview and buy music
  • Buy applications for his iPod
  • Search for and listen to podcasts
  • Browse and subscribe to “iTunes U” university courses
  • Listen to streaming radio stations
  • Listen to audiobooks
  • Browse and listen to music shared by others in his household Each of these functions introduced new content types with particular categorization schemes. iTunes still had a search box as it did on day one, but search results were now much more difficult to parse, since they included different (and incompatible) media types. Was the result for “Dazed and confused” referring to the movie, the movie soundtrack, the Led Zeppelin song, or one of its myriad covers? Later, when Mario bought his first iPhone, he was surprised to discover that the

    functionality that he was used to having in iTunes on the Mac (music, movies, TV shows,

    podcasts, etc.) had now been “unbundled” into various apps, as shown in Figure 1–4. In the iPhone, iTunes is not where you play music; for that there is an app called

    (appropriately) “Music”. However, there are no “Movies” or “TV Shows” apps; there is

    one app (“Videos”) that plays both. However, this is not where Mario can see the videos

    he has shot himself; for that he has to go to the “Photos” app. There is also an app on the

    phone where Mario can buy movies, music, and TV shows, called “iTunes Store”–the only reference to iTunes on the phone—and another where he can buy iPhone apps,

    called “App Store”. All of these apps offer functionality that is available within iTunes on

    the Mac, and all of them have different content organization structures. Later on, Apple introduced a service called iTunes Match, which allowed Mario to upload his music

    collection to Apple’s “cloud”; now he also had to keep track of which songs are actually

    in his phone and his Mac, and which are in Apple’s servers.

  Figure 1–4: iOS’s unbundled iTunes apps.

  Mario bought Apple products in part because of the company’s reputation for excellent

design. He’d heard that Apple “controls the hardware and the software”, and is thus able

to provide a unified, coherent experience across all of its products. Yet managing his

media across his Mac and iPhone is neither unified nor coherent. Also, over time Mario

has become a consumer and an organizer of an information ecosystem; he has to deal with the information structures that are designed into the system by Apple and his own organization schemes for his personal music collection, which now transcends many device form factors and contexts. Mario can’t quite put his finger on it, but he can tell

that something big is amiss with the design of these products, even though he finds them

visually appealing.

The Problems Information Architecture Solves

  Mario is experiencing two problems:

  • The tool he used to manage and navigate his simple library of 40 or so music albums has changed to one that deals with hundreds of millions of different data objects of

    various types (songs, movies, TV shows, apps, podcasts, radio streams, university

    lectures, and more), each with different organization schemes, business rules (eg., In which device he is allowed to play back his rented movie within the next 24 hours),

    and ways of interacting with the information (eg., viewing, subscribing, playing,

    transcoding, etc.)
  • • The functions provided by this tool are no longer constrained to Mario’s computer;

    they are now available across multiple devices, including his iPhone, iPod, Apple

    TV, CarPlay, and Apple Watch. Each of these devices brings with it different

    constraints and possibilities that define what they can (and cannot) do with these

    information structures (eg., “Siri, play With a Little Help From My Friends ”), and Mario doesn’t experience them as a consistent, coherent interaction model.

  Let’s look at these challenges in a bit more detail.

Information overload

  People have been complaining about having to deal with too much information for

centuries. As far back as Ecclesiastes (composed in the 3rd or 4th Century BCE), we read that “of making many books there is no end”. However, the information technology revolution that started around seventy years ago has greatly increased the information available to us. The phrase “information overload” was popularized by futurist Alvin Toffler in his 1970 book Future Shock. Toffler called out the increased rate and pace of problems that we’d have to deal with in the future. (As you can see from Mario’s example, this future is now!)

In the 19th and 20th Centuries, electronic media such as the telegraph, telephone, radio,

and television, allowed more information to reach more people over greater distances

than ever before. However, the process really sped up in the second half of the Twentieth

Century with the appearance of digital computers and their eventual connection into what

became the Internet. Suddenly, massive amounts of information could be shared with anyone in the world. The Internet–and the World Wide Web, especially–were conceptualized as two-way, interactive media. For example, you could not only receive email, but also send it. Sir Tim Berners-Lee meant for the Web to be a read-write medium; the first Web browser, called WorldWideWeb, gave as much prominence to editing Web pages as it did to browsing them. Compared to previous information

mediums, publishing on the Web was fast, cheap, and efficient. As a result, the amount of

information being published in information environments like Facebook, Twitter, and Wordpress, dwarfs anything that has ever come before.

It’s important to note that while every advance in information technologies has increased

the overall amount of information available and has made it possible for more people to

publish and have access to information, the resulting glut has also led to the creation of

new technologies to help people organize, find, and make better use of information. For

example, the invention of the movable type printing press in the 15th Century made more

books and pamphlets available more cheaply to more people. This, in turn, led to the

creation of technologies such as encyclopedias, alphabetic indexes, and public libraries,

[1] which allowed people to better manage and make sense of the new information sources.

It should not be surprising, then, that some of the great success stories of the early Web,

such as Google and Yahoo!, were companies founded to help users find information [2] online. Still, there is much more information out there than we can manage, and the findability techniques that were effective in the late 1990s (for example, Yahoo!’s curated hierarchical directory) are ineffective today. With the rise of app-centric Internet-connected mobile devices such as smartphones, it has become fashionable for pundits to postulate the demise of the World Wide Web.

However, instead of making the Web irrelevant, these devices have given access to more

people to the information available on the Internet. For many applications, the data sources that feed apps tend to be indistinguishable (if not identical) to those that power the Web. If anything, the mobile revolution has increased access to the information available in the world.

  So back to Mario. Instead of the 400 or so songs in his record collection, he can now [3]

peruse the iTunes Store’s collection of 37 million songs . Not that he can flip through it


like he could with his CDs (or even his local Tower Records ); here, he’s going to need a

bit of help to find what he’s looking for.

Context proliferation


While the information explosion has been happening for a long time, the second problem

Mario faces is newer: The relentless miniaturization of electronics, combined with widespread adoption of wireless communications technologies, has resulted in a proliferation of small, inexpensive Internet-connected devices that are transforming the way that we interact with information and with each other.

As we mentioned earlier, there was a time when information existed in a tightly coupled

relationship with the artifacts that conveyed that information. Recall Marla’s record

collection. The music in her copy of Sergeant Pepper’s was set into a singular vinyl disc

that sat on her shelf. Marla’s copy was a reproduction: many more people had similar vinyl discs with that particular music on it. However, this particular container (the disc)

and the information (the music) were irrevocably tied together after being manufactured.


Going back even further back to a time before mechanical reproductions, we find an even

tighter relationship between information and its containers. Think of early (pre- Gutenberg) books: Making a copy of a hand-written codex–the only reproduction technology available before the invention of the movable type press–was an extremely onerous process. It wasn’t easy or cheap to make copies, so individual instances of information artifacts such as books were even more valuable. Because of the rarity and

cost of these early books, reading them was an activity reserved for particular classes of

people (eg., scholars, monks, aristocrats, etc.) in specific times and places (eg., an abbey

library during daylight hours.) Now consider an ebook, such as you would read on a Kindle device. These “books” are not tied at all to their containing devices; a single Kindle e-reader can contain hundreds

of ebooks, and conversely, each individual Kindle ebook can be downloaded and read in

a wide variety of different devices ranging from smartphones to dedicated e-readers to

desktop computers. You can have the same book open in more than one device at a time,

as either a text or an audiobook, and your reading position–along with your highlights and annotations–is synchronized instantaneously between devices. The presentation of these books varies from device to device depending on the features and limitations of

each, with the text itself being an invariant that is reformatted, reflowed, and reconfigured

to fit its new environment. (Perhaps you are reading or listening to these words in such a


Whereas physical books–especially the expensive, hand-written ones–had constraints on

when and where you could use them, ebooks have no such limitations. You are as likely

to be reading a Kindle book while taking a bath as you are standing in line at the supermarket. The result is that the information (eg., the text of the book) is not just decoupled from the artifact that contains it (eg., the paper book) but also from the contexts in which we access it (eg., the quiet abbey library).

  Another important difference between physical media (like printed books) and their digital counterparts is that the latter can gather information about their usage, including

highlights, annotations, and reading patterns, and provide additional functionality based

on this meta-data. For example, Kindle apps include a feature called “popular highlights”

which allows the reader to identify the passages of a book that have been most highlighted by other Kindle readers. (Figure 1–3.) Decoupling information from its

physical containers has also made it cheaper to reproduce and distribute, and this in turn

has made it more available to more people. Fortunately, the days when information was

only accessible to monks in abbey libraries are long-gone.

  Figure 1–3. The Kindle iPad app includes features that use metadata to allow you to explore books in interesting new ways that were previously impossible

Obviously, contextual proliferation is not just happening for books; we are experiencing

Sergeant Pepper’s along with her on a trip, she needed to bring the physical vinyl disc


with her, and her music library back home would have a gap where that particular album

used to be. On the other hand, when Mario wants to bring Sergeant Pepper’s on a trip, all

he needs to do is drag a copy of the bits that represent the album from his computer onto

his iPhone. Both devices now have exact replicas of the information, and neither music library is reduced as a result of the operation. The next logical step in the dematerialization of information is for it to permeate our surroundings and become an ever-present feature of our personal interactions with the world. We can already see the beginnings of this ambient digital information layer in what is being referred to as the “Internet of Things”–the proliferation of small Internet- connected devices into everyday contexts and activities–and in “wearable” computers,

whose constant proximity to our bodies allows them to record health and activity data and

serve us small morsels of information in the form of just-in-time notifications. Devices like the Fitbit activity monitors and the Nest thermostat serve as two-way information

conduits between our physical environments and cyberspace, learning from our behavior

patterns and adjusting themselves accordingly to suit our needs.


A fascinating example of this trend towards blurring of physical and information spaces

was an innovating marketing campaign carried out in 2011 by South Korean supermarket

chain Home Plus. In a bid for increased market share, Home Plus appealed to smartphone-wielding commuters by plastering subway stations with photographs of

shelves full of groceries. Customers could walk up to these virtual shelves and order their

groceries by snapping photos of QR codes associated with products. (Figure 1–4.) Delivery would happen within minutes or hours, saving commuters time. As a result of the campaign, sales increased 130% in three months, and registered users increased [5] 76%.

  Figure 1–4: Commuter shopping Home Plus’s virtual supermarket shelves. Image: To summarize, we are not only having to deal with more information than ever before, we are also having to do so in a wide variety of different physical and psychological

contexts. This will take getting used to: We bring different expectations to a Web search

entered on a computer keyboard in a quiet office than one tapped into a 5-inch glass

screen in a football stadium or spoken into a car’s Bluetooth audio system while driving

at 50 miles per hour. Increasingly, organizations have to consider how users will access

their information in these and many other wildly different contexts. They will obviously

want these experiences to be consistent and coherent regardless of the where and how they are being accessed. So Mario is not only faced with finding new music to listen to from a collection of 37 million songs; he’s having to do so in multiple devices–notebook computers, smartphones, TV set-top-boxes, and more–that provide very different ways interacting

with the information, and in a wide variety of different contexts. Mario is going to need a

lot of help from the people who design these products and services.


Part of the reason Mario is confused is that while most software applications are designed

to solve very specific problems, the successful ones tend to outgrow their problem-set boundaries to encompass more and more functionality over time. As a result, they lose clarity and simplicity. So while iTunes started its life as a tool to enable the digitization

and management of music collections in personal computers, it grew to become a media

platform that encompasses the original music ripping, playing, and organizing

functionalities plus other media types (movies, podcasts, audiobooks, university courses,

other software applications) multiplied by other jobs (buying, renting, streaming, subscribing, sharing) multiplied by various device/interaction paradigms (Microsoft Windows computers, iPods, iPads, Apple Watches, Apple TVs). In other words, iTunes went from being a tool to being an ecosystem. Given the information and device class proliferation we mentioned earlier, this is a

situation many organizations are already struggling with. What is needed is a systematic,

comprehensive, holistic approach to structuring information in a way that made it easy to

find and understand–regardless of the context, channel, or medium the user employs to

access it. In other words, someone needs to step out of the product development trenches

and look at the broader picture in the abstract, to understand how it all fits together so that

information can be easier to find and understand. This is exactly what information architecture does.

Places made of language

  As we’ve said before, the experience of using digital products and services increasingly happens through multiple devices in different places and times. It’s important to

recognize that we interact with these products and services through the use of language:

labels, menus, descriptions, visual elements, content, and their relationships with each other, create an environment that differentiates these experiences and facilitates

understanding (or not!). For example, the language employed by a recipe app on a mobile

phone is bound to be different than that employed by an auto insurance company’s website. These differences in language help define them as distinct “places” that people

can visit to accomplish certain specific tasks: they create a frame for the information they

convey, allowing us to understand it relative to concepts we already know.


In his book Understanding Context, information architect Andrew Hinton argues that we

make sense of these experiences much like we do physical places: by picking up on particular words and images which define what can and can’t be done the environment– be it an idyllic open field in the English countryside or a Web search engine. Digital experiences are new (and very real) types of places made of language; the design challenge lies in making them be coherent across multiple contexts. As Andrew says,

  “Information architecture is a discipline well suited for attending to these challenges. It [6] has been working with them in one way or another for decades.”

Consistency across channels


How does information architecture achieve this coherence? To begin with, it does so by

asking the designer to think about these challenges in the abstract. Where other design disciplines are focused on specific instances of an artifact–the label on a bottle of detergent, the look-and-feel of an app’s user interface–information architecture asks designers to define semantic structures that can be instantiated in multiple ways

depending on the needs of different channels. A navigation structure that works well in a

Web page should function differently when presented on a 5-inch touchscreen, but the language employed in both should be consistent. (Figure 1–5.) Figure 1–5. uses a responsive layout that adapts page elements to fit in different screen sizes, while using a consistent organization structure throughout In their landmark book Pervasive Information Architecture, Andrea Resmini and Luca Rosati argue for consistency as a critical component of what they call a pervasive

  • –that is, one that is experienced across multiple channels and

  information architecture contexts. As they explain it,


Consistency is the capability of a pervasive information architecture to serve the

contexts it is designed for (internal consistency), and to preserve this logic across

different media, environments, and uses (external consistency)… Consistency needs

to be designed with the context it is addressing clear in mind, and in respect to the

[7] several media and environments that the service or process will span .

  In other words, when an organization serves its users via multiple channels, the users’ experiences between those channels should be consistent and familiar. For example, a

person using a bank’s mobile app should experience consistent semantic structures when

using the bank’s wevsite or calling the bank’s phone-based service. While the capabilities them should be familiar and consistent. In order to do so, they must be abstracted from actual implementations.

Systems thinking

  Because of this emphasis on abstracting solutions to complex challenges, information

architecture also requires that the designer think systemically about the problems at hand.

Where other design disciplines focus on the design of particular artifacts, information

architecture is concerned with defining the semantic systems that the individual artifacts–

apps, websites, voice interfaces, etc.–will be working within. Peter’s book Intertwingled

is an impassioned plea for systems thinking in the design of complex information

environments. He calls out the dangers of low-level thinking when trying to design these

new types of products and services:

  In the era of ecosystems, seeing the big picture is more important than ever, and less

likely. It’s not simply that we’re forced into little boxes by organizational silos and

professional specialization. We like it in there. We feel safe. But we’re not. This is no

time to stick to your knitting . We must go from boxes to arrows. Tomorrow belongs

[8] to those who connect .

  You can’t design products and services that work effectively and consistently across

various interaction channels if you don’t understand how they influence and interact with

each other and with various other systems that affect them. As mentioned earlier, each interaction channel brings to the mix different limitations and possibilities that should

inform the whole, so designers need to gain a high-level, comprehensive understanding of

the entire ecosystem. As a discipline, information architecture is ideally suited to this task. That said, information architecture not only produces high-level, abstract models: the

design of products and services that are findable and understandable requires the creation

of many low-level artifacts as well. Traditionally, many people think of website navigation structures when they think of information architecture, and this view isn’t entirely off: navigation menus and their ilk are certainly within the remit of what information architecture produces. It’s just that you can’t get there without having explored the more abstract territory first. Effective information environments strike a

balance between structural coherence (high-level invariance) with suppleness (low-level

flexibility), so well-designed information architectures consider both. Having a systems-level view that is informed by (and that informs) day-to-day design activities is also a good way of ensuring that you are solving the right problems. In his


So ask yourself: am I designing a cathedral or a garage? The difference between the two

is important, and it’s often hard to tell them apart when your focus is on laying bricks.

Sometimes–as in the case of iTunes–designers start working on a garage, and before they

know what’s happening they’ve grafted an apse, choir, and stained-glass windows on it,

making it hard to understand and use. Information architecture can help ensure that you’re working on the plans for a great garage (the best in the world!)–or a cathedral, if

such is the problem you’re trying to solve. In the rest of the book, we’ll show you how.


book Introduction to General Systems Thinking, computer scientist Gerald Weinberg uses

the following story to illustrate what he calls fallacies of absolute thought:

A minister was walking by a construction project and saw two men laying bricks.

“What are you doing?” he asked the first. “I’m laying bricks,” he answered gruffly.

“And you?’’ he asked the other. ”I’m building a cathedral," came the happy reply.

The minister was agreeably impressed with this man’s idealism and sense of participation in God’s Grand Plan. He composed a sermon on the subject, and

returned the next day to speak to the inspired bricklayer. Only the first man was at

work. “Where’s your friend?” asked the minister. “He got fired.” “How terrible. Why?” “He thought we were building a cathedral, but we’re building a garage.” [9]


  • • Throughout history, information has shown a tendency to dematerialize, going from

    having a one-to-one relationship with its containers, to our digital information which is completely detached from its containers.
  • • This has had two important effects in our time: information is more abundant than

    ever before, and we have more ways of interacting with it than ever before.

  • • Information architecture is a design discipline that is focused on making information

    findable and understandable. Because of this, it is uniquely well suited to address

    these issues.
  • • Information architecture addresses these issues by asking the designer to think about

    problems through two important perspectives: that our products and services are

    perceived as places made of language, and that they function as ecosystems that can be designed for maximum effectiveness.
  • • That said, information architecture doesn’t operate solely at the level of abstractions:

    for it to be effective, it needs to be defined at various levels.


In chapter two we will give you a deeper overview of the discipline of IA, and will have a

[10] shot at defining the damned thing . 1. ars/

  ↩ Google’s stated mission is to “organize the world’s information and make it universally accessible 2. and useful.”


  3. ↩ R.I.P. 4. ↩ 5. Korean-commuters.html

  ↩ Hinton, Andrew, “Understanding Context”, O"Reilly 2014 6.

  ↩ Resmini, Andrea; Rosati, Luca (2011–03–23). Pervasive Information Architecture: Designing 7. Cross-Channel User Experiences (Kindle Locations 2267–2272). Elsevier Science. Kindle Edition.

  ↩ Morville, Peter (2014–08–12). Intertwingled: Information Changes Everything (Kindle Locations 8. 149–151). Semantic Studios. Kindle Edition.

  ↩ Weinberg, Gerald (2011–04–07). An Introduction to General Systems Thinking (Kindle Locations 9. 1393–1404). Weinberg & Weinberg. Kindle Edition.

  ↩ “Defining the damned thing”–or DTDT, as it is often shortened in Twitter and mailing lists–is an 10. ongoing source of contention in the IA community, to the merriment of some and annoyance to others. When you make a living labeling things, squabbles about conceptual boundaries are an occupational hazard.


  • – Antoine de Saint-Exupéry

  What we’ll cover:

  • A working definition (or four!) of information architecture
  • Why it’s so hard to point to something and say, “that’s a great IA”!
  • A model for effective IA design

    If you’re new to information architecture, at this point you may be wondering what this is

    all about. This chapter has answers for you! And if you have been working in one of the

    UX design disciplines for a while, you may be thinking, “But isn’t information

    architecture about making sitemaps, wireframes, and website navigation menus?” Well,

    yes – these are important elements of information architecture design. But there is much

    more to this story! In this chapter, we’ll give you a broader picture of what information architecture is – and isn’t.

  A Definition Let’s start by clarifying what we mean by information architecture. in•for•ma•tion ar•chi•tec•ture n.

  The structural design of shared information environments.

  • The combination of organization, labeling, search, and navigation systems within
  • digital ecosystems.

    The art and science of shaping information products and experiences to support

  • usability and findability. An emerging discipline and community of practice focused on bringing principles
  • of design and architecture to the digital landscape.

  Were you expecting a single definition? Something short and sweet? A few words that

succinctly capture the essence and expanse of the field of information architecture? Keep


  The reason we can’t serve up a single, all-powerful, all-purpose definition is a clue to understanding why it’s so hard to design good digital products and services. We’re

talking about the challenges inherent in language and representation. No document fully

and accurately represents the intended meaning of its author. No label or definition totally

captures the meaning of a document. And no two readers experience or understand a particular document or definition or label in quite the same way. The relationship


between words and meaning is tricky at best. And here’s the paradox of defining information architecture: by defining and clarifying semantic concepts, IA makes them

more understandable and findable, but at a cost, because definitions are so imperfect and

limiting at the same time. The definition of IA itself is a great illustration of this paradox.

We’ll now descend from our philosophical soapbox and get down to basics. Let’s expand

on our definitions to explore some basic concepts of information architecture.



We use the term information to distinguish information architecture from data and

knowledge management. Data is facts and figures. Relational databases are highly

structured and produce specific answers to specific questions. Knowledge is the stuff

in people’s heads. Knowledge managers develop tools, processes, and incentives to

encourage people to share that stuff. Information exists in the messy middle. With

information systems, there’s often no single “right” answer to a given question. We’re

concerned with information of all shapes and sizes: websites, documents, software

applications, images, and more. We’re also concerned with metadata: terms used to

describe and represent content objects such as documents, people, processes, and


  Structuring, organizing, and labeling [2] Structuring involves determining the appropriate levels of granularity for the

information “atoms” in your product or service, and deciding how to relate them to

one another. Organizing involves grouping those components into meaningful and

distinctive categories, creating the right contexts for users to understand the

environment they are in and what they’re looking at. Labeling means figuring out

what to call those categories and the navigation structure elements that lead to them.

Finding and managing


Findability is a critical success factor for overall usability. If users can’t find what

they need through some combination of browsing, searching, and asking, then the

system fails. But user-centered design isn’t enough. The organizations and people

who manage information are important, too. An information architecture must balance the needs of users with the goals of the business. Efficient content

  Art and science

Disciplines such as usability engineering and ethnography bring the rigor of the

scientific method to the analysis of users’ needs and information-seeking behaviors.

  We’re increasingly able to study patterns of usage and subsequently make improvements to our websites. But the practice of information architecture will never

be reduced to numbers; there’s too much ambiguity and complexity. Information

architects must rely on experience, intuition, and creativity. We must be willing to

take risks and trust our intuition. This is the “art” of information architecture.

Just Because You Can’t See It, Doesn’t Mean It Isn’t There


One of the challenges people have with information architecture is that they can’t easily

point to it. How many times have you heard someone say, “Boy, that website’s information architecture is really terrific!” or, “I can’t find anything on this app! Its

information architecture sucks!” Our bet is, not many. But the fact that you can’t readily

see the information architecture in things doesn’t mean it’s not there. As de Saint- Exupéry said, sometimes what is essential is invisible to the eye.


To illustrate, think of the game of chess. Perhaps the image that comes to your mind is of

a chessboard like the one shown in Figure 2–1, with beautifully sculpted wooden pieces,

a goblet of brandy sitting near a flickering fireplace. And certainly that beautiful

chessboard is a common instantiation of the game we call chess. However, chess is more

than that. You could argue that what makes chess “chess” is a set of information structures that relate to each other according to predefined rules.

  Figure 2–1. A chess board with pieces in the opening position. Image:

To begin with, chess has a taxonomy of pieces which represent army units: pawns, rooks,

bishops, knights, kings, and queens. In play, there are two sets (“armies”) of such pieces:

“black” and “white”. These armies face each other in a field which consists of an eight-

by-eight grid of alternating light- and dark-colored squares. This field – the chessboard –

creates a context (a “place”) for the battle to take place.

The different types of pieces can move and interact in different ways in this board; there

are lots of rules which determine how these armies can interact. Differences in their range, scope, and numbers determine their relative worth to each army. (Table 2–1.)


Table 2–1

Name Symbol Amount per army Relative value



  1 Knight


  3 Bishop


  3 Rook


  5 Queen


  9 King 1 - (The king is invaluable: its capture ends the game.) So think back to the beautiful wooden chess set. If chess can be reduced to these basic information structures, perhaps you’re suspecting that the wooden pieces and board are somewhat superfluous and that you should be able to play chess with many different

types of sets. You’d be correct: in fact, chess can be played in many different ways which

do not involve carved wood–or any types of physical pieces–at all. For example, you may

have heard of correspondence chess, which is played over postal mail using pen and paper. (Figure 2–2.)

  Figure 2–2. Correspondence chess postcard. Image: By Schach Niggemann GFDL

( or CC-BY-SA–3.0 (,

via Wikimedia Commons Or perhaps you’re more familiar with chess as a video game, an example of which is shown in Figure 2–3. This variant is played on a computing device with the board and

pieces rendered as pixels on a screen, with the game mechanics adjusted to conform to

the device’s user interface particularities.

  Figure 2–3. Deep Green chess, played on an iPhone with a touchscreen interface

Chess can also be played in a computer terminal console, with the most minimally

symbolic user interface imaginable. (Figure 2–4.)

  Figure 2–4. GNU Chess, played with a command line interface

And of course, there are also countless variations of physical chess sets, ranging from our

beautiful wooden set, to cheap “travel” sets with minimally rendered graphics on

magnetic pieces (Figure 2–5), to the “Jewel Royale Chess Set” which is valued at almost

$10 million.

  Figure 2–5. Intense game of chess unfolding in a cheap magnetic travel set. Photo (cropped):–8jJEBH–6akZjs

These incarnations of chess are all physically very different from each other. Yet they are

all still chess. Why? Because they make manifest and afford the underlying information

structures and rules of chess. Expressing and supporting these information structures is

what makes them chess; their physical form and interaction mechanisms are interaction or

industrial design. In many ways, this in-the-abstract, platonic chess, is more “real”–but

less tangible–than the physical (or virtual) chess sets that we interact with, since it is what

makes chess different from other games.

It’s worth noting that nobody set out to explicitly create this “information architecture” of

chess; the game, its piece types and rules, its lore, etc. have evolved over centuries. This

is also true for the ways we’ve organized other information structures that afford


understanding over time: it’s only in retrospect that we can point to them and say: “that’s

a damned good information architecture!”

Towards a Damned Good Information Architecture

  Users. Content. Context. You’ll hear these three words again and again throughout this

book. They form the basis of our model for practicing effective information architecture

design. Underlying this model is a recognition that you can’t design useful information architectures in a vacuum. An architect can’t huddle in a dark room with a bunch of content, organize it, and emerge with a grand solution. It simply won’t hold up against the light of day.

  Websites, intranets, apps, and other information environments are not lifeless, static

constructs. Rather, there is a dynamic, organic nature to both the information systems and

the broader contexts in which they exist. This is not the old world of yellowing cards in a

library card catalog. We’re talking complex, adaptive systems with emergent qualities. We’re talking rich streams of information flowing within and beyond the borders of departments, business units, institutions, and countries. We’re talking messiness and mistakes, trial and error, survival of the fittest. [3] We use the concept of an “information ecology” composed of users, content, and context to address the complex dependencies that exist. And we draw upon our trusty Venn diagram (see Figure 2–6) to help people visualize and understand these

relationships. The three circles illustrate the interdependent nature of users, content, and

context within a complex, adaptive information ecology.

  In short, we need to understand the business goals behind the project and the resources

available for design and implementation. We need to be aware of the nature and volume

of content that exists today and how that might change a year from now. And we must learn about the needs and information-seeking behaviors of our major audiences. Good information architecture design is informed by all three areas.

  Figure 2–6. The infamous three circles of information architecture Is this an oversimplified view of reality? Yes. Is it still useful? Absolutely. We’ve been

using this model for 20 years. It’s held up well in all sorts of environments, from global

websites of Fortune 100 corporations to standalone intranet applications within small nonprofits. More importantly, we find these three circles incredibly helpful whenever

we’re confronted by a difficult question. After mouthing the trusty phrase “It depends”—

as all smart practitioners of information architecture do—we develop our answer by deconstructing the question into three parts that coincide with our three circles. For

example, when asked what are the most important qualities that an information architect

should bring to the table, the answer becomes quite simple: some knowledge of users and

their needs (which might come from exposure to human–computer interaction and a variety of other fields), content (think technical communication and journalism), and context (read a book on organizational psychology).

  The three circles help with other tough questions, too, such as:

What research and evaluation methods should information architects be familiar

  • with? What kinds of people should be part of the team that designs the information
  • architecture? What kinds of books and blogs should I read to keep up with the field and its
  • practice? What should go into the IA strategy that I propose to my new prospect?
  • The answer to each starts with a balance among the three areas: users, content, and context.


Should technology have its own circle? Maybe. But we find that technology usually gets

too much attention. Also, we increasingly find that much of what falls under the rubric of

technology can be expressed within the “context” circle. After all, what technology brings to the table are new possibilities and constraints that give shape to the final product, and this is squarely within the realm of the context we’re designing for. Incidentally, we think it’s important for information architects to have a good sense of

humor. Perhaps you’ve already figured this out. The work we do involves high levels of

abstraction, ambiguity, and occasionally absurdity, and to some degree we’re all still making it up as we go along.


If there’s one thing that many years of information architecture consulting has taught us,

it’s that every situation is unique. We don’t just mean that websites are different from intranets or that extranets should vary by industry. We mean that, like fingerprints and

snowflakes, every information ecology is unique. The Toyota intranet is vastly different

from that of Ford or GM. Fidelity, Vanguard, Schwab, and Etrade have each created unique online financial-service experiences. Despite all the copycatting, benchmarking,

and definitions of industry best practices that have surged throughout the business world

in recent years, each of these information systems has emerged as quite distinctive.

  That’s where our model comes in handy. It’s an excellent tool for learning about the specific needs and opportunities presented by a particular project. Let’s take a look at

how each of our three circles contributes to the emergence of a totally unique information


Context All digital design projects exist within a particular business or organizational context

  Whether explicit or implicit, each organization has a mission, goals, strategy, staff, processes and procedures, physical and technology infrastructure, budget, and culture. This collective mix of capabilities, aspirations, and resources is unique to each organization.

  Because of this, information architectures must be uniquely matched to their contexts.

The vocabulary and structure of your websites and your apps is a major component of the

evolving conversation between your business and your customers and employees. It

influences how they think about your products and services. It tells them what to expect

from you in the future. It invites or limits interaction between customers and employees.

  Your information architecture provides perhaps the most tangible snapshot of your organization’s mission, vision, values, strategy, and culture. Do you really want that

  The key to success is understanding and alignment. First, you need to understand the business context. What makes it unique? Where is the business today and where does it want to be tomorrow? In many cases, you’re dealing with tacit knowledge. It’s not

written down anywhere; it’s in people’s heads and has never been put into words. We’ll

discuss a variety of methods for extracting and organizing this understanding of context.

Then, you need to find ways to align the information architecture with the goals, strategy,

and culture of the business. We’ll discuss the approaches and tools that enable this custom configuration.

You also need to understand the contextual differences imposed by the channels that the

user will be using to interact with your organization. Will they be experiencing your services primarily via apps on mobile phones, or via a website on a desktop-based browser? Both platforms have things they can do well, and things they can’t. For example, smaller screens mean less space, which in turn implies shorter labels and navigation menus. If your service will be used via more than one channel, you need to

consider how these channels will overlap and interact with each other. All of these factors

form part of the context that will shape your information architecture.


  We define “content” very broadly to include the documents, applications, services, schema, and metadata that people need to use or find in your systems. To employ a technical term, it’s the stuff that makes up your sites and apps. Our library backgrounds will be evident here in our bias toward textual information, and that’s not such a bad

thing, given the heavily textual nature of many digital systems. Among other things, the

Web is a wonderful communication tool, and communication is built upon words and sentences trying to convey meaning. Of course, we also recognize it as a tool for tasks and transactions, a flexible technology platform that supports buying and selling, calculating and configuring, sorting and simulating. But even the most task-oriented e- commerce website has “content” that customers must be able to find.


As you survey content across a variety of digital systems, the following facets bubble to

the surface as distinguishing factors of each information ecology.


  Who creates and owns the content? Is ownership centralized within a content

authoring group or distributed among functional departments? How much content is

licensed from external information vendors? The answers to these questions play a

huge role in influencing the level of control you have over all the other dimensions.

  Websites and intranets are becoming the unifying means of access to all digital

formats within the organization. Oracle databases, product catalogs, Lotus Notes

discussion archives, technical reports in MS Word, annual reports in PDF, office-

supply purchasing applications, and video clips of the CEO are just a few of the types of documents, databases, and applications you’ll find on a given site.


All documents are not created equal. An important memo may be fewer than 100

words. A technical manual may be more than 1,000 pages. Some information systems

are built around the document paradigm, with the fully integrated document as the

smallest discrete unit. Other systems take a content component or digital asset

approach, leveraging some form of structural markup (XML or JSON, for example)

to allow management and access at a finer level of granularity.

  Metadata To what extent has metadata that describes the content and objects within your system already been created? Have documents been tagged manually or

automatically? What’s the level of quality and consistency? Is there a controlled

vocabulary in place? Or have users been allowed to tag the content? These factors

determine how much you’re starting from scratch with respect to both information

retrieval and content management.

  Volume How much content are we talking about? A hundred applications? A thousand pages? A million documents? How big is your system?


What is the rate of growth or turnover? How much new content will be added next

year? And how quickly will it go stale?


All of these dimensions make for a unique mix of content and applications, which in turn

suggests the need for a customized information architecture.



The most important thing to know about users is that when we are talking about “users”

we are talking about people. These are human beings with desires, needs, concerns, and

foibles–just like you and us. We use the word “users” as shorthand to mean “the people

who will use your information environment.”


When we worked on the first corporate website for Borders Books & Music, back in the

mid–90s before Amazon became a household name, we learned a lot about how customer

research and analysis was applied towards the design and architecture of physical bookstores.

  Borders had a clear understanding of how the demographics, aesthetic preferences, and

purchasing behaviors of their customers differed from those of Barnes & Noble. It is no

mistake that the physical layout and the selection of books differed significantly between

these two stores, even within the same town. They were different by design. And that

difference was built upon an understanding of their unique customer or market segments.

Differences in customer preferences and behaviors within the physical world translate into different information needs and information-seeking behaviors in the context of websites and apps. For example, senior executives may need to find a few good

documents on a particular topic very quickly. Research analysts may need to find all the

relevant documents and may be willing to spend several hours on the hunt. Managers may have a high level of industry knowledge but low navigation and searching proficiency. Teenagers may be new to the subject area but really know how to handle a search engine.


Do you know who’s using your system? Do you know how they’re using it? And perhaps

most importantly, do you know what information they want from your systems? These are not questions you can answer in brainstorming meetings or focus groups. As our friend and fellow information architect Chris Farnum likes to say, you need to get out there in the real world and study your “users in the mist.”


  Let’s recap what we’ve learned in Chapter 2: • There’s more than one way to define information architecture, and that’s OK.

  • Information architecture is not something you can easily point to; it is mostly abstract and exists below the surface, in the deep semantic structures of products and services. This is OK too!
  • • Our model for practicing effective information architecture design considers three

    things: users, context, and content.

  As we mentioned in the introduction to Part I, IA is focused on making information

environments findable and understandable. These are related, but different, objectives. In

the next chapter, we’ll look more closely at designing for findability. Onward!

  For a humorous perspective on the trickiness of the English language, see Bill Bryson’s The Mother 1.

  (William Morrow).

  Tongue: English & How It Got That Way

  Granularity refers to the relative size or coarseness of information chunks. Varying levels of 2. granularity might include: journal issue, article, paragraph, and sentence.


  3. For more about information ecologies, read Information Ecology by Thomas Davenport and

Lawrence Prusak (Oxford University Press, USA) and Information Ecologies by Bonnie Nardi and

Vicki O’Day (MIT Press). Nardi and O’Day define an information ecology as “a system of people,

practices, values, and technologies in a particular local environment.”


Chapter 1 Why Does Data Matter? Introduction In this chapter we want to give you a high level introduction into how bringing data into

  the design process can transform your business. To do this, we’ll give some historical examples of the critical role that data played in illuminating core problems which will hopefully show you how powerful data can be. We’ll also cover how digital interfaces have fundamentally changed our ability to use data and some of the emerging tools and services which allows even the smallest companies to gather their own data at scale. Because we are using this chapter to set the foundation for the rest of the book, we will also use it to provide some basic terminology and touch on the different philosophical approaches to data and design. Ideally we’d like to take these data terms and transform them into design terms which you will feel comfortable with.

  This chapter is much more about giving you a basic understanding of the relationship between data, business and design, rather than teaching you how to design or making you an expert statistician or data scientist. We’d like to show you how data and design are just tools that you use to build really great experiences for your users. If you are building great experiences for your users, then you have a great foundation for your business. We will feel successful if we can get you to leave this chapter convinced that understanding the data that you can gather about your users will make your design and therefore your business better.

  The Power of Digital Interfaces

  It might feel like using data is big news now, but the truth is that we’ve been using data for a long time already. For the past 20 years, we’ve been moving and replicating more and more experiences that we used to have in the physical world into the digital world. Sharing photos, having conversations, duties that we used to perform in our daily work have all become digital. We could probably have a separate discussion as to how much the migration from the physical “real” world to the digital world has benefitted or been detrimental to our society, but you can’t deny that it’s happening and only continues to accelerate at a breakneck pace. Let’s take a look at what it means for these experiences to be moving from the physical to the digital. Not too long ago, the primary way that you shared photos with someone was that you would have to have used your camera to take a photo at an event. When your roll was done, you’d take that film to the local store where you would drop it off for processing. A few days or a week later you would need to pick up your developed photos and that would be the first time you’d be able to evaluate how well the photos that you took many days prior actually turned out. Then, maybe when someone was at your house, you’d pull out those photos and narrate what each photo was about. If you were going to really share those photos with someone else, you’d maybe order duplicates and then put them in an envelope to mail to them – and a few days later, your friend would get your photos as well. If you were working at a company like Kodak that had a vested interest in getting people to use your film, processing paper or cameras more, then there are so many steps and parts of the experience that I just described which are completely out of your control. You also have almost no way to collect insight into your customer’s behaviors and actions along the process. Now let’s take the same example of sharing a photo in the digital world. Your user will take out their phone and take a photo. They may open up your Instagram, apply some filters to the photo and edit it on the spot before adding a caption and then sharing it. They might also choose to share it on different channels, like Twitter or via email. The entire experience of sharing a photo has been collapsed and condensed into one uninterrupted flow and a single screen, one that you can hold in the palm of your hand. And because all of this is digital, data is continuously being collected along the way. You have access to all kinds of information that you wouldn’t have had before. Location, time spent in each step, which filters were tried but not used, what was written about the photo and to whom the photo was sent. You can also gather consumption data on the photo, how many people viewed it or liked it? Not only are you able to gather that information on just one user, but you can gather it for each and every single user. And that data is both precise as well as dynamic – so you could get an instant understanding of how your customers behaviours and interactions might be changing and evolving with respect to your product and in reaction to changes you make to your product. All this data can be really powerful, and BECAUSE digital interfaces have made data collection so easy we have to make sure that we don’t fool ourselves into thinking that data interpretation is easier than it actually is. There is a danger that the ease in gathering data also makes it easer to make bigger mistakes with that data. It becomes our responsibility to make sure we use that data responsibly. That we are clear and careful about how we use data. We are just seeing the beginning of this time where data at scale is just as accessible to small startups as it is to well established large companies and the future holds so much promise for what designers will be able to do with access to all this information.

Commoditization of data

  We are seeing that data is quickly becoming commoditized with companies and services springing up to help you with your data. There are so many tools and services available now that can really help you gather data about your customers that there is almost no excuse to not be leveraging data more in your design and product development cycle. We’re seeing this commoditization of data happening in all aspects, Companies like and others are making it easier to get qualitative data even if you don’t have dedicated user research facilities, in fact you could argue that services like this can be stronger than traditional labs because the virtual nature of the service allows you to gather feedback from customers around the world. Optimizely, and other companies are making quantitative data collection easier by allowing companies to run quick and easy AB tests on their websites as well. We see data boot camps springing up … and there are also companies where you can outsource your data analysis to as well so that you don’t need to bear the expense of hiring and keeping data analysts on staff.

  Finally we see more and more places where there are new data degrees emerging.

Quantitative data at scale

  We thought it would be fun to include a little bit of history in this chapter, that by taking a step back, way back, it might help to give our readers some perspective into how the smart use of data has been something we have been doing for a very long time. As designers, we pride ourselves on being excellent at solving problems, seeing how others have used data to illuminate and solve the problems they face in other industries can be quite enlightening. th The 15 century marked the beginning of the Age of Discovery, when Europeans embarked on expeditions to explore the world. However, on especially long trips where they could not store fruits and vegetables, scurvy – a serious disease, was a significant problem. In May 1747, aboard the British Navy ship HMS Salisbury, naval surgeon James Lind conducted an experiment to identify a cure for scurvy. He chose six pairs of seamen suffering from the disease and gave a different “remedy” to each pair, in addition to their normal rations. Five of these pairs of sailors showed no significant improvement, but one pair, who had been prescribed oranges and lemons, quickly showed signs of recovering from the disease. th

  “On the 20 of May, 1747, I took twelve patients in the scurvy, on board the Salisbury at sea. Their cases were as similar as I could have them. They all in general had putrid gums, the spots and lassitude, with weakness of the knees. They lay together in one place, being a proper apartment for the sick in the fore-hold and had one diet common to all … two of these were ordered each a quarter of cyder a day. Two others took twenty-five gutts of elixir vitriol three times a day… Two others took two spoonfuls of vinegar three times a day …Two of the worst patients, were put under a course of sea-water. Two others each had two oranges and one lemon given them every day. The consequence was, that the most sudden and visible good effects were perceived from the use 1 of the oranges and lemons.” By this simple experiment, Lind managed to demonstrate that oranges and lemons were a more effective cure for scurvy than any of the other known remedies. Eventually, the Navy started giving citrus fruit to all sailors on long voyages, to protect against the disease.

  In another historical example, Dr. John Snow was working with the Reverend Henry th Whitehead in the midst of the 19 century cholera outbreak in London. As described by Steven Johnson in his book “The Ghost Map”, the two men worked together to take a truly multidisciplinary approach. John Snow’s scientific understanding behind the transmission of the disease was powerfully coupled with Rev. Henry Whitehead’s human understanding of the local community and their behaviors to help uncover the source and ultimately stop the spread of the disease.

  The link between British scientists and how we use data in design today might not seem immediately obvious, but Lind is credited with not only conducting the first ever clinical trial, but the first controlled experiment on multiple groups, where all factors remained the same aside from a single variable. As for Dr. Snow and Rev. Whitehead, you can see here how qualitative data was gathered and used to both provide more insight into uncovering what was going on in the communities and how that qualitative data collected at scale was able to bring insight and clarity to a phenomenon that was initially confounding. 2 The history of the modern “data scientist” is much more recent. It was in the 1960s that statisticians like John Tukey started to think more about what it was to bring a scientific approach to data analysis. In the 1970s we see these analysts start to recognize that the power they can bring to the data is to fill it with insight and more information. As we jump ahead to today, there is no question that data science is a term which now captures all the work that is done to both capture, measure and to interpret the vast amount of data that represents our users on a daily basis. We now take it for granted that in medicine, new treatments will be fully researched and rigorously evaluated against other options, before being adopted. We expect the same level of rigour in the design and engineering of safety-critical systems like aircraft, automobiles or nuclear power stations. But in the design of consumer-facing and recreational software and web sites, where human lives are rarely at stake, the pursuit of the best possible designs through a similar approach of testing various options using a scientifically structured methodology is a relatively new phenomenon. Based on the sheer volume of articles, publications, talks that we see generated about data and business, data and technology, data and marketing… it’s clear that data is a very hot topic and the currency of the day. What we want to do with this book is to take the term “data science” and expand it even further to move beyond the realm of people who consider themselves statisticians and to something that designers will start to embrace as part of their skillset as well.

  1 2­‐0029.pdf

Data roles

  As you start to incorporate the usage of data in your day to day, you’ll find that in addition to navigating the data itself, you’ll also need to navigate the various people who work with data in different ways. In some cases there might be just one person who represents each of the roles we describe, in other cases there might be an entire team based around a particular role and in some cases you will find one person might play multiple roles. We break these roles up into two key groups; those that help to create and capture the data (producers) and those who use the data and information generated from it in their work (consumers).

  Data can be generated in so many ways –through tracking of user behaviors in your product, or through interviews with customers or by soliciting user feedback through surveys. The people we often find associated with the generative side of data are; data analysts, data scientists, user researchers, designers and marketers. 3 Data analysts and scientists should be involved throughout the lifecycle of a product.

  They help to take the mass of data that is collected from a product and then help to clean, interpret, transform, model and validate that data. All of this work is done with the intent of helping the business to make better decisions. Data analysts and scientists often bring insight which can help the business predict where it needs to go, but they can also help to analyze the resulting data from a business decision to understand if the business accomplished what it set out to do. Common background for data analysts and scientists will include statistics, information management , technology and business intelligence. 4 User researchers are complimentary to data analysts and scientists and in some cases will overlap with them in terms of skills and interests – especially as user researchers start to do more of their work on a bigger and bigger scale. Typically user researchers are championing the user by seeking to understand who your users are and what they want. They are interested in both attitudinal and behavioral information about your users. They will tend to do this by focusing on qualitative information gathering via interviews, surveys, diary studies and other forms of ethnographic research. Common backgrounds for people involved in user research might include psychology, cognitive science, as well as the standard backgrounds that you often find for designers.


Designers, as we’ve been insisting throughout this book need to also be concerned with

  the generation of data. It’s not new for designers to seek information about our users or to gather information about our designs as we evaluate them. In some companies that don’t have the room for dedicated user researchers or analysts the designer will have to 3 step into those roles occasionally to get the information that they need to generate their 4

  industry designs. Designers can also play a key role in the generation of data based on what they design and choose to prototype. Designers can just as easily come from a tech or art background. Human factors or HCI are also fairly common as well.


Marketers can also be great collaborators in terms of data generation and too often we

  find that a weak tie between product and marketing means that a lot of valuable information which could be shared by both teams can get lost. Marketers are often seeking to understand the target audience, the market size of that audience and as a result often generate a lot of data around customers. Many people in marketing will have a strong business background. On the consumption side of data roles, we find people who are actively taking the insights generated from the data to help them make decisions about how to push the business forward. In this bucket, we typically find; business managers, product managers and, of course, designers.


Business managers and product managers look to data to get stronger insights into

  how the business is performing. Business metrics (which we cover in more depth in

  Chapter 2) are monitored and used to provide a health check on how the business is performing. They also look for impact of business decisions and to see if the changes that are being done in the product are performing as expected.


Designers should not only be caring about the business metrics, but also thinking about

  any additional metrics with respect to usability or the user interface. Of course designers should also be actively involved in understanding the data that comes back from user researchers or analysts on their own design throughout the product development cycle. The key for designers is to interpret these results and understanding them within the context of the larger business.


User researchers and analysts should also be consumers of each others data. Looking to

  see how a broader understanding of the data that is being collected on their product can provide clarity into why they might be seeing locally in their own data. These roles do not have strict boundaries or definitions. However, as you might find yourself playing into either a consumer or producer of data it can be helpful to understand which side of this divide it is that you are fitting into at that specific point in time.

Our use of terminology in this book

  Terms like “big data” and “design thinking” are in fairly common use now as is the distinction between “data driven” and “data informed” design. However, we’d still like to take the opportunity to define these terms and a handful of others that we’ll be relying on pretty heavily throughout the book. The terms we define in this chapter are especially important as they represent some of the key philosophical foundation of what you will find in the book.

  The term first emerged in 2007 and has generally come be used to describe very large data sets (structured and unstructured) which can has the potential to be analyzed and mined for information.


Design thinking – also a very common term which is used to describe a process for


  creating new ideas and solving problems. The term was popularized by Tim Brown and the folks at IDEO to describe a process where innovation comes from direct observation of users and relies on creating strong empathy for them. What we hope to do in this book is to not only show how all kinds of data fits nicely into the construct of design thinking, but how design thinking as a practice can also be applied to the data itself. 7 The design council in the UK introduced the notion of the “double diamond” design process model in 2005. The phases of this model are as follows:

  Phase 1: Discovery – where activities like market research, user research help to identify the user needs. Much of what we discuss in this book is leveraged at this stage of the design process. Phase 2: Definition – in this stage you are aligning the user needs to the business. It’s for this stage that its especially important to understand what your business objectives are and which metrics will help you and your team align to them best. We cover this in more detail in Chapter 2.

  Phase 3: Development – the design solutions are developed and iterated on at this stage of the process and it’s in this phase that the designer should be thinking proactively about the kind of data that they will need to capture to best understand the effectiveness of their work.

  Phase 4: Delivery – this represents the time where the product is finalized and launched. At this stage we think it’s most important for the designer to be able to close the loop and determine the effectiveness of what they have done. Understanding the resulting data from their design and how it provides insight into which next steps they should or shouldn’t take are the key things at this stage.


Quantitative and qualitative data at scale – for the purposes of this book we really

  focus on gathering either qualitative or quantitative data at scale. For us what that means is looking to getting enough information that it can be interpreted at a level that gives you the confidence that whatever you interpret as a result from that data will scale. That the

  5 6 7 %20%282%29.pdf data you are gathering and interpreting is statistically significant. We’ll talk more about the details around making sure that your data is sound in Chapter 3.


Data vs. Design vs. designer vs. designing – it may seem obvious, but we do want to

  call out that the design that is produced by a designer is a tool (in the same way that we are advocating for the fact that ‘data’ is also a tool) that is used to help the designer craft a solution for their users. The act of designing is something that we want to redefine as a process that not only speaks to the work of crafting a design, but also taking into account and incorporating data.

  Data driven vs. Data Informed vs. Data Aware

  Before proceeding we’d like to spell out some differences we have perceived in how data and design have been positioned in the industry. The three terms are “data driven”, “data informed” and one we have coined, “data aware”. You are probably already somewhat familiar with the debate between “data driven” and “data informed” and you are also probably aware of the different views that surround those terms as well as the potential pitfalls of taking too binary approach to data.

  One of the best descriptions that we’ve ever seen on the difference between data-driven and data-informed comes by way of Andrew Chen. In a well referenced post entitled 8 “Know the difference between data-informed and data-driven” , he explains that “[…]the difference […] in my mind, is that you weigh the data as one piece of a messy problem you’re solving with thousands of constantly changing variables. While data is concrete, it is often systematically biased. It’s also not the right tool, because not everything is an optimization problem. And delegating your decision-making to only what you can measure right now often de-prioritizes more important macro aspects of the problem.” The words “not everything is an optimization problem” sum up the philosophy behind this book. Our intent is to broaden the definition of “data” from being an overly strong association with AB test results to acknowledging that what companies need and should gather are multiple forms of data gathered from many different sources. In reality, many companies are already collecting all kinds of data on their customer’s behaviors: business analytics, trace log data, user experience lab-based data, interview data, customer feedback data, NPS and other industry standard data formats, call center data around issues and complaints. However one of the things we are concerned with in this book is that AB testing at scale has captured the imagination as THE tool to use even when not systematically conducted because of the enticement of large numbers …and the obsession in or industry with ‘scale’ as if large numbers can’t be wrong. We want to acknowledge that the intersection of data and design can be so much more than AB testing and to recognize that it can be equal parts art and science.

  Data driven design implies that the data that are collected are what drives design decisions. In some instances, this is the right way forward. We will give examples through the book where data are gathered and directly effect the design decision that was made next. The data is used to answer a specific 8 question and the results are unequivocal.


  In some instances however, things are more nuanced and the data might suggest an answer but it is not cut and dried. This is what we call data-informed design, where a team decides to take the data gathered with a pinch of salt, and perhaps set up another iteration of investigation. This is when more research may need to be done, different kinds of data gathered, and/or an informed creative leap is taken. We will give examples of this kind of situation in the book too.

Finally, we use the term “data aware” design to underscore the fact that the design process is a creative one, where design decisions need to be taken not just

  from data but back to data – that how a system is instrumented, that what data types are being captured and how they are combined is itself a design problem. So, designers and data scientists need to work with developers and business strategists to actively design systems so that the right data types forms are collected to address the right questions. Designers always need to be designing their hypotheses and the data they would like to see collected to test their assumptions. In this book, we want to encourage you to inform your design decisions by specific, objective evidence; data. Data comes in many forms, and it is collected in a number of different ways, and it should be used to give teams a better understanding of what customers are doing with a product. We want to acknowledge that data is not information until it is effectively managed and analyzed and it is not knowledge until it is put into the business and decision making context. Using data in our decision making entails that we reflect on the quality of the data, on what data is right for the decision making setting – that we critically engage with question relevance (as we asking the right questions?), data appropriateness (does it answer our questions) and data quality (is the data reliable? Did we lose something in data collection/curation?). It also requires we ask: would different data and/or a different analysis be more appropriate? Are we doing what is convenient rather than what is right? Being smart about data in your decision making has considerable advantages. Having common success metrics within your company can also help designers and the broader product team to align around common goals and to understand what kind of data is the most important to track and follow. So more specifically, for our purposes, we hope to present a framework that you can use as a designer to help you hone your understanding of customer behavior, align you and your team to the larger company objectives and business goals.

Personal Stories

  We thought it would be useful to share a personal story from each of us, to help share with you why we are so passionate about this topic. Each of us has seen how leveraging data smartly in the product development cycle has made an impact on our ability to react to our customers and make smart decisions.

  A note on “Why I love data” from Rochelle

  During the summer of 2011 a couple of the designers at Netflix were working on a major redesign of the website. At that time, the fundamental “bones” of the website hadn’t been touched in over 3 years even though the business had changed quite a bit. Netflix had started as a service that offered DVD-by-mail and was going through the transition of becoming more known for it’s streaming service rather than its DVD business. When

  Netflix started to offer a streaming service, the existing design for the DVD service was simply replicated with the buttons that originally said “Add to Queue” being replaced by buttons that said “Play” instead. There were a number of other artifacts from the DVD design as well, some of these artifacts were based on the technical limitations or web standards that existed at the time that the service was created and some were based on usability considerations (e.g. more information provided up front so that a customer could make an informed decision about whether or not it was worth adding a particular movie to their queue and then waiting the 2 days it would take to arrive in their mailbox.) The team was really excited to begin working on a new design and we started by clearly defining a hypothesis for the redesign: “A cleaner UI which showcases the content will lead to more viewing.” There were a number of deeper implications with this overarching statement. For example, in a world where you could just stream the movie or TV show instantly, you didn’t need to have a lot of additional information front and center - the act of playing could be the primary means of determining whether or not a piece of content was worth watching. By enlarging the box art used to represent the movies or TV shows, we could showcase the content in a more visual way which would be a more compelling way of showing off the content. Before launching the AB test, we were gathering feedback through user research and sharing prototypes with customers to see what their reaction was to the different changes we were making. Feedback generally came back positive.


Figure 1 Original “Watch Instantly” Web Page


Figure 2 New “Clean” Design

Figure 3 Play button, stars, text title all appear on hove

  The team rolled out several versions of the new design to a small group of users - running an A/B test to understand which design “performed best”. The results of these new designs were compared to the existing design to see if our hypothesis was correct and that we indeed could move our core metrics. We knew that people who streamed more from our service were more likely to retain as customers, so “hours played” was a great proxy for retention. As the results came in it was clear that the new design indeed worked better than the existing design. The viewing hours were up and we saw a small lift in retention. Given the positive results, the team was eager to roll out the winning design.


Announcement of New Netflix Design

However, the response on the Netflix blog and on twitter was strongly negative.


User feedback

  In fact, this change to the website resulted in the fastest accumulation of negative comments we had ever seen (more than 1000 posts within 24 hours). Imagine how the team felt at that moment. The flood of criticism really shook our confidence and made us question our design. You could imagine that one outcome would be to roll back all the changes we had just pushed out. However, because of the prior A/B testing we had done,

  AND because of how we had rolled out the new design, the data showed us that the new design was still performing better than the original design. Most designers know that when you make a major change to a design that people are comfortable with, that there is often a strong negative reaction because people generally don’t like change. That being said, it never feels good to be in the middle of all that criticism. The data helped to give us confidence that the reaction we were getting must have been from a strong, vocal minority. But as we picked up the pieces of our broken souls off the ground and we got the strength to look at the feedback that we had gathered from customers through a number of sources

  • we did user testing after the launch to better understand the reactions and to observe how people were using the product to see if we could identify other issues that didn’t emerge from the AB testing. We learned that the sortable list and scrolling were they key issues with the design. Luckily, when we had done the testing, these were variables that we had controlled for. We knew that we could isolate these items and work to improve on them. We were able to respond to the criticism, and do more isolated testing and iteration on the parts that users told us were problematic. If you look at the design of the website today, you’ll notice that it’s largely the same as what we originally launched. This story illustrates a number of the reasons that I really love and believe in data-aware design. A/B testing and data from user research and surveys of a broader population gave us the confidence that our decision was correct and allowed us to keep pushing forward despite the vocal, passionate reaction of some of our customers. Looking at the data helped to give us clarity around what the key issues really were and it helped us to refine our understanding of what the customer found valuable and what didn’t make an impact on them.

  A note on data aware design from Elizabeth

  In 2006, a prototype product was launched by a research scientist at Yahoo! Lab, then located at Berkeley. This prototype was a plug-in to Yahoo!’s then popular Messager service that allowed users to watch video in real time together in a chat space. Here is the scenario (see Figure X): I am chatting with you in Yahoo! Messenger, and share a link to a video with you. Rather than opening another browser, pasting the URL in, waiting for the page to download, clicking on the play button and then watching the video and reporting back to you, I could simply click on a button that said “Watch with Me” and the video would load in the chat, and we’d be able to watch it together, You hit pause, it pauses for me. I hit play it plays. And we can text chat alongside the video as it plays.

  Figure X” Zync synchronous media chat space This kind of synchronized media consumption is commonplace now but in 2006 it wasn’t. After a “soft launch” later, of course we wanted to evaluate user’s reactions to it.

  Numerous measures were taken, from links shared to time spent per session, to number of links shared, to amount of chat…. After 2 months, we had around .5 million active users a month spending on average 11 minutes a session and sharing a median of 3 videos. 43.6% of the sessions the invitee played at least one video back to the session’s initiator., we showed a 77.7% sharing reciprocation and that pairs of people often exchanged more than one set of videos in a session. We looked at content categories; in the categories of Nonprofit, Technology and Shows, the invitees shared more videos back to the initiator (5:4, 9:7, and 5:2 respectably). We later developed social network analyses of the diffusion of media content through different subgroups online. Back to 2007, the lead scientist, David Ayman Shamma, created various vizualizations of the data to try and tease out the shapes of user engagement with the product – we note that data visualization is another area where design skills are central to the advancement and improvement of the data sciences. One of the visualizations is shown in Figure Y.

  Figure Y: Percentage of actions over time This visualization shows the relative amounts of time that people spent rewinding, playing, pausing and chatting per session. Clearly this shows that people main action was chatting. However, the more interesting story arose when we looked at the data over time. This is shown in Figure Z. When we first looked at this plot, we looked at actions as pulled from the data server according to what was then a “standard” session. Here the time of a session for the data pull was set to be a certain number of minutes (describe a session). We were curious to see the sharp drop of activity, a sign of low engagement for most end-user applications where action equates to engagement. However, in tandem with activity data and summary action data analysis we were conducting observational studies of users trying Zync. And we made an observation that seems obvious in hindsight, but was not obvious until we did the observational studies: for actions like watching a video, inaction or doing nothing, is a sign of engagement. To put it simply, if you were sitting on a couch watching a video and the person next to you keep chatting, nnin that content and doing nothing. With this insight in hand, we returned to our data and widened the time window for the log analysis, we created a human-activity driven session window rather than a system session window, and we saw something very interesting: the tall spike in activity that you see at the far right of Figure Z. When the video stopped playing, people started chatting, they resumed their engagement with each other. We thus defined a whole new set of methods for determining user engagement with the product, and created a set of design guidelines for data analysis for engagement as inaction. This example illustrates several things: First, we designed several content recommendation features for Zync based on what we learned, (2) we derived a set of instrumentation for experience mining recommendations, including consideration of what constitutes a session (3) data awareness here was the understanding of how to triangulate the different data types and reconsider the first analysis as potentially misleading based on an insights from another data set.



  Figure Z: Trace log of activity in a Zync session

Upcoming chapters

  In Chapter 2, we’ll shift to focusing on the business side of things. We’ll cover the different kinds of businesses you might be in and cover how that might affect the data that you gather. We’ll also discuss how the maturity of your business might affect the metrics that you gather and how to solve for different aspects of your customer funnel. We’re also going to take a look at a few really interesting case studies from different kinds of companys a t different stages in their lifecycle including starting with one of the most (in)famous stories of data and design.

Summary/Key Takeaways

  We hope this chapter has given you a good foundation in not only some of the terminology that we’ll be using throughout the book, but also in the philosophical approach that we would like to encourage as you start to work with data in your design decisions. We want you to feel empowered by data and to recognize that by adapting this framework, you’re actually engaging in a two way conversation with your users where both data and design can be a useful tool in that communication.

  The history of using data to bring insight and information which facilitates problem solving is long, we can learn a lot by looking at how other industries have used data. Though incorporation of data into design is relatively recent, we believe this is the beginning of an exciting and long era to come. As a designer, you will play both the role of a producer and a consumer of data. There isn’t a “one size fits all” approach to data and design, and understanding the nuances of data driven vs. data aware vs data informed can be a powerful tool in design. Fundamentally, the difference between data-aware and instinct driven design comes down to what you rely on to inform your design decisions. With data-aware design, data is a creative production and is the primary decision making tool when and only when the data have been themselves well designed and have been proven to be what we call fit for


purpose ; with instinct- or experience-driven design, decision-making is more

experimental. Both paths can lead to great design. Is one way right? Absolutely not.

  Are these methods mutually-exclusive? No. For us, the “right” approach to design will vary depending on the nature of the problem you are trying to solve, how you operate best and will almost always requires a balance between leveraging experience, instinct and data. You need to have great instinct and experience to be a great designer regardless. Data can be one more (great) tool that you can add to that toolkit.

Questions to ask yourself

  We thought it would be helpful to include a section on “Questions to ask yourself’ at the end of each chapter. These questions are included as a way to spark some conversation either with yourself or within your company.

  How is your company currently using data? What kinds of data does your company use? Who is currently producing and consuming data in your company? Are there data “gaps”? How could you close those gaps? What kinds of questions would you like to answer about your users?

  Additional resources


  1 Mommy, What’s a Social User Experience Pattern?

  Tim Berners-Lee Weaving the Web, p 157, 1999

I have a dream for the Web...and it has two parts. In the first part, the Web becomes a much more powerful

means for collaboration between people. I have always imagined the information space as something to

which everyone has immediate and intuitive access, and not just to browse, but to create. Furthermore, the

dream of people-to-people communication through shared knowledge must be possible for groups of all

sizes, interacting electronically with as much ease as they do now in person.

A Little Social Backstory..


Social design for interactive digital spaces has been around since the earliest bulletin board systems. The


most famous being The Well (1985), which was described by Wired magazine in 1997 as “the world’s

most influential online community” and predated the World Wide Web and browser interfaces by several


The Well


The Well started in 1985 on a VAX system and a series of modems. Conceived by Stewart Brand

and Larry Brilliant, Brand had a simple idea to “take a group of interesting people, give them the

means to stay in continuous communication with one another, stand back, and see what happens.”

He also had the idea that community created online through written dialog could be strengthened

through offline, face-to-face meetings, and he set out to combine the two quite successfully.

From the 1997 Wired article: “But probably the most important of Brand’s early convictions for

The Well was that people should take responsibility for what they said. There would be no

anonymity; everyone’s real name would be available on the system, linked to his or her login.

Brand came up with a credo that would, through the years, spark no end of debate: ‘You own your

own words.’ That proviso greeted members each time they logged on. ‘I was doing the usual,

considering what could go wrong,’ he recalls. ‘One thing would be people blaming us for what

people said on The Well. And the way I figured you get around that was to put the responsibility

1 on the individual.’”


Since the beginning of connected computers, we have tried to have computer-mediated experiences

between people. As Clay Shirky notes in a 2004 Salon article, “Online social networks go all the way back

to the Plato BBS 40 years ago!”



“PLATO (Programmed Logic for Automated Teaching Operations) originated in the early 1960’s

at the Urbana campus of the University of Illinois. Professor Don Bitzer became interested in

using computers for teaching, and with some colleagues founded the Computer-based Education

Research Laboratory (CERL).


“The sense of an online community began to emerge on PLATO in 1973–74, as Notes,

Talkomatic, ‘term-talk’, and Personal Notes were introduced in quick succession. People met and

got acquainted in Talkomatic, and carried on romances via ‘term-talk’ and Personal Notes. The

release of Group Notes in 1976 gave the community fertile new ground for growth, but by that

time it was already well established. The community had been building its own additions to the

software infrastructure in the form of multiplayer games and alternative online communications.

One such program was Pad, an online bulletin board where people could post graffiti or random

musings. Another was Newsreport, a lighthearted online newspaper published periodically by

Bruce Parello, aka The Red Sweater.”

Excerpted from David R. Woolley’s 1994 article “PLATO: The Emergence of Online Community”

( An earlier version of this article appeared in

the January 1994 issue of Matrix News.


In the early days of the Web, social experiences were simply called community and generally consisted of

message boards, groups, list-servs, and virtual worlds. Amy Jo Kim, author and community expert, calls

these “place-centric” gathering places. Community features allowed users to talk and interact with one

another, and the connection among people was usually based on the topic of interest that drew them to the

site in the first place. Communities formed around interests, and relationships evolved over time. There was

little distinction between the building of the tools to enable these gatherings and the groups of people who

made up the community itself. Bonds were formed in this space but generally didn’t exist in the real

(offline) world.


The interfaces and interaction design for these types of tools were all over the board—from graphical

representations like eWorld (see Figure 1-1) to scary-looking, only for early adopters, text-only BBSs, to

the simple forms of AOL chat rooms.



Figure 1-1. The very graphical interface of eWorld was the next step up from BBSs and

was competing with AOL.


The first example that straddled the line between community and what we now call social networks was the

site ( (1997; see Figure 1-2). SixDegrees showcased connections

among people, allowed users to create and manage their personal profiles, and brought people together

based on interests and other features. Sound familiar?



Figure 1-2. ( was one of the first social networks

that connected people and built user profiles.


Somewhere along the way, though, before the first dot-com bust in 2000, community became a dirty

word—most likely because it was overly resource-intensive to build and care for, and no one had quite

figured out how to make money from all that work.

With the advent of Web 2.0, and the second wave of websites and applications and the richer experiences

they offer and the proliferation of mobile devices allowing people to carry their networks with them


networking has taken on a new life. Suddenly, it is all the rage, and every site must have social experiences.

In fact, mobile thrives on this and even enterprises now understand the values of these features. In this

phase, social has many more components and options available to users, but still generally means features

or sites that allow interaction in real or asynchronous time among users. The tools are more robust, storage

space is more ample, and more people are online to participate. The increase in online population is a major

driving force for the shift to prioritizing these types of features and sites. There is critical mass now. By

2010, 87% of Americans, 70% of Europeans, and over 50% in the rest of the world were online and



Another key difference between the first cycle of social and now is that the social network—the real

relationships with people that we know and care about—is key to the interactions and features. Features are

gated based on the degrees of connection between two people. Many of the tools, apps, and websites offer

features and functions that support existing offline relationships and behaviors. These places count on each

person bringing his personal network into the online experience. The concept of tribes and friends has

become more important than ever and has driven the development of many products.


What was ho-hum in 1997 is now the core—for user features as well as opportunities for making money.

Additionally, the power of the many, or the wisdom of crowds, is being leveraged to exert some control

over content creation and self-moderation processes. Companies are learning that successful social

experiences shouldn’t and can’t be overly controlled. They are learning they can leverage the crowd to do

some of the heavy lifting, which in turn spares them some of the costs. User-generated content has helped

many businesses and the participating community keep things moderated.


The other factor contributing to the spread of these types of features is the expertise of a new generation of

users. These folks have grown up with technology and expect it to help facilitate and mediate all their

interactions with friends, colleagues, teachers, and coworkers. They move seamlessly from computer to

their mobile device or phone and back, and they want the tools to move with them. They work with

technology, they play in technology, they breathe this technology, and it is virtually invisible to them.

In the years we have been living in the social web, we are seeing tensions around privacy, around

permanence versus ephemerality and people are beginning to question how these experiences can be

archived for future generations while others want guarantees that the words and ideas and experiences they

share have a half-life shorter than the speed at which they are propagated across the internet. The deeper

philosophical, ethical and cultural questions are now part of the dialogue and the differing attitudes across

the world and demographically, effects how these tools and experiences are developed and nurtured.


The terms community, social media, and social networking all describe these kinds of tools and

experiences. The terms often are used interchangeably, but they provide different views and facets of the

same phenomenon.

In a paper published in the Journal of Computer-Mediated Communication in 2007, danah boyd, a noted

researcher specializing in social network sites, and Nicole B. Ellison defined social network sites as “web-

based services that allow individuals to (1) construct a public or semi-public profile within a bounded

system, (2) articulate a list of other users with whom they share a connection, and (3) view and traverse

their list of connections and those made by others within the system. The nature and nomenclature of these

connections may vary from site to site.”

According to Wikipedia, “social media is the use of electronic and Internet tools for the purpose of sharing

and discussing information and experiences with other human beings,” and it defines social networking as

“a platform to build social networks or social relations among people who share interests, activities,

backgrounds or real-life connections. Most social network services are web based and provide a means of

ways for users to interact over the internet, such as e-mail and instant messaging services.” Community is

defined as the group of people who utilize these environments and tools.

  Well, What About That Social Media? Can You Expand on That?

The term social media first came on our radar as a way of generalizing what was going on with blogs circa


conversational ecosystem to arise, become a bubble, calve into many smaller overlapping and distinct

subcommunities, and so on.

In that scenario, the blog posts were the media, but then (as now) much blogging involved linking to

sources that themselves might come from the traditional, mainstream media (or MSM, as some of the

political bloggers tend to call it) or from other independent voices. Many people online realized they were

consuming much of their media (news, gossip, video clips, information) through social intermediaries:

reading articles when a more prominent blogger linked to them, discovering media fads and memes by

following BoingBoing or many other similar trend-tracking sites, and tuning in to the blogs and

publications of like-minded people and relying on them to filter the vast, unfathomable information flow

for those valuable nuggets of relevancy.

Along the way, the term social media began to stand in for Web 2.0, or the Social Web, or social

networking, or (now) the experiences epitomized by Facebook and Twitter. Christian called this “the living

web” in his last book, The Power of Many: How the Living Web is Transforming Politics, Business, and

Everyday Life (Wiley). Technorati tried branding it as the “world live web.” The idea is that as the internet

in general becomes more social (that’s the word we’ve all converged on) and everything is social and social

is everywhere, there is an element of it that is read-write, that involves people writing and revising and

responding to one another, not in a one-to-one or one-tomany fashion, but many-to-many. The problem

with using social media as a generic term for the entire Internet-enabled social context is that the word

“media,” already slippery (does it refer to works of creation, or to finding relevant news/media items, or to

public chatter and commentary, or all of these things?), starts to add nothing to the phrase, and doesn’t

really address the social graph.

We continue to see a proliferation of social media marketing experts and gurus online, and their messages

range from the sublime (that marketing can truly be turned inside out as a form of customer service,


through Cluetrainful engagement with customers, i.e., treating them as human beings through ordinary

conversations and public responsiveness), to the mundane (as in the early days of the Internet, every local

market has its village explainers), to the ridiculous (a glorified version of spam).

The collection of patterns that comprise this book were once labeled “social media patterns,” after the

social media toolkit that Matt Leacock started at Yahoo!, but as it evolved, it became clear that we were

using “social media” to mean “social networking” or “involving the social graph” or just “social,” so for

clarity’s sake, we’re using it to refer to “media that is created, filtered, engaged with, and remixed

socially.” Here’s a similar, but slightly more community-oriented definition of social media from Harjeet Gulati:


Social Media collectively refers to content (in the form of Text (Blogs, Discussion Forums, Wikis), Voice

(Podcasts), or Video (YouTube) that is generated by the community of users for consumption within the

same community. In this model, the role of Publisher and Consumer of information is delegated to the

community at large. The role of the Channel becomes key in this model even as the degree of control that the

community exercises over the content that is displayed within the boundaries of a given system varies. Where

the term “media” meant traditional channels like Newspaper, Radio and Television, the advent of the Web in

the early nineties accelerated the inclusion of the Web as a medium to reach out to others. The content

ownership in traditional media continued to be with the “publishers” of content—the production houses,

newspapers, tv channels, and radio stations. Content Owners/Publishers, the Channel and the Consumers

were clearly differentiated. As the Web continued to evolve, the term “Social Media” has come to dominate

the discussion. Social Media encourages a participative, collective model of content creation, distribution and

usage and is more representative of the tastes and inclinations of the community at large.


We find it most useful to focus on the social objects (which may be media objects, but may also be such

things as calendar events) and the activities people can do with them, and with one another, through our

social interfaces.

For a further exploration of this term, see also “Social Media in Plain English”

( from Common Craft.

What Do We Mean by Principle, Best Practice, and Patterns?


With the growing expectation of seamless experiences, it is important for designers to see the emerging

standards and to understand how one experience of a site and its interactions affects expectations for the

next site. By working with standard and emerging best practices, principles, and interaction patterns, the

designer takes some of the burden of understanding how the application works off the user, who then can

focus on the unique properties of the social experience she is building.

To start, we do define these three things differently. They live along a continuum, from prescriptive (rules

you should follow) to assumptions (a basic generalization that is accepted as true) to process (ways to

approach thinking about these concepts).

Principle: A Basic Truth, Law, or Assumption


Principles are basic assumptions that have been accepted as true. In interaction design, they can lend

guidance for how to approach a design problem, and have been shown to be generally true with respect to a

known user experience problem or a set of accepted truths.


For example: Be learnable—create systems that are easily learned and provide cues for users to predict how

things work from one area to another.

Principles don’t prescribe the solution, though, like an interaction pattern does; instead, they support the

rationale behind an interaction design pattern or set of best practices.

Practice (or Best Practice): A Habitual or Customary Action or Way of Doing Something


Best practices are funny things. They are often confused with principles or interaction patterns. They fall

along the continuum and are less prescriptive than an interaction pattern solution—at least in our definition.

We often include best practices inside an interaction pattern.

For example: In a mobile context, Design for Touch. Make sure buttons, forms and other elements are large

enough to interact with and accommodate human fingers without accidently triggering neighboring


The best practice helps clarify how to approach a design solution, and is generally the most efficient and

effective way to solve the problem, although not necessarily the only way.

Pattern: A Model or Original Used As an Archetype

  When we first started working with interaction design patterns, we defined a pattern as:

Common, successful interaction design components and design solutions for a known problem in a context.

Patterns are used like building blocks or bricks. They are fundamental components of a user experience and

describe interaction processes. They can be combined with other patterns as well as other pieces of

interface and content to create an interactive user experience. They are technology and visually agnostic,

meaning we do not prescribe particular technological solutions or visual design aesthetics in the patterns.

User experience design patterns give guidance to a designer for how to solve a specific problem in a

particular context, in a way that has been shown to work over and over again.

The notion of using interaction design patterns in the user experience design process follows the model that

computer software programming took when it adopted the concepts and philosophies of Christopher

Alexander. Alexander, an architect, wrote the book A Pattern Language. In his book he describes a

language—a set of rules or patterns for design—for how to design and build cities, buildings, and other


Alexander says that “each pattern describes a problem which occurs over and over again in our

environment, and then describes the core of the solution to that problem, in such a way that you can use this

solution a million times over, without ever doing it the same way twice.”

In addition to developing this language of elemental repeatable patterns, he was concerned with the human

aspect of building. In a 2008 interview, Alexander says that his ideas “make [homes] work so that people

would feel good.” This human approach and concern for the person (as user) is part of what has appealed to

both software developers and user experience designers.

The idea of building with a pattern language was adopted by the computer software industry in 1987, when

Ward Cunningham and Kent Beck began experimenting with the idea of applying patterns to programming.

As Ward says, they “looked for a way to write programs that embraced the user, where users felt supported

by the computer program, not interrogated by the computer program.”

This approach took off, and in 1995 the book Design Patterns: Elements of Reusable Object-Oriented

Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the Gang of Four)

was published.


In 1997, Jenifer Tidwell published a collection of user interface patterns for the human-computer

interaction (HCI) community based on the premise that capturing the collective wisdom of experienced

designers helps educate novice designers and gives the community as a whole a common vocabulary for

discussion. She specifically stated that she was attempting to create an Alexandrian-like language for

interface designers and the HCI community. The evolution of that site and her work became the book

Designing Interfaces , published in 2005 by O’Reilly Media.


Several others published collections on the Web, including Martijn van Welie, a long-time proponent of

patterns in the interaction design realm, which in turn inspired my (Erin’s) team at Yahoo! to publish

portions of our internal interaction pattern library to the public in 2006.

I (Erin) had joined Yahoo! in 2004 to build a pattern library for the ever-growing user experience design

team and to create a common vocabulary for the network of sites that Yahoo! produced for its hundreds of

millions of global users. We built the library in a collaborative manner, utilizing the most successful, well-

researched design solutions as models for each pattern. Designers from across the company contributed

patterns, commented and discussed their merits, added new information as technology and users changed,

and moderated the quality and lifecycle of each pattern. In 2006, spearheaded by Bill Scott, we were able to

go public with our work with a subset of the internal library. The work was very well received by the

interaction design and information architecture community, and inspired many in their design work. From

2007 – 2010, Christian further evangelized the library to bridge the gaps between design and development

and open source communities. Since our first edition, several other pattern libraries have joined the

growing body of work including pattern collections for mobile, for Android specifically, for supporting

responsive code libraries and many other companies have publicly published their libraries (MailChimp,

BBC, Intuit Small Business’s Harmony ecosystem, Google and their Material Design patterns) in order to

rd share their knowledge, inform 3 party developers and inspire the design community.


The notion of having a suite of reusable building blocks to inform and help designers develop their sites

and applications has gained traction within the interaction design community as the demands for web and

mobile interfaces have become more complex. When the Web was mostly text, there wasn’t a whole lot of

variety to how a user interacted with a site, and the toolkit was small. The complexity of client applications

was difficult at best to duplicate online. But that was then. Now, whole businesses and industries rely on

easy-to-use web-based software [SAAS] and mobile applications to conduct their business. There is more

need than ever to have a common language for designers and developers. And because social is now

integrated into every facet of interactive experiences, it is important to put a stake in the ground about just

what those pieces should be and how they should and shouldn’t behave.

  The Importance of Anti-Patterns

The term anti-patterns was coined in 1995 by Andrew Koenig in the C++ Report, and was inspired by the

  Koenig defined the term with two variants: Those that describe a bad solution to a problem that resulted in a bad situation.

  • Those that describe how to get out of a bad situation and how to proceed from there to a good solution.
  • Anti-patterns became a popular method for understanding bad design solutions in programming with the

    publication of the book Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis by

    William Brown et al.

    For our purposes, anti-patterns are common mistakes or a bad solution to a common problem. It is

    sometimes easier to understand how to design successfully by dissecting what not to do. In the world of

    social experiences, often the anti-patterns have some sort of jarring or malicious side effects like social

    group faux-pas or in the extreme—identity theft.

    The anti-patterns we illustrate in chapter 2 and 3 will point out why the solution seems good and why it

    turns out to be bad, and then we will discuss refactored alternatives that are more successful or gentler to

    the user experience.

Thinking Mobile


The proliferation of mobile devices worldwide, especially after the introduction of the iPhone and Android

smartphones has changed the way people interact with their social networks. By 2013, 61% of smartphone

users were accessing social media on their mobile devices. And the Y Generation (Millenials 18-29), are

the fastest growing and largest users of social networking sites with the majority of that access being done

via mobile devices.

When considering social interfaces, remember that the mobile device is inherently a social device. Build

easy, one-click opportunities for connecting people together with others and their content. People want to

be connected to their network all the time. Mobile devices are along for the ride and are generally always

available, whereas computers are not.


Figure 1-3. Yelp has translated their successful web service to the iPhone. This

screenshot shows a listing of “Coffee Shops” nearby the location of the phone and user.


If you are designing a social experience, consider thinking mobile first. Mobile users don’t want a “less

than” experience, they want an experience that is appropriate to their device and it’s size, that takes

advantage of features inherent in the device, like location. General interface factors to consider are:

  • Infinite lists that load only as needed to cut down on download costs.
  • Auto-complete within forms as much as possible to avoid typing.
  • Graceful interpolation of intent when typing on small keyboards.
  • Making the ability to share everything and anything from anywhere as easy as possible.
  • Larger clickable targets and gestural interactions.
  • Take advantage of time and location
  • Leverage existing data. For example, utilize the common information from the user’s address book and location rather than duplicating or requiring new data to be input.


Mobile devices are often people’s only computers, but the rules are different and the interaction patterns

need to adjust themselves accordingly. Designers should become familiar with the basic principles that are

common across all devices. The complexity, though, lies in the fact that there are no standards in screen

size, in type (keypad, touchscreen, pen-based), or in how the hardware interacts with the software.


Most of the social patterns discussed here can be combined to create interesting and rich social experiences

in mobile and web or for mobile exclusively with minor modifications.

Designing Social for Mobile

  I’ve been designing for mobile since before the first iPhone was released. People used to ask me all the time how I could stand it. How could you do anything on those tiny screens? A few years and a billion or so smart mobile devices later, no one’s asking that anymore. The app store model has changed the rules of engagement, the rules of design, and the competitive landscape, and almost overnight, we are all designing “mobile first.” Mobile design to me (as compared to desktop design) is like writing sonnets—or better, haiku—as compared to writing free poetry. The structured nature of mobile design makes it more important than ever to understand our users’ passions, motivations, context, and decision-making processes.

  With that in mind, I share with you my “Dos and Don’ts” for mobile design, some of which are the same as they were five years ago, and some which have emerged as this space has evolved. Do:

  • Use the 5-minute rule. Mobile users are, well, mobile; they’re going to use your application while standing in line at the sandwich counter/waiting at the bus stop/sitting on the couch waiting for the commercial to be over. Make sure that whatever your mobile app or site’s raison d’être is, it breaks down easily into short bursts of activity. Even better if those bursts of activity are super-entertaining or super-useful.
  • Some focused research and task analysis. Figure out who your user is, what she cares about most, and what she’s really going to use your app for in those five minutes—and make sure your designs do those top one or two things well.
  • Expect – and design for – interruption. Not only in the user’s thought process (what was I doing before I lost reception/had to pay for my takeout/arrived at work?), but also between
multitasking features, I am still cursing every time I receive a text that blows away a response I had been writing to another.

  • Dazzle (or at least intrigue) them quickly, or lose them just as quickly. Sure, your engineering and design geek buddies might have fun tinkering with the guts of the settings on their phones, but in the app store world, your users have lots of choice and little patience for delayed gratification. Make sure your app demonstrates its value immediately. Get familiar with the mobile ecosystem. Take a field trip to a local shop or three and play with
  • the display models. Develop a habit of watching people texting and playing mobile games on the train and reading their email in the elevator. Immersion can quickly make you a local in Mobile-landia, rather than a tourist. Make informed, user-centered decisions about whether to start with a responsive mobile web
  • site or a native app. The right choice is going to depend on your target user base, your business’ goals and engineering capacity. In short: Do you need to go broad, release a small set of features/content to as large an audience as possible, as quickly as possible? Then go mobile web. Do you need to go deep, impress the heck out of iPhone users right out of the gate, with the best possible user experience and use of the latest iOS APIs? Best be going native. Design leadership in the twenty-teens and beyond requires that you be able to facilitate this conversation, and make sure your team makes the most effective choice for the design problem you are solving. Think about the business. How will your app make money? How will your social ecosystem
  • sustain itself? One thing that’s changed is that more and more folks are willing to put up with ads, particularly relevant ones, to get something for free. What will inspire them to pay for the premium version (other than an assumption of annoyance that might no longer be valid)? It pays to understand your particular persona’s motivations.


  • …pare down the feature set too much. Sure, if you’re converting a successful desktop app or site to mobile, you MUST prioritize the flow hierarchy effectively. However, too many mobile designers – even of successful commercial apps – remove key features on a misguided search for “simplicity.” I mean, who thought it was a good idea to release the first version of mobile Gmail without search? Who on earth decided not to let me delete a Dropbox folder in a hurry while waiting for my latte, or reorder my Netflix queue during my bus ride home? There are plenty of interaction design patterns, such as the ones you’ll learn about in this book, that you can use to indicate hierarchy or relative importance. Use them. …think that shrinking a desktop app down to mobile size is going to work—especially on a
  • touchscreen. Many mobile designs that fail do so because the designer (or engineer) who built them assumed that a mobile device was just a very small computer. This is true both from a UI control standpoint (making clickable elements large enough for clumsy fingers) and from a “how people’s brains work” standpoint (context, as above and as ever, remains king).
  • >…assume. You probably know what my dad says happens when you assume. What I mean in a mobile design context: my students were doing a project recently, geared towards increasing public knowledge of and access to below-market-rate real estate in San Francisco. They had a hypothesis that mobile access to this service might not be very important, because people who would benefit from the service might not have mobile device access. Their research proved them dead wrong – 80% of their target audience showed up to an informational workshop, smartphones in hand. Good thing they were such diligent researchers and designed from real user observation, rather than designing from stereotypes or “gut feelings.” …think about software. Not so much in the Lakoff “don’t think of an elephant” sense, but
the time. It flows in and out of your hand like an extra limb or an extra brain, available to fill in the gaps in your knowledge, ability, attention span, or location. When you’re checking Facebook, you’re not thinking about what buttons and sliders and widgets are on the screen, you’re having feelings about the people whose posts you’re reading. When you’re buying a plane ticket online, you’re not thinking about those buttons and sliders either -- you’re having feelings about where you’re going, whom you’re visiting, how much you can afford to spend.


Unless you’re an interaction designer, of course, in which case you’re thinking about the software

all the time.

The point is, in mobile more than anywhere else we’ve designed for: if you’re having a

conversation about features and what UI controls are on the screen, rather than the experience

you’re delivering, you’re having the wrong conversation, and your app will suffer.


In 2009, when I wrote the original essay for the first edition of this book, mobile phones were

highly disconnected devices. Heavy dividers separated social interaction in different applications –

email, texts, or calls to contacts lived in their own silos, and Facebook, Twitter, and other

networks lived in their own separate universes.


At that time, it seemed revolutionary to point out that “contextually speaking, mobile phones are

by definition social networking devices,” and to encourage designers to “break out of the classic


phone/phone book mental model and transform that experience to include 21 -century-style social

networking.” It’s exciting to see that as a design community, we have taken up the challenge and

initiated more transformation and disruption that I could have imagined.


The depth of connection enabled by the mobile user experience has increased along with this

transformation, and brought with it not only new opportunities, but also privacy concerns we

designers need to consider. I like to make an analogy to politics, which is what I studied in

college. In government, there’s a tradeoff between Protection and Freedom. Individuals locate and

re-locate themselves along that spectrum depending on their context (race or class, what’s

happened in their local communities, whether it’s an election year, etc.) With respect to mobile

design, the tradeoff is between Convenience (or Pleasure) and Privacy – and people will also

locate and re-locate themselves similarly. The same hard-working tired mama, for instance, might

bristle at letting an app her employer accesses save her credit card details, but not blink an eye at

leaving the same data on the servers of an app company that allows her to press a single button

and have takeout on her doorstep when she arrives home with the kids. The point? It’s become

complex. Find out where your user stands, and why.

  A few final questions to consider in your mobile experience design process:

  • • What does the intimacy my user has with his/her phone mean for how s/he experiences

    mobile social networks? (Think about the difference between the majority of my Facebook or Twitter friends, as opposed to the ones whose updates I set to vibrate in my pocket.) What experience am I offering my users to make it worth it for them to trust me/my app with
  • their data? What is and isn’t ethical to do with the data, for the purpose of improving the personalization of their experience? How about for the purpose of improving the business’ bottom line? What kind of experience can I offer my user that is special because I have an aggregate
  • understanding of all the people participating in the ecosystem, what their relationships are to one another and to the content of this particular app?

  If my own experience is indicative, thoughtfulness on these topics will make your design process more exciting, and your applications more compelling. —Billie Mandel, UX design instructor at General Assembly, experience design consultant, and once-and-future design director

So, That’s All the Little Parts: Now What?


Our approach for the rest of this book is similar to Christopher Alexander’s, in that we start with a

foundational set of high-level practices that underpin the individual interactions detailed in subsequent


In each section, we talk about which patterns build on others and how you can combine patterns to create a

robust experience. We cross-reference patterns and give examples from the wild where we see examples of

these patterns in action.

The social patterns support the entire lifecycle that a user may experience within a site or application, from

signing up to actively participating, to building a reputation, to dating or collaborating with friends, to

collaborative games and even moderation. We are building a vocabulary and language for social

application design in the same spirit as Alexander:


We were always looking for the capacity of a pattern language to generate coherence, and that was the most

vital test used, again and again, during the process of creating a language. The language was always seen as a

whole. We were looking for the extent to which, as a whole, a pattern language would produce a coherent



Patterns...or Clichés?

Clichés. They’re a dime a dozen. Avoid them like the plague, or so we’re told.


But are they really that bad? Would we really be better off if, every single time we wanted to say

something, we had to start from scratch and think of a whole new way of saying it?

The word cliché comes from printing with movable type: typesetters would take a commonly used

expression and cast it in a single block called a cliché, rather than setting the whole phrase by hand

every time. Over time, the term came to be used to describe the words and phrases themselves. For

authors who are tempted to use them, clichés can indeed be problematic: In a writer’s hasty use of a cliché, he may end up saying something he didn’t exactly mean.

  • By choosing a cliché instead of looking for something new, the author loses an opportunity to
  • surprise and delight the reader with more elegant or thought-provoking words. An overly obvious cliché may come across as cheesy and banal: readers will hear the cliché, not
  • the message.

    But in normal life, clichés are not only permissible but are, in fact, critical to our everyday

    communication. Clichés make our messages efficient and more easily understood. So are design patterns the same as clichés?

    In a sense, yes: they’re proven, ready-made, and often familiar ways of solving creative problems.

    And just like with clichés, it’s important to recognize when they are useful and relevant... and

    when they are ill-suited or misleading.

    In an interview with the Unbeige blog, designer and author Steven Heller was asked about his

  design process:

Unbeige: What’s the first thing you do when you’re starting to design something, and you’re faced with a

blank page/computer screen?


It’s true: a design pattern, or a cliché, is often just a starting point. It’s often the first thing you

reach for from your palette of design tools when assembling the rough outlines of a design

solution. A writer’s quick first draft of an essay or story may include a few hackneyed clichés she

will eventually improve, sometimes with the help of an editor. Think of patterns the same way:

your first pass at a user experience design may include a few basic patterns that, as initially drawn,

feel a little too obvious, almost cliché. But when you view them again in the big picture, you can

see where they don’t quite work and will require some changes and improvement. A little

wiggling around.


Occasionally a basic design pattern will be a perfect fit the first time out. But usually not. You

should always think hard about how the pattern itself could be reimagined to suit the particular

demands of your product. So go ahead: reinvent the wheel. —Christopher Fahey, SVP Product and User Experience at Big Spaceship

Further Reading


Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis , by William Brown, Raphael

Malveau, Skip McCormick, and Tom Mowbray, Wiley, 1998

Community Building on the Web: Secret Strategies for Successful Online Communities , by Amy Jo Kim,

Peachpit Press, 2000

Design Patterns , by Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides, Addison-Wesley

Professional, 1994 Design for Community , by Derek Powazek, Waite Group Press, 2001 Designing for the Social Web , by Joshua Porter, New Riders Press, 2008 Designing Interfaces , by Jenifer Tidwell, O’Reilly Media, Inc., 2005 Groundswell , by Charlene Li and Josh Bernoff, Harvard Business School Press, 2008

A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series), by

Christopher Alexander, Oxford University Press, 1977 Social Media in Plain English, A Timeless Way of Building , by Christopher Alexander, Oxford University Press, 1979

The Virtual Community: Homesteading on the Electronic Frontier , by Howard Rheingold, The MIT Press,


  , by Katie Hafner, The Well: A Story of Love, Death and Real Life in the Seminal Online Community Carroll, Graf Publishers, 2001 Mapping Experiences



  Early R & U RAW

  James Kalbach

  1 Locating Value with Alignment Diagrams

  In This Chapter:

  Introduction to alignment diagrams Value-centered design Distinguishing diagram types Principles and benefits of alignment diagraming


There is only one valid definition of business purpose: to create a customer.

  • – Peter Drucker, in The Practice of Management (1954)

  People expect some benefit when they use the products and services an organization provides. They want to get some job done, solve a problem, or experience a particular emotion. If they then perceive this benefit valuable, they’ll give something in return – money, time, or attention.

  To survive, organizations need to capture some worth from their offerings. They need to earn profit, maximize reach, or improve their image. Value creations is bi-directional. But how do we locate the source of value in such a relationship? Simply put, value creation lies at the intersection of human interaction with the provider of a service. It’s where the experiences of individuals overlap with the offerings of an organization.




  A number of years ago, I was struggling to determine which type of diagram to use on a project: a customer journey map, mental model diagram, service blueprint, or something else. After some comparison of several examples, a similar set of principles became apparent: these diagrams all represent the value creation equation in some way.

  Viewing the commonalities of various diagrams opened up possibilities. I wasn’t locked into one prescribed method over another. I realized the focus should not be on a specific technique, rather on the broader concept of value alignment. More importantly, I was better able to connect the dots between human-centered design and business objectives. Focusing on alignment allowed me to talk with business leaders and stakeholders about the importance of Design in reaching their goals. Within a short time, I was running workshops with senior leaders and showing my diagrams to CEOs.

  In this chapter, I introduce the concept of alignment diagrams to describe a class of diagrams that visualize the circumstances of value exchange. By the end you should have a firm grasp of value alignment, the commonalities and key differences between diagram types, and the benefits of value alignment.

Alignment Diagrams

  The term alignment diagram refers to any map, diagram, or visualization that reveals both sides of value creation in a single overview. They are a category of diagram that illustrates the interaction between people and organizations. Such diagrams are already used in practice. They are not new. Thus my definition of


alignment diagram is less of a proposition for a specific technique than a recognition of

how existing approaches can be seen in a new, constructive way.

  Logically, alignment diagrams have two parts. On the one side, they illustrate aspects of the individual’s experience. This is a depiction of aggregate behavior across archetypal users. On the other, alignment diagrams reflect an organization’s offerings and processes. The points of interaction between the two are the means of value exchange. You may have already used them: service blueprints, customer journey maps, experience maps, and mental model diagrams are widespread examples. The following sections compare common types of alignment diagrams to reveal their similarities.

Figure 1.1 shows a simple customer journey map of a search service for finding architects internationally. This is a modified version of a diagram I created on a project a number of

  years ago, concealing the name of the product and company. It describes how a customer interacts with the provider of the search service from beginning to end. Phases of interaction are listed across the top, starting with “Become Aware” and going to “Renew/Upgrade.” The rows show various facets of the customer experience: actions, state of mind and feelings, desired outcomes, and pain points. The bottom half shows key departmental activities to support or respond to the customer. An analysis of strengths, weakness, opportunities, and threats appears below that. The primary means of interaction are listed in the row in the middle.

  Individuals   Interaction


  Figure 1.1: A customer journey map for a service for finding architects internationally

Figure 1.2 shows a service blueprint created by Brandon Schauer, a strategist and business analyst with Adaptive Path, a leading user experience design group. It depicts

  the experience of a conference attendee. The customer actions are indicated at the top and business processes at the bottom. In the middle Schauer indicated the “line of interaction" – the touchpoints where there is an exchange of value.

  Individual s Interactions  

  Organizati   Figure 1.2: An example of a service blueprint for conference going.

Figure 1.3 shows an example of an experience map created by Chris Risdon, also of

  Adaptive Path. This particular map is for a service called Rail Europe, and it shows the phases in a trip through Europe by train. It describes the experience people have when using the service in the top portion. At the bottom are opportunities for the business. The interactions between the two are embedded in the middle of the diagram.

  Interactions   Individual s   Organization   Figure 1.3: Experience map of Rail Europe created by Chris Risdon.

  Another type of alignment diagram is Indi Young’s “mental model" approach, detailed in her book of the same title. These are typically very large diagrams that when printed can cover an entire wall. The example in Figure 1.4 shows a close-up of mental model diagram for going to the movies.

  A horizontal line in the middle divides the diagram into two parts. The top shows individual customer tasks, feelings, and philosophies. These are grouped by topic into what are called towers, which are then sectioned off into goal spaces (e.g., “Choose Film” and “Learn More about a Film”). The boxes below the center line show support for achieving those goals from various products or services.

  Individuals Interaction


  Figure 1.4: Mental model diagrams seek to hierarchically align customer behavior with business support in two halves

  Unlike customer journey maps, service blueprints, or experience maps, the structure of mental model diagrams is hierarchical rather than chronological. The two-part arrangement qualifies it as an alignment diagram nonetheless.

Figure 1.5 shows an example of a spatial map. More specifically, this is a so-called isometric map created by Julia Moisand, a leading user experience designer. The three

  dimensional aspect of this example makes it unique from the previous examples. On the left are rectangles, called “carpets.” These reflect departments and divisions in a company. Individual “cards” shown in the middle represent different content types and artifacts used within the system described. And on the right are users of this content, with touchpoints between the two parts.

  Organization   Interactions  


  Figure 1.5: Spatial map created by Julia Moisand showing alignment of content system to users of that system (in French).

  As the name implies, spatial maps are neither chronological nor hierarchical. This distinguishes this type of diagram from the previous examples.

Value-Centered Design

  Creating solutions by focusing on the overlap between individuals and organizations represents a perspective referred to as value-centered design. In his article “Searching for the Center of Design” (Boxes and Arrows, 2003), service design expert Jess McMullin defines value-centered design as follows:

  Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction.

Table 1.1 summarizes each of the previous diagram type examples through this lens.

  Each diagram type tells the story of value-centered design in a different way, with different conventions and representations.


  Customer Journey Chronological Touchpoints Actions, thoughts, Roles and departments Map feelings, pain involved in creating an points, etc. experience

  Experience Map Chronological Touchpoints Actions, thoughts, Physical and social feelings, pain artifacts in a system; points opportunities

  Service Blueprints Chronological Line of interaction Actions, physical evidence Backstage actors and processes

  Mental Model Diagrams Hierarchical Center line Tasks, feelings, philosophies

  Support – products and services available Spatial Maps Spatial Midpoint with arrows Actions, needs, information flow Data systems, departments


Table 1.1: Different ways to diagram aspects of value-centered design

  The notion of alignment diagrams finds common ground between these examples. As the fields of customer experience, user experience, and service design become merged and see overlap in activity, it becomes increasingly important to have a range of approaches to solve situational problems.

Distinguishing Diagrams

  While I’m urging you to focus on value alignment, also recognize the differences between various diagram types. The point is that you can apply the approach that makes the most sense for your situation. Don’t rule out any one technique over another a priori. The three key distinguishing factors are relationship, viewpoint, and need. Relationship

  There are different relationships in a given value creation ecosystem. For instance, the relationship between a buyer and a service provider is different than the relationship between a producer and supplier to the producer. Ask yourself, which experiences in the overall value chain make the most sense to investigate and illustrate?

  Viewpoint Each relationship can be viewed from a different standpoint. Does the diagram represent the perspective of a single actor or multiple people, or is it if from the perspective of the organization? Also consider the scope and the focus of the diagram? When does the experience begin or end? What elements of the experience will you focus on – actions, emotional factors, or something else? These aspects all come together to provide a viewpoint for the diagram.

  Need There is no right or wrong way to illustrate experiences, only appropriate or not appropriate. What you illustrate depends on the need of the organization. Are you looking to manage the overall lifecycle of a brand, improve a specific face-to-face service encounter, or design a new software solution? The needs for these various objectives give rise to different diagram types. Admittedly, the differences between diagram types may not be immediately apparent. I will be discussing the differences between diagrams throughout the book. Chapter 2 deals with these fundamentals in more depth, and Chapter 3 provides detailed guidance on selecting a diagram type. Chapters 8-12 deal with the five primary diagram types, each in a separate chapter.

  Compounding the confusion is an inconsistent use of terminology in the field. You may find labels used interchangeably in the field. The terms most often conflated are customer


journey maps , experience maps, and service blueprints. These are all chronological maps,

  so the mix-up is understandable: they have a similar form and similar use. But there are distinctions between these commonly-used diagrams. See the following sidebar for more details.


What’s the Difference?

Customer Journey Maps, Experience Maps, and Service Blueprints

  A key difference is the perspective of that actor and the relationship of that actor to the organization. Customer journey maps typically view the individual as a customer of the organization. There is often a purchase decision involved. Service blueprints view how a service—usually a real-time encounter—is experienced by a customer. Both diagrams seek to show how the customer fits into the services provided by the organization. Experience maps on the other hand look at a broader context of human behavior. They reverse the relationship and show how organization fits into a person’s life. Breadth and depth vary for each as well, providing a different focus. Figure 1.6 shows a skeleton for a generic chronological map. The chevrons at the top show phases of interaction. The top half represents a description of the individual’s experience, and the bottom represents the service an organization provides. In the middle are touchpoints.


Figure 1.6: Depth and breadth differs across diagram types

  Customer journey maps tend to focus on the experiential side of the equation, with only a brief description of the service provision processes. Service blueprints focus on the backstage processes. An experience map focuses on the broad customer experience but could also include detailed descriptions of the organization’s actors and processes. Contrast examples of each shown in the following three figures to understand these differences.

  The diagram in Figure 1.7 is customer journey map. The rows in the center of this map clearly focuses on the positive and negative experiences of the individual as a customer of the organization. There is a decision point in the middle of the experience.


Figure 1.7: a customer journey map for a fictitious company, “Acme


  The next example (Figure 1.8) is an experience map for pregnancy. This was created by Beth Kyle, a Senior Technical Analyst at Cornerstone Information Systems, during her graduate work in Human Computer Interaction at Indiana University. It reduces the complexity of many facets of information into a single overview.

  The focus here is human experience, not on a particular company or business. There is no purchase decision or point of sale, to contrast it to a customer journey map. Nonetheless, an organization could use to learn how to provide better service, such as a doctor’s office or a pregnancy planning service. The organization in this as is not explicitly represented. It’s implied. As a result, multiple organizations could benefit from this diagram.

  Figure 1.8: A pregnancy experience map created by Beth Kyle

  Service blueprints tend to focus on shorter, real time interactions. They typically show more detail of the service provision mechanisms and lack depth in describing the person’s experience. Figure 1.10 shows an example from a 1 landmark article on service blueprinting by Mary Jo Bitner and colleagues.

  Service Innovation,” Working Paper, Center for Leadership Services, Arizona State University (2007)


Figure 1.9: Service blueprint for an overnight hotel stay, created by

Mary Jo Bitner and colleagues

  The above examples differ in use as well. Customer journey maps tend to be used by marketing, branding, and customer experiences professionals to manage the overall relationship with customers. Service blueprints are a mainstay of service design. And experience maps aid in the design of digital systems with many touchpoints.

  Principles of Alignment A common set of principles binds alignment diagrams together as a class of document.

  Understanding these opens up possibilities for attempting this kind of work: you’re not limited to one approach over another. And you may combine techniques to gain deeper insight as needed. Common principles of alignment are detailed below.

  Principle of Holism

  Alignment diagrams focus on human behavior as part of a larger ecosystem. They are not about product research (e.g., not about mapping out the workflow with a specific software program). As much as possible, look at what individuals do, think, and feel in a given context. Use people’s goals and desired outcomes as the main driving force for telling the alignment story. Show their pain points, constraints, and barriers for an impactful narrative. This will point to opportunities for innovation and growth.

  Principle of Multiplicity

  Alignment diagrams illustrate multiple facets of information simultaneously. This is what the

  “alignment” part of the technique is really all about. Common aspects on the user side include actions, thoughts, feelings, state of mind, goals, and pain points. There may be others depending on your situation. On the organization side, typical elements include processes, actions, objectives, and metrics, as well as actors or roles involved.

  Principle of Interaction

  Alignment diagrams expose touchpoints and the context of those touchpoints. The multiple layers of information come together to show an exchange of value. As a result, alignment diagrams prototype the human experience. It’s easy to walk through the touchpoints in slow motion, analyzing the broader circumstances around each interaction. You can diagnosis your own performance, asking,

  “How well do we support people throughout the experience?” More importantly ask, “Do our beliefs and values align with those of the individual?”

  Principle of Visualization

  Alignment diagrams show a composite view of behavior and processes in a graphical overview. It’s the immediacy of an all-at- once visualization that makes them powerful. A 10-page report or bulleted slides with the same information won’t have the same impact. Visualizations give organizations a much-needed view into their interaction with their customers. And they make otherwise abstract and invisible concepts like “user experience” tangible.

  Principle of Self Evidence

  Alignment diagrams typically need little or no explanation. Anyone can walk up to one and orient themselves relatively quickly. Keep in mind a visual format itself does not guarantee simplicity: you’ll still have to work hard to reduce information to just the most salient points and shape it into a cohesive story. It’s challenging to be concise, but self-evidence is more important than comprehensive detail.

   Principle of Relevance

  Alignment diagrams seek to address real-world issues and therefore must be relevant to the organization. As a creator of an alignment diagram, this means you must investigate and understand the goals, challenges, and future plans of the organization. The resulting diagram should fit into their thinking. In particular, strive to shed light on unknowns or questions faced by an organization. For instance, a business may be looking to strategically expand into new markets. An alignment diagram can help illustrate the types of interactions the business would have with this new segment. In turn, this insight might highlight additional capabilities they need to acquire and new services they need to provide.

  Principle of Validity

  Alignment diagrams are grounded in investigation, not made up in isolation. It is entirely possible to brainstorm a model of the user experience without ever looking at an external source of information. While this may an acceptable first step to generate hypotheses, it’s imperative to integrate hard evidence into the final diagrams to ensure validity. Even if a company already knows a lot about its customers’ behaviors, primary research will likely be part of your alignment diagram effort. It’s typical to find gaps in knowledge through alignment activities. More importantly, primary research deepens and strengthens the information included and the insights gained.

Benefits of Alignment Diagrams

  Alignment diagrams can have a broad set of uses that span projects, departments, and strategic efforts. Below are key ways to leverage them:

  Diagnosis. Alignment diagrams map current performance. They are a type of

  prototype for a person’s experience. As such, alignment diagram identify where interactions breakdown or where emotional intensity is highest. They also reveal redundancies and opportunities for streamlining services.

  Discovery. Alignment diagrams serve as a springboard into innovation. They

  provide insight into the human experience in a holistic way that inspires new solutions. They help teams arrive at new products, services, and experiences.

  Design. Maps aid in product and service design beyond mere improvements to

  existing offerings. They provide an architectural view of an intended experience, across channels, devices, and touchpoints.

  Development. Implementation efforts can be prioritized against a diagram for

  balanced planning. Alignment diagrams expose necessary cross-departmental communication, breaking down siloed thinking. Alignment diagrams are no panacea, for sure. Still, they have many potential benefits across these uses. These include building empathy, providing a common “big picture,” breaking silos, reducing complexity, and finding opportunities. Alignment diagrams also generally enjoy a great deal of longevity.

  Build empathy

  It’s amazing – sometimes even shocking – how little organizations know about the experiences the people they serve actually go through. Alignment diagrams shed an important source of light on real-world human conditions. In doing so they instill empathy into an organization. Bruce Temkin, a leader in customer experience management, stresses the relevance and importance of such mapping activities. He writes in a blog post:


…companies need to use tools and processes that reinforce an understanding of actual

customer needs. One of the key tools in this area is something called a customer journey

map… Used appropriately, these maps can shift a company’s perspective from inside-

2 2 out to outside-in.

  Bruce Tempkin. “It’s All About Your Customer’s Journey,” Customer Experience Matters (2010) Looking back into the organization from the outside causes a change in perspective, one that is invariably more sensitive to people’s thoughts and feelings. People form feelings around the products and services they come in contact with. To design offerings with an emotional appeal, we must first understand people in the context of use and form a sensitivity to their condition.

  Provide a common “big picture” Alignment diagrams allow teams to rally around a common purpose.

  They serve as a shared reference, helping to build consensus. In this sense, alignment diagrams are strategic tools: they influence decision making at all levels and lead to consistency in actions. But there is often a gap between strategy and execution. Some organizations may have a clear picture of what to do at the top management layers. And the teams at lower levels may be busy with implementation activities. If there’s a disconnect in the middle the resulting outcome won’t be successful.

  In her book The New How, business leader and author Nilofer Merchant calls this gap an

  air sandwich :

An Air Sandwich is, in effect, a strategy that has a clear vision and future direction on the

top layer, day-to-day action on the bottom, and virtually nothing in the middle–no meaty

key decisions that connect the two layers, no rich chewy center filling to align the new

direction with the new actions within the company.

  Alignment diagrams help deflate the air sandwich. They are a collective point of reference and encourage participation in strategy creation and comprehension. The alignment effect, then, is internal as well as external – getting teams on the same page. What’s more, alignment diagrams also help retain a common big picture over time. Teams may change. As members come and go, alignment diagrams help maintain continuity. In this sense, there is a knowledge management function role they also play.

   Break silos

  People experience a product or service in a holistic way. They don’t break it down into neat segments of thoughts or feelings that match a company’s org chart. Ideal solutions can easily cross an organization’s departmental lines.

  Alignment diagrams reveal divisional joints in an organization. Discussion around them frequently sparks cross-departmental collaboration. Alignment diagrams, then, are effective in driving change by orienting an organization to value creation and delivery from the individual’s perspective.

  The principles of alignment also aid in the design of cross channel experiences. Consider the cross-channel blueprint (Figure 1.10) created by Tyler Tate, entrepreneur and expert in search system design. While it doesn’t include the richness of other types of alignment diagrams, it does align user behavior (along the top of the chart) with channels (vertically on the left) and with support from the organization (the bottom row).


Figure 1.10: Cross-Channel Blueprint by Tyler Tate

  In this simple, yet insightful example, a product taxonomy spans across all channels. But in a typical organization, the print catalog department is likely different from the digital product team and from the physical store. In this case, the implementation of a cross- channel taxonomy requires these units to work directly with one another. Sounds easy, but in reality that may be a foreign concept with no precedent. Alternatively, an organization could also be structured by the user experience. Why not have a “Lookup and Explore” department that naturally works across all channels? Alignment diagrams can even provide the impetus for fundamental organizational change. They suggest a model for dividing teams by the user experience rather than by function.

   Reduce Complexity

  In survey of over 1500 global leaders conducted by IBM in 2010, complexity was cited as the most significant issue facing businesses today. The study shows that manmade business systems have reached an unprecedented scale and level of interconnectedness.

  Another study in 2011 by Booz and Company, a majority of the 1800 executives surveyed indicated they were unable to focus on business strategy: they are being pulled in too many directions. Conflicting priorities, competing business units, and an inability to find attractive markets are some of the top issues that contribute to this state. As a result, many companies lack coherence. Coherence in business strategy—or incoherence, as is often the case—is the subject of


The Essential Advantage by Paul Leinwand and Cesare Mainardi. After years of research

  in corporate strategy, the authors conclude:


To unlock the benefits of coherence, you need to take deliberate steps—to reconsider

your current strategy, overcome the conventional separation between your outward-

3 facing and inward-facing activities, and bring your organization into focus.

  Alignment diagrams represent such a deliberate step: they inherently match outward and inward-facing endeavors. In doing so, they bring a stronger sense of coherency to organizations.

   Reveal Opportunities

  Visualizations offer an immediacy of comprehension, providing insight into previously unnoticed value-creation opportunities. Indi Young describes this potential in a common response to her mental model diagrams from stakeholders:


I have invited executives to presentations 15 minutes earlier than other folks, so they can

stand in front of the diagram on the wall and walk from the left to right, asking me

questions as they go. As I answer their questions, I explain how it will be used to direct

product design. This kind of walkthrough is quick, to the point, and stays in the context

of “missed” and “future” opportunities that executives usually focus on. Many executives

have told me that they’re never before seen all this information collected so succinctly in

4 one place.

  While the diagrams themselves don’t give an immediate solution, their presentation to the team often has an ah-ha effect. They pinpoint areas for improvement in both operational efficiency and experience design, as well as expose opportunities for growth.

  Alignment diagrams enjoy Longevity

  Mapping an experience is a foundational activity. Once completed, alignment diagrams of tend not to change rapidly. Because they uncover fundamental human needs and emotions, the data are not particularly volatile.

  Some specific interactions or types of touchpoints may change with advances in technology. As a result, the information contained in alignment diagrams generally remains valid for years to come. The key is to set up the effort in a way most relevant to the organization and focus on the most appropriate elements. The next two chapters discuss how to do this in detail.

  3 4 Paul Leinwand & Cesare Mainardi. The Essential Advantage (Harvard Business Review Press, 2010) Indi Young. Mental Models (Rosenfeld Media, 2009)


  This chapter introduced the term alignment diagrams, a category of diagrams that visually align individuals’ experiences with an organization. It is an umbrella term for various, contemporary approaches. Thus, alignment diagrams are not a specific technique or method, rather a reframing of existing practices.

  Examples of alignment diagrams include customer journey maps, service blueprints, experience maps, mental model diagrams and spatial maps. By looking at the common principles of alignment found in this type of diagram, mapping takes on a more strategic function. There are many benefits to alignment diagrams: They build empathy, shifting an organization’s view from inside-out to outside-in.

  Alignment diagrams give teams a common big picture. Mapping experiences helps break organization silos. Visualization helps reduce complexity inherent in systems of interaction.

Alignment diagrams point to opportunities for improvement and innovation

  Alignment diagrams also enjoy substantial longevity. They are based on fundamental human needs and emotions. Once completed, they tend not to change rapidly. Alignment diagrams are foundational. They don’t provide answers or solutions directly, but facilitate conversation and stimulate deeper reflection. As complexity in business increases, such approaches are no longer nice-to-have: they are imperative to how an organization learns about the experiences it creates and the relationships it forms. But there are differences in diagram types as well. Three factors that distinguish one diagram from the next are the relationship that is illustrated, the viewpoint from the experience is depicted, and the needs and uses of the diagram by the organization. Focusing on alignment opens up possibilities. To benefit from the range of options within the category of alignment diagrams requires making choices: which experiences to map, what areas to focus on, and what diagram might work best. Chapter 2 and Chapter 3 provide practical guidance on the selections you’ll make when creating an alignment diagram.

Further Reading

  Jim Kalbach and Paul Kahn. “Locating Value with Alignment Diagrams,” Parsons


Journal of Information Mapping (April 2011); and Jim Kalbach, “Alignment Diagrams:

  Focusing the Business on Shared Value,” Boxes and Arrows (Sept 2011)


This pair of articles by the author are the first concrete writings on alignment diagrams as

defined in this book. They are based on a presentation given at the Euro Information

Architecture conference in Paris in 2010. This first was co-authored with Paul Kahn, who helped develop the concept of alignment diagrams greatly. Harley Manning & Kerry Bodine. Outside In: The Power of Putting Customers at the

  Center of Your Business (New Harvest, 2012)

This is an excellent, full-length book on the value of customer experience design for

businesses. “Customer experience is at the heart of everything you do—how you conduct

your business, the way your people behave when they interact with customers and each

other, the value you provide,” the authors write. Mapping is a key activity to gain insight

into the experience customers actually have with your organization.

  Jess McMullin. “Searching for the Center of Design,” Boxes and Arrows (Sept 2003)


In this article, McMullin calls for us to think beyond user-centered design and embrace

value-centered design. This principle underlies the basic notion of alignment diagrams.

  Andy Polaine, Lavrans Løvlie & Ben Reason. Service Design (Rosenfeld Media, 2013)


This book provides an excellent overview of the field of service design, with hands-on

tools and tips for practitioners. Chapter 5 discusses service blueprints in some detail and

positions them as a key activity is the service design process.

  Diagram Credits Figure 1.1: Customer journey map created using MS Excel by Jim Kalbach, modified from its original form

Figure 1.2: Brandon Schauer, “Service Blueprint for Seeing Tomorrow’s Panel Services,” retrieved from flickr

(CC Share-Alike 3.0)

Figure 1.3: Experience map for Rail Europe taken from: Chris Risdon. “The Anatomy of an Experience Map”

Adaptive Path Blog (2001), used with permission Figure 1.4: Isometric map created by Julia Moisand, originally appearing in: Paul Kahn & Julia Moisand.

  “Patterns that Connect: the Value of Mapping Complex Data Networks,” Information Design Journal (2009)

Figure 1.5: Section of a mental model diagram created by Indi Young and included in her book Mental Models

(Rosenfeld Media, 2008), used with permission Figure 1.7: Customer journey map created by Macadamian (, used with permission Figure 1.8: Experience map created by Beth Kyle, a Senior Technical Analyst at Cornerstone Information

Systems, during her graduate work in Human Computer Interaction at Indiana University, used with permission

Figure 1.9: Service blueprint created by Mary Jo Bitner and colleagues, originally appearing in: Bitner, Mary Jo, Amy L. Ostrom & Felicia N. Morgan. “Service Blueprinting: A Practical Technique for Service Innovation,” Working Paper, Center for Leadership Services, Arizona State University (2007) Figure 1.10: Cross channel blueprint by Tyler Tate, taken from “Cross-channel Blueprints: a modern tool for

  IA.” (CC Share-Alike 3.0)


Chapter 1: What is a Design Sprint? A Design Sprint is a flexible product design framework that serves to maximize the

  chances of making something people want. It is an intense effort conducted by a small team where the results will set the direction for a product or service. A Design Sprint consists of five discrete phases:

  0. Prepare (Get ready)

  1. Understand (Review background and user insights)

  2. Diverge (Brainstorm what’s possible)

  3. Converge (Rank solutions, pick one)

  4. Prototype (Create a Minimum Viable Concept)

  5. Test (Validate with users)


6. another Design Sprint, or a Lean and Agile build process such as

Scrum or Continuous Delivery / Extreme Programming.

A Design Sprint reduces the risk of downstream mistakes and generates vision-led goals

the team can use to measure their success. For the purpose of this book, we’ll focus on

digital products since our direct experience lies in that arena, though the Design Sprint

  1 has roots in gaming and architecture , and many industries have employed them successfully.

Uses of a Design Sprint

  At the beginning of a project, you might use a Design Sprint to initiate a change in process or start the innovation of a product concept. This works well when you’re

exploring opportunities with the goal of coming up with original concepts that ultimately

will be tested in the real world. For example, if we need to understand how young parents would buy health care products online.

In the middle of a project, you might use a Design Sprint to start a new cycle of updates,

expanding on an existing concept or exploring new ways to use an existing product. One

such example that we worked with was a marketing data company that realized that the

data they gathered might be useful to other market segments. Building a prototype gave

them the validation they needed and prompted a deeper investment into that product segment, which ultimately was rewarded with a significant increase in sales.

  For a mature project, the Design Sprint can also be used to test a single feature or

subcomponent of a product. This allows you to focus in on an aspect of the design. For

example, your team might need to know what improvements can be made to the onboarding process. Using the Design Sprint to discover the pros and cons of a new

onboarding channel could give you granular insights into a high return part of the product


  However you use it, the Design Sprint brings clarity to your roadmap to kickstart and obtain initial validation for almost any new product design related work.

How the Design Sprint Came to Be


The word ‘sprint’ comes from the world of Agile, and it describes a short period of time,

typically 1-4 weeks, set aside to accomplish a focused goal. The Design Sprint is no

different. It uses the original concept of the sprint to describe a period of time dedicated

to working on the necessary design thinking. This time-bounded paradigm is critical to

the success of the Design Sprint. ‘Timeboxing’, as it’s sometimes called, is essential to

driving the right types of behavior from the participants. It’s not just important in speeding

up the product design and development process, it takes advantage of core parts of our

human nature - energy economy and social collaboration.

  Going way back, the term charrette was used to describe any collaborative workshop session amongst designers and design thinking frameworks from Stanford's emerged as a way to apply more structure to this concept. Industrial product design

firms like IDEO developed short cycle design sessions called Deep Dives, which built on

  IDEO’s most famous example is the Shopping Cart deep dive, which appeared on

  gets done and brought a multidisciplinary team together to brainstorm, research,

prototype, and obtain user feedback that went from idea to a working model in four days.

By collapsing the time constraints, these designers were essentially holding a gun to their heads and forcing themselves to come up with better solutions in less time.

  The influence of industrial design and software design was the genesis, but it was the

emergence of digital product design that brought on a more formal framework for testing

ideas out in the wild. Several organizations started to converge upon similar processes with similarly named phases:

Although there have been company specific versions of this approach used over the last

decade, it was the work of Jake Knapp at Google Ventures (GV) that brought them to a

broader audience.

GV invests in startups, and at times those startups would need product design advice to

align their teams. To help with this, GV would send a designer for a week to the startup.

As it turns out, these processes have five phases, one for each day of that week. The

structure and time constraint proved useful. Lo and behold, the Design Sprint was born.

  Created for Startups, Useful for Enterprises Startups are notoriously fast-moving environments that value speed to market over almost everything else. This commitment to speed gives them an advantage but also

risks leaving out a lot of the essential thinking and testing required to build a truly useful

product. Too many products go to market without customer validation. How do you maintain the speed while including the necessary research and design thinking? Many startups in the Constant Contact InnoLoft Program cite a Design Sprint as one of the most valuable parts of their participation.


Enterprises that have well-established processes may also look to a Design Sprint as a

way to accelerate their product design and development so that they can work more like

a fast-moving startup. The accelerated learning can give the enterprise an advantage

and also reduce the amount of resource investments for exploration of product ideas and

concepts. Spending three to five days on a project idea to see if it makes sense to move

forward is better than working three to five months then finding it would be better to not have proceeded at all. Any product or product feature will be validated or invalidated. You can do that validation, or let the market do it. Which do you think will be less expensive?

Success = Time and Money Saved + Minds Blown

  You can’t change what you can’t measure, right? One of the biggest questions we

initially faced when implementing Design Sprints in our organizations was “How do you

measure the success of a Design Sprint?” Our experience was we had a few things we

would measure, and often it was the absence of something that we were measuring. For example how do you measure the amount of time you won’t spend on bad product development? How much money will you save by not investing in a product that will make less ROI? Those questions point towards future gains by not spending some difficult-to-calculate amount of time or money. How do you measure the absence of a failed product? “There's no way you're not going to save yourself time and money. Because the way

these deals usually work is to go out and build things and just invest thousands of dollars and all this time, and then, find out that it falls flat. There is no testing done, no exploration done with end users,” remarked Dana Mitrof-Silvers, a design thinking consultant who works with many non-profits, such as the Indianapolis Museum of Art

and the Denver Museum of Nature and Science. She measures the success of a Design Sprint by the ideas generated. “While ideas aren’t usually the problem, most

organizations find themselves with an excess of ideas, validated ideas and the execution is what’s missing.”

In many cases, a Design Sprint will lead you to something that gets initial user validation, where the next steps are defined. You’ll have reduced risk by doing some validation diverse Stakeholders from an educational nonprofit got on the same page about what

would be built, and remarked upon how quickly they reached agreement. Teachers and

students were excited about the prototype they saw and couldn’t wait to use it. What we

needed to build was clear and could proceed unimpeded at a good clip, which was very

much needed given the size of the app and a shoestring nonprofit budget.

Sometimes issues come to light that need some clear changes in your product, and you

can fix those things and plan additional research. For example, thoughtbot did a Design


attached. In the Sprint we found that making the device beep louder helped people find

keys 3 times faster than with anything we could do to the app. We iterated based on all

the learnings and continued additional research sessions in the following weeks. Design Sprints can help prevent you from building the wrong thing even when your customers say it’s the right thing. Larissa Levine from the Advisory Board Company suggested a Design Sprint is successful if it guides you towards building the right product feature. She explained, “Product marketing wants to sell this one feature and says, ‘let's build XYZ because we heard that the user said they wanted XYZ,’ when actually, that's not the problem at all. They think they want XYZ, but it's not it at all. So you end up building the wrong thing.” Sometimes a Design sprint can get rid of those preconceived notions. Michael Brooke,

co-founder of InnoLoft startup resident itsgr82bme, entered a Design Sprint with a clear

idea in his head about using APIs as a means for connecting their family events

calendar with other sites’ event listings. During the sprint, he realized this could be done

without using any APIs at all. He ended the sprint in a very different place.


Lastly, a Design Sprint can stop you from building any product at all. Marc Guy, CEO of

FAZE-1, also went through a Design Sprint at the InnoLoft. The sprint made him realize

his company needed to stop building a product and instead go out and talk to customers.

Product invalidated! Their business has shifted significantly as they then focused on the

customer development. In fact, C.Todd didn’t see Marc or his team in the InnoLoft much

after their design sprint. They were all out talking to customers, even their development

team! Each Design Sprint will have its own needs and idiosyncrasies and you'll have to

determine up-front what’s best for your project. Any good design thinking process might

help identify the real problem in each of these cases. What makes the Design Sprint approach more effective is the structured, time-constrained framework with the right

exercises. This will force the team to make decisions and validate ideas faster than most



  Takeaways: ● A Design Sprint has 5 phases: Understand, Diverge, Converge, Prototype, and

Test. The names of these phases may vary from company to company, but the overall ethos remains the same: A time-boxed design cycle completed in a collaborative fashion with real user input. ● The focus of a Design Sprint is to get the validation needed to maximize the chances of creating something people want. ● The process is very flexible and can adapt to different teams and needs.

● They can be measured in different ways, from number of “good” ideas generated, team alignment, company direction, and even halting a project. elease


  Early R & U RAW

  Tragic Design

  Jonathan Shariat

How Bad UX Killed Jenny I love people

  I love technology and I love design, and I love the power they have to help people.

  That is why when I learned they had cost a young girl her life, it hurt me deeply and I couldn’t stop thinking about it for weeks.

  My wife, a nursing student, was sharing with her teacher how passionate I am

about technology in healthcare. Her teacher rebutted, saying she thought we needed less

technology in healthcare and shared a story that caused her to feel so strongly that way.


This is the story that inspired me to write this book and I would like to share it with you.

  Jenny, as we will call her to protect the patient's identity, was a young girl who was

diagnosed with cancer. She was in and out of the hospital for a number of years and was

finally discharged. A while later she relapsed and returned to be given a very strong chemo treating medicine. This medicine is so strong and so toxic that it requires pre-

hydration and post-hydration for three days with I.V. fluid. However, after the medicine

was administered, the nurses who were attending to the charting software, entering in everything required of them and making the appropriate orders, missed a very critical piece of information. Jenny was supposed to be given three days of I.V. hydration post


When the morning nurse came in the next day, they saw that Jenny had died of toxicity

and dehydration. All because these very seasoned nurses, were preoccupied trying to figure out this interface (figure 1-1).

  Figure 1-1 This is the software that was used at the hospital for many years.

  When I heard this my heart sank and when I looked up screenshots online of the tool

they used (which my wife who worked at the same hospital confirmed still looked that

way) I was furious! How could such a critical service in our lives be employing such terrible software? Now, some would argue that the fault lies with the nurses, I would


So let’s stop and ask ourselves some very important questions, ones that don’t get asked

enough in Silicon Valley where I’m from: “What is the purpose of technology?” “Why is design important?” “How will what we are making, and how we make it, affect the world?”

I’ve been designing interfaces for almost a decade now. Like many of my peers, I started

hobbling together websites and photoshopping posters until I found my way to

designing interfaces and delving into User Experience Design. All the while the industry

has exploded and design has matured into the leading differentiator. I admit, I too have

gotten caught up in these billion dollar exits and the glamor of tech. I started out wanting to make the world a better place, but I soon found myself blindly building

technology that was chasing dollars and not outcomes for real people, not just “users”.

  “What is the purpose of technology?”

This is such an important question everyone involved in building technology

should seriously ask themselves, ponder, and write down their own answer to. Frankly,

  I’m embarrassed that it has taken me this long to answer it for myself, because I know

that if you want to be great at something, you have to fundamentally know its purpose.


Many of the great designers, engineers, and entrepreneurs who we look up to have done

this at some point on their journey, and you should too, but let me give you my own definition and to be completely transparent, my failed attempts as well.

  The purpose of technology is to extend what is possible. (Just because something is possible, doesn’t mean it’s something we should do.)

The purpose of technology is to benefit humanity.(Close, but it doesn’t always have to be

so serious, technology can just be fun) The purpose of technology is to increase the quality of life. (For who? Sometimes we must sacrifice an increase for us, if it hurts someone else) The purpose of technology is to serve our needs, for the benefit of all.

  That is the definition I was most happy with, the one I felt encapsulated all the

important parts of design that are relevant to me. Technology should serve needs, big or

small. It should do it in an inclusive and constructive way that benefits everyone.

  “Why is Design Important?” So how does design fit into technology? Design, as Jared Spool so succinctly put it is “the rendering of intent.” While that is a very correct, logical and succinct way of

boiling it down, I feel it misses one important element: People. Of course there are cases

where something can be “designed” that has nothing to do with people but I would argue that it falls closer to “engineering” but alas that is the frustrating obstacle of language. I would define design, especially in the sense of designing products and

software, as “the planning of technology’s relationship and interaction with people” The

definition of design simply has to include people. Bad designs are always the ones that

collide with human behaviours, therefore good designs are the ones that are transparent

and helpful. When we create things with out the end user in mind, or with some vague

sense of them as a customer, we almost always end up creating a bad design. I like to call


this book will convey, produces real harm to the people who experience it. Good design

attempts to understand the intended user, and create an experience that serves their

needs. A good design is worthwhile one. One whose existence isn’t a burden on its users

but instead makes their life better in some way. However good design isn’t just a bunch

of goodwill and pleasant feelings, it’s good business too. Designing well creates

worthwhile experiences, and that sells. If your product serves you and your competitor’s

product serves the customer, then the customers going to use the one that was made for

them first. In today's technology landscape it’s easier than ever for competitors to match

features and scale up to millions of users. Thus, user-centered design, because of it’s accessible nature, will become the main differentiator.

  Technology meant to be used by people but created without their needs first is not moving forward, its moving back. Design is important for this reason: It is the

bridge between what we want technology to do and having it benefit everyone. It acts as

the interface between technology and the people it’s supposed to be benefiting. When that bridge isn’t there, the opposite happens, and it’s destructive. It sets technology back, it sets us all back.

  “How will what we are making, and how we make it, affect the world?” So often those of us passionate about technology get caught up in the science and exploration of it. We gawk over what is possible with it and rarely stop to think about the “why” of it. We who dream and create are the gatekeepers of the imaginary world

into reality. We are responsible for what we bring into this world. In the same way that a

parent is responsible for their child. Yet, we often create at a whim, chasing the next

  Asking this question reveals if you have any effect at all! Furthermore, how we create that thing is also highly important. We must ask ourselves: is our success coming at a

hidden cost? For some companies that might be the environment, for many though that

cost is their own employees’ well beings. In a company, employees should come before customers. Because you can't please a customer with unhappy and uninspired

employees. It’s like trying to paddle up river with a whisk, your employees are your tools

to making things happen and are worth caring for.

  Now that we have answered those three important questions, let’s take a fresh look at Jenny’s story with this added context. What were the factors that lead to her death? What was the purpose of technology in Jenny’s story? How was design important? How did the software, and how it was made, affect her life?

  Healthcare right now is facing a crisis. In 1999 a landmark report concluded that 44,000 to 98,000 people a year die from medical errors at a cost of 17-29 Billion per

year. A more recent study done in 2014 puts the estimates of 100,000-400,000 deaths

per year. Like the recent study says: “In a sense, it does not matter whether the deaths of

100,000, 200,000 or 400,000 Americans each year are associated with PAE [Preventable Adverse Effects] in hospitals. Any of these estimates demand assertive action”.

  Jenny’s story is, unfortunately, not uncommon. When we blame the nurses we miss the entire context that leads up to that grave mistake. In nursing they call it the “swiss cheese model.”(source) There are multiple layers before a mistake can get

through to affecting the patient. For example when there is a medication error, an error


giving it, and the mechanism. Each layer will have its own holes but together they make

the chances of the error happening very rare. Nurses are the last line of defense in that chain and so it’s easy to blame them for many of the mistakes that can happen. In the

case of Jenny, the software was taking up their cognitive capacity which was loaded with

having to figure out how to use the interface to chart the patients care and make the

appropriate orders. The nurses weren't negligent, they were human. They were working

in an environment that was working against them. Try to imagine if you were required

to play a difficult game on your phone while you drove? How many mistakes would you

make over the course of a year? Up to 400,000 people die from medical errors a year.

  Blaming the nurses is to completely miss the root cause. The system is broken and design should be the way forward in repairing it. Technology in healthcare should be used as a tool to ensure mistakes don’t happen. In the case of Jenny it was a factor in the cause of a tragic error.

  That’s the crux of it all. Design is the interface between people and technology. Without good design, the technology is turned from a help to a harm. It can cause

physical harm, like in the case of Jenny. It can cause emotional harm, like when a social app facilitates bullying. It can cause exclusion, like when a seeing impaired person doesn’t get to participate on a popular website because simple accessibility items have not been attended to. Lastly, it can cause injustice, yes injustice, which all of these can

be categorized under, but direct injustices like nullifying someone’s vote or someone in

need who isn’t able to access help to get back on their feet. The scary thing is that right

now, our world is full of bad design and it’s costing us dearly. It’s costing us lives, time, money, joy, and justice. It’s scary because I never thought design would play such an with proper access, interaction, and use of technology so it serves their needs and doesn’t work against them.

  In the following chapters we will dig deep into specific stories of how bad design interferes with people's lives in very real ways. We will explore extreme examples, as

well as more common ones that will surely affect you in your career. While this book will

be filled with practical advice about how we can tackle these difficult issues, my main goal is to shed light on these areas, to illuminate your mind to how bad design affects peoples lives. That’s the most important step to solving any big problem in life, illuminating it. Once we have the bigger picture, we will talk about how we can fix it, designers, makers, all of us. Together.

Chapter 2 Great Designers are Great Communicators


“Words: so innocent and powerless as they are standing in a dictionary, how potent for good

and evil they become in the hands of one who knows how to combine them.”

  • - Nathaniel Hawthorne

    Trying to navigate this new reality that designers are at the forefront of the digital product business can be a real challenge. We creative thinkers are now thrust into the middle of a process with business people, expected to be the experts on design, and then asked to tell

    everyone else what we think should be done. Like a fish out of water, we struggle to breathe.

    In order to make this mental shift and be effective in our new role, it’s critical that we understand just how important good communication is to design.

Too Many Chiefs in the Kitchen


Designing in this new reality called UX would all go really well if it weren’t for the fact that other people on the project might disagree with our decisions. Actually, they will!

There are now a lot of people who may know little or nothing about design, yet who have the authority to oversee and dictate our design practice. They have a vested interest in participating in the conversation but they aren’t trained designers and they don’t have the same depth of knowledge in design or technology that we do. What used to be a somewhat obscured conversation between graphic artists is now open and available to many other players in the business. Quite simply, there are too many cooks in the tribe and too many chiefs in the kitchen. bizarre parts of our relationship with stakeholders. People who have influence over our project readily admit they are not good at our jobs, yet insist on making changes that we believe will be detrimental to the user experience. They say that they trust us and yet frequently overrule us. It can be incredibly demeaning and confusing, but the problem may not lie entirely with them. These stakeholders have to be part of our process, but we struggle with including them in a way that’s helpful and doesn’t derail our objectives. This is what we have to figure out.

Everyone is a Designer!

  Everyone knows good design when they see it, even if they don’t know how to create it

themselves. That sounds frustrating (even ridiculous), but it’s actually true. The same can be

said for other arts, like music. I may not know how to play an instrument, but I can recognize a pleasing tune. I can decide what music I like (and don’t like), even if I can’t tell you how to create it yourself. While there may be different preferences, we’re all able to choose music we want to listen to whether we know how to reproduce those sounds ourselves or not. The phenomenon that a non-expert can have an opinion about your design work is something that is almost entirely unique to design within today’s organizations. Accounting

practices are fairly standard and few people would complain about how money is tracked as

long as it is being tracked. That is, unless it ever affects them personally, like with their

paychecks: the way they’re paid or the details on their pay-stub. In accounting, the paycheck

is the user interface for most people in the organization. When it comes to accounting, no one

cares unless it affects their pay.

The same could be said for development. No one looks at the code except the developers. No

one cares what the programmers are doing to build it, unless it actually affects them. What if

the service is so slow that the thing (network, website, or computer) is rendered unusable?


accomplish that are obscured to the end user. The only part we “see” is the speed. That is the

main interface for development.

The Interface is Your Interface


Similarly with design, people only care about the part that affects them. They care about the

interface. But when you’re in the business of doing nothing but creating the user interface,

then everyone is going to care about everything that you do! All of your work is exposed so it

naturally conjures more opinions and ideas than many other areas in the organization. More

than that, your work is now becoming the interface of the entire company like never before.

So the people who run the business have strong opinions about how your work reflects on

them. Few people will tell you how to create those interfaces. The process or tools you use to

create the designs are obscured to them. But unlike accounting or development, the vast majority of your work is exposed to every stakeholder you meet with.

  It’s a strange feeling: what could be more rewarding than to know that our work and

expertise is so highly valued that so many people want to be a part of it? Design is being held

up on a pedestal! Finally getting the recognition it deserves! We knew that we could solve for real business problems and make a dent in the world. It’s what we’ve always wanted, right? Be careful what you wish for! If we want our work to be the center of attention, we

must also take responsibility for showing people how and why our work is valued. That part

doesn’t come automatically. It takes work, it takes practice, but more importantly… it takes good communication.

  1 There is no U or X in Team Collaboration seems like it should be the pinnacle of great design work: different opinions coming together to form the best possible solution. That’s the thing everyone really wants.

The image is of a handful of respectful intellectuals passionately debating the right solutions

that ultimately leads to a collaborative discussion yielding an ideal design that no one could

have thought of on their own. Teamwork at its best! Everyone leaves satisfied, fulfilled, and

respected - ready to take on the next design challenge. The problem is that this is never how

it goes.

We think we want that kind of collaboration, but it all falls apart when we disagree with each

other. When we disagree, we get defensive. When we get defensive, we fail to focus on the real issues. The meeting ends, not with collaboration, but with grumbling compromise and, often, a crippled user experience.

  In situations like this, meetings can easily turn into design-by-committee. Everyone has a suggestion for how to solve a problem. We hear different opinions on every side and are unable to defend our own choices against this barrage of feedback. One suggestion evolves into an idea for something else. That spurns a thought about something different, and the conversation can spiral out of control into a hodge podge of well-intentioned tweaks that collectively spell doom for the overall goals of the project. The thing we came together to accomplish has been muddied by group think and mob mentality. Remember, teamwork always ends with work.

The CEO Button Because of this, we see things like the CEO button

  The CEO button is an unusual or otherwise unexpected request from an executive to

add a feature that completely destroys the balance of a project and undermines the

very purpose of a designer’s existence.

It’s funny because it’s true. You might spend weeks or months building the best possible app.

Your team has poured in all the best practices that you learned at that one conference. You’ve done usability testing to prove it works. Your mom was even able to use it without

incident! And yet one executive can come in and blow up the whole thing. We want to avoid


Homepage Syndrome Another common problem is the homepage syndrome

  The homepage syndrome is a condition whereby the home screen of an application or website becomes a catch-all for everything, creating a garage-sale of links, buttons, and banner ads that unravels the fabric of usability, causing designers to cry themselves to sleep.

  You see, sometimes no matter how hard we try, the homepage just becomes a huge mess.

Everyone wants their business unit represented on the homepage. It’s as if something doesn’t

exist if it isn’t on the homepage! That new thing we’re launching? Put it on the homepage.

  That other thing that isn’t performing well? Maybe if we put it on the homepage it will get better! Sound familiar? We have to learn to deal with this phenomenon.

Communication Matters


The good news is that it doesn’t have to be this way. It’s possible to avoid the disruption and

compromise that happens so frequently in organizational design through better

communication with our stakeholders. I’ve found that the majority of issues or concerns that

our stakeholders bring to our attention are often just a matter of misunderstanding or

miscommunication. The way that we talk to them about our designs is the key to making sure

that we always end up with the best possible user experience.


It makes sense when you think about it. All human relationships are really nothing more than

a series of bound up understandings and misunderstandings. We don’t always have control over how other people understand us in the beginning. Everyone brings their past experiences into conversations with us on a daily basis. We do, however, have control over

how we communicate with them in order to influence those future understandings. The way

that we talk to people and the things that we say can change their mind.

Words are Powerful

  This makes our words really powerful. Throughout human history, words have had

significant power to change people, circumstances, and entire systems of government. Words

can spark wars, end relationships, and damage emotions. Conversely, words can also be used

to build people up, change minds, and reinforce positive connections. Saying something out loud can make it real. So real, in fact, that you can make things happen simply by talking about them.


Our words have a profound effect on the people around us. As a parent, I have to be careful


grow up to believe whether or not what I say is true. If I am constantly berating my kids over

their behavior, they will believe bad behavior is just part of who they are. If I tell my kids

they’re stupid, they could grow up believing that they shouldn’t even try to learn. The things

I say to my kids will shape their understanding of themselves and their perception of world around them. You might think it’s just impressionable children who don’t know better, but all people are just as easily impacted by our words. In life, there are no adults, only more experienced children.

For decades, eyewitness testimony has been called into question because of how easily it can

be influenced. Police have to be careful about what they say because a witness’s perception of what happened is so greatly influenced by what they hear. Witness memory can actually be changed by the way they are questioned. It’s well documented that memories can be

  2 altered under interrogation by police. The truth is not necessarily what actually happened,

but what we think happened. We can use words not only to express ourselves and make our

opinions known, but also to speak into the reality of other people. Our words can actually alter people’s perception of the situation.

Good Communicators Win

  Overall, being a better communicator will give you more opportunities. I’m amazed (and

offended) at the number of designers who apply for a job yet lack basic communication skills.

People will send me a resume without explanation, forget about interviews, or fail to follow

instructions. Ultimately, I’m only going to pursue candidates who can communicate well and

so the poor communicators get passed over very quickly.

It is common for my clients to express that one reason they hired me was because it’s so hard

to find people who are reliable and can communicate effectively. I’ve heard many stories about former contractors who simply couldn’t pull it together enough to set expectations, follow instructions, or clearly articulate their work. The need to work with other people on


from other designers. When one of my clients went on vacation, he asked me to help run his

business while he was gone because he knew he could trust me to represent him well. A contractor with good communication skills was more trusted than his own employees! I get more work simply because I can communicate effectively.

  If you’ve ever hired an overseas contractor, then you know how difficult it is to find quality

people. They can be really inexpensive, but it’s questionable whether the cost savings justifies

itself when it comes to quality and communication. The biggest barrier is usually communication. I have to spend an inordinate amount of time writing everything down, detailing requirements, and going over it with them multiple times before they finally understand what they need to do. The mistakes are almost always the result of a

miscommunication. It’s not that they’re unintelligent, it’s that there’s a gap in communication.

It’s much easier to have a miscommunication when you don’t speak the same language. But even in this situation, the overseas contractors with better communication skills (and better

English-language proficiency) are far more likely to be chosen for work for the simple matter

that they will be easier to work with because of their communication skills.

  No matter what sort of design work you’re looking for, it will be easier if you’re a good communicator. Strangely enough, being a good communicator may be all it takes to set

yourself apart from other designers. Even a designer who might be more artistically talented

than you. Very simply: good communicators win.

Being Articulate Means Success

  It’s more than just communication, we have to turn those words into something that will enact change or compel people to agree with us. It’s not just about using words with a frequency or persistence, it’s about using them in a way that is compelling and convincing.

  Being articulate can make you successful in any area of life. It can help you get almost

anything you want: a job, a spouse, or a bargain. It is the ability to use your words, tone, and

approach with people to communicate a specific message and elicit a specific response. The

key to being articulate is to understand both the message you want to communicate and the

response you want in return. If you can learn to craft your messages in such a way that they

yield the desired response, you’ll find that you’re much more successful at getting the things

that matter to you. The same ideas can be applied in your design practice.

The Best Ideas [Don’t Always] Win


In general, designers are pretty terrible at explaining themselves to non-designers, yet when

people disagree the most articulate person usually wins. It’s too altruistic to believe that the

best ideas are the ones that always win. They should, perhaps, but the reality is far from that.

The best ideas get stuffed into an amalgamation of meetings where competing needs vie for attention. The person who can convince the other they’re right is the one who gets his way.

Your design might be revolutionary, but an aggressive and well-spoken salesperson is more

likely to get his way if he can convince your boss that he’s right and you’re not.

  Designers lacking the ability to convince people why they did what they did end up on the

losing side of the argument, forced to make changes they disagree with simply because they

were unable to fend them off. This is not to say that the stakeholder relationship is adversarial. No, these discussions can feel very much like good, solid teamwork. But our inability to speak up and articulate your side will often land us in in the position of making changes that won’t yield the best results.

  Alternately, being articulate about our designs:

  • Imparts intelligence - you’re smart, you know what you’re talking about, you have

    expertise in this area, and you can be trusted with the solution.
  • Expresses confidence - you know what you want and how to get it done. Having a

    solid argument shows that you’re not wishy-washy and you mean what you say.

  • Shows respect - you value everyone’s opinions and time enough that you’re well- prepared. You’re not wasting time or disregarding others.

  The way to be articulate about design is to offer a message that communicates why we did what we did in order to help stakeholders see our reasoning. We build trust with stakeholders by showing our expertise through logic and reason, not feelings and intuition.

So we need to harness the power of communication, be articulate, and use these skills to help

people see that our UX decisions provide the best possible solution. Being articulate will help

us be successful.

Becoming a Great Designer

  To hone in on the best practices for articulating design decisions, let’s look at what makes a

design project successful because that will form the basis for how we communicate about it.

In order to overcome these obstacles, we have to boil UX down to its very core. We have to

understand the fundamentals of what makes a great experience and how we can reproduce that thinking and approach in others.

Focus on the Product, not the Process


Many teams are into the latest methodology: Waterfall, Agile, Lean. Whatever your flavor of

project management or product development, don’t let the details of process get in the way of being truly creative and making sure your ideas get to market. While these approaches can be incredibly useful for keeping projects on track and creating great results, we can get bogged down in the details of execution and less focused on what we’re trying to achieve. This carries over into our meetings with stakeholders who may have no idea about the ability to understand our decisions. Let’s not burden them with a sub-culture that is unfamiliar. (Scrum master, anyone?) The truth is, it’s irrelevant to the discussion of the designs. We need to think about our work differently in order to talk about it more effectively.

The Big Three


Let’s return to the question that I ask every designer that I interview for a job: What makes

a good design good? We could debate the answer to this question in many different contexts

or even consider the merit of the question itself. However, when it comes to creating the user

experience for a web or mobile application a design is really only good when it solves a

problem. Usually, we are trying to solve problems both for the business and for the user. So

it’s important to not only solve problems, but if we’re truly practicing a user-centered design

approach then we must also make our apps super easy for our users. Those two things together (solving a problem and making it easy for users) will help us create truly great experiences with our designs. This is what makes a good design good.


However, the one thing that we often forget is that there are other people involved who have

influence over our project. It’s not enough to simply create an incredible app, we also have to

get the support of everyone else on our team. Without their support, our project can’t see the

light of day. The difference between a good designer and a great designer is in their ability to

not only solve the problem but also to articulate how their design solves it. If you can do that,

you’re a great designer.

So there are three things that every UX project (or design) needs to be successful:

  1. It solves a problem

  2. It’s easy for users

  3. It’s supported by everyone These are the basics of creating a great user experience that the average person (like your stakeholders) can understand. Projects that fail are usually lacking in one of these areas. If you can do all three of these, your project will be a success. Let’s look at each one in more detail.

Solve the Problem

  Designers involved in the practice of creating a user experience are already accustomed to solving problems. This tends to be the most obvious. Of all the things we’re trying to accomplish with our work, this is the most explicit. We have become very good at solving problems: business goals, engagement, conversion, frequency, feedback. Whatever the problem is, our job is to find a solution and measure its success. How will we know we’ve done our job? By looking at the results before and after, tracking some specific metric, and watching it improve.

Hopefully you and your team have already established these goals, metrics, or KPIs for your project. If not, I recommend doing them yourself so you have a measuring stick to use in all your conversations. Projects without goals will surely languish because there is no way to

convince someone else that you’re right if you have nothing by which to measure its success. It just becomes a matter of opinions and subjectivity will make it difficult to move forward.

So if your team isn’t set up to establish these in the beginning, do it now for your own sanity.

Find out what the most important factors are for your stakeholders: impressions, conversion,

account sign ups… pick one or two measurable issues that you’d like to improve and write it down. Set this as your goal and use it to your advantage when talking to other people. While we’re certainly adept at approaching these problems to find creative solutions, we’re not always in tune with our own thought process to help other people understand why we for us to see a solution without having to give it much thought. In fact, this is what sets us apart from non-designers: our ability to intuitively solve problems with little more than a sense for what ‘feels right.’ The hard part, though, is figuring out what drives that intuition. What makes this ‘feel right’ so that we can help other people see our perspective? So the

practice of solving problems with design must also be accompanied by an awareness that will

help us explain our decisions to other people.

Let’s take a step back to the first time you design a UI control or element for your app. You

need to make yourself consciously aware of every decision you’re making and why. You need

to be constantly asking yourself: What problem am I trying to solve with this? Chapter 8 will list some of the most common ways I describe my own solutions, but for now just consider that you need to practice making yourself aware of all the changes you’re making, all the new things you’re adding, and all the rearranging that goes into finding the right

interface. Those unconscious choices hold the key to explaining your designs to other people

and making sure that your expert perspective remains at the center of the final decision process. The best way I know to practice being conscious of your decisions is to write them down. There is something about moving your unconscious thought to a tangible form that allows

you to remember everything you’ve done. Since you have measurable problems you’re trying

to solve, write down the problem and then list your solutions next to it. Whatever it takes to

demonstrate your own thought process. I am a list maker, so I love to type lists and sync

them across all my devices so that I can have access to them if needed. Some people prefer to

put pen to paper and allow their hand to make the physical movements necessary to connect

their thoughts to the real world. This can be done with simple notes or more complex

sketches. Make a list on paper of your solutions or even draw a storyboard that demonstrates

the before and after effect of your designs. The method you use for writing down your answers doesn’t matter. The point is to get you thinking about your decisions in concrete

  Here are a few examples from my own work: Problem Proposed Solution Users don’t realize the filter controls have updated the list of results because it’s instantaneous ✓ Move the count of items in the list closer to the filters so the user can see the number change ✓ Briefly show a loading spinner on each checkbox as the

user checks it

✓ Add a “Done” button that closes the panel so the user can have a sense of completing the task Marketing landing page does not convert well ✓ Move the headline and hero image to the left to make space for the call to action on the right ✓ Change the color of the call to action to red, update the copy ✓ Remove background image, too distracting

  ✓ Position the “Next steps” list so that it will usually overlap on the fold, causing the user to want to scroll to

the second CTA

Increase the add to cart rate on search results lists Reduce the number of actions required to add an item to cart

from search. One-Tap Add:

✓ Tapping “Add to cart” will auto-add the item to cart first without requiring a quantity or other information ✓ On tap, the button changes to a quantity incrementer with a value of 1. User can increase quantity as needed. ✓ Remove secondary “add to cart” confirmation button ✓ New messaging animates to indicate the item was added.

  Items with options, like color or size, will automatically ✓ select a default but allow the user to change it within view

  It can also be useful to describe your designs using only words. So much of our work is

purely visual that it can be difficult to understand what that ‘sounds like’ in a world without

pictures. Since our end goal is to tell other people about it, why not attempt to describe every

detail in sentence form and assume the reader doesn’t have the ability to see it? How would you describe your designs to someone on the phone? Or by email? Writing down how you see your work will reveal many of your motivations, some of which you never realized were there.

Here’s an example from one of my projects:

  “The list view is sorted alphabetically by country by default. The standard sort menu is available in the top-right. I made each item in the list exactly the right height for a mobile touch target. On the far left of each item is that country’s flag. We thought that would make them more easily identifiable to people. Next to the flag is the name of the country in bold and then a short description of the project directly underneath, in smaller grey type. A quick reference to the report title. On the far right of these controls are two things: 1) a summary of the data for the report type the users has selected. For example, it will show the percentage, like 34% for infection rate or the total in short form like 1.5m. 2) A disclosure arrow to indicate that there is more content ‘to the right’ if the user taps this item. The flag will make it quick for the user to find the right country and the short snippet of data will help

them know if they need to tap for more detailed report. With this design, users should be able to

quickly browse the list to find the correct report.”

  It doesn’t have to be long and it shouldn’t be time-consuming. This isn’t busywork. Do whatever it takes to help you identify your thinking. For example, if you find yourself

comparing your designs to another popular platform, it’s a good sign that your decision was based on solving a problem they might have already addressed. “When you tap on the button, it loads the next set of results the same way that SocialApp does.” It’s ok to make decisions based on another app, but it doesn’t always make the best case. What it will do is

allow you to go through a new series of questions to get to the bottom of your thinking: Why

does SocialApp do it this way? Is our context similar enough that solving the problem in the

same way makes sense? Does SocialApp have any data about doing it this way? Every time you’re able to describe your designs, you’ll uncover a part of your thought process that can help you find the best ways to talk about it.

  You do not have to share these notes with your client. They may never see them and that’s

ok. Right now, this is more about practicing being intentional than it is about communicating

with others. But the process of writing about what you create will help your brain to connect

the dots between the problem you’re working on and how your designs solve it. The better you are at making those connections, the better prepared you’ll be to talk about them with others. Whatever works for you, the goal here is to find a way to turn your thought process into something real, sharable, and visible; to uncover the words that will help you explain yourself to other people in a way that makes sense.

Make it Easy


If we’re truly taking a user-centered design approach, then we absolutely must be designing

interfaces that are easy for users. We may be solving business problems, but we have to make

it simple to use if we’re going to create a great UX. Like solving problems, this is another area where many UX practitioners do pretty well. Really, a focus on usability is the whole purpose of UX to begin with. So in the same way that UX has become a focal point of the

organizational product design process, so too has our own understanding of ease of use. We

know that usability is the core issue to be faced with our designs, but it can be difficult to describe that to other people.


My assumption is that you already understand something about usability or you wouldn’t be

here to begin with. The purpose of this section is not to tell you how to make your apps easy

to use, that’s the topic of many other classic UX books, but rather to think about usability in

a way that will help you defend, talk about, and evolve your designs to the point of a public release.

  Just as you were solving problems and making yourself aware of your decisions, you must also do the same thing here. At every step of the process, for every decision you make, ask

yourself: How does this affect the user? The trick with answering this question is that often

we simply don’t know how our decisions will affect our users. We can only make our best

guess, try it out, and then draw conclusions from what we observe. Like the previous section,

write it down. You need to be able to answer this question first to yourself so that you’re prepared to give that answer to stakeholders.

One way that I capture how my designs affect users is to write a story that is either based on

a user session I observed or loosely based on the overall use case. Here are some examples:

Design Changes How it Affects the User

  Having two similar buttons for Login and Sign Up next to each other is confusing to some users. We’ve observed users hesitate which button they should choose because they’re so similar. Since Sign Up is the most common case in this context, I’ve made that button the full width of the container and changed the Login button to a text link. This should make it easier for new users to Sign Up, while still allowing existing users to login. Most existing users will go directly to their account page by being automatically logged in. This should reduce confusion and increase conversion.

  When researchers are in the field, they need quick access to their data without having to navigate through the app. So rather than keep the hero image at the top of the home screen, we’re moving it down in favor of a “Recent Projects” list at the top. They can still see this important information, but their reports are more easily available to them because that’s their primary use of the app once they’ve already accessed the projects. Simplified, usability is about two things: common sense and research. When you’re first starting on a project, you may not have much to work with in terms of data or user

observation. You really have no choice but to make your best guess about what will work for

the user. As a usability expert, you have experience designing interfaces so you’re able to make informed assumptions: making decisions based on what you believe will create the

simplest experience. This is where common sense comes to play. There really is no reason to

overthink it. Create the easiest solution you can think of. Do what makes sense and move on.

Of course, what you think makes sense and what someone else thinks makes sense are quite

often two different things. That’s why we have research. Once we’ve made some informed

guesses, we have to check our ideas with real people. We aren’t doing user experience design

if we haven’t actually seen a user experience it. Research can take many forms, but the most

common tools are either analytics or a usability study. We will talk more about this in

  chapter 7, but let me say here that the challenge with analytics is that it can only tell us what the users did. It cannot tell us why they did it. The only way to actually know how your decisions affect users is to observe them. So make your best guess with the data you have,

but then check your designs with real people and make notes. You’ll always be surprised by

the results and you’ll be in a much better position to defend your decisions.

Get Support

  It’s not enough to solve problems and make our app easy to use, because if a stakeholder disagrees with our solution then we aren’t going to get anywhere at all. You could have the most innovative design in the world, but if no one on your team understands what you’re trying to do then you’re not going to be successful at implementing it. explanation wasn’t compelling or memorable), they’ll bring it up again at the next meeting. “Now, why did we agree to do this again?” When people aren’t convinced you’re right,

they’ll continue to think of alternatives to suggest. The project scope will increase with time

as people propose adding things: a simple control, one more button, a new menu. And as a result, you won’t be able to move as fast as you need to because you’ll be bogged down managing requests. In the end, you might have to ship a product with a compromised user experience, all because you couldn’t get stakeholders on board with your solution.

  Getting the support of everyone on your team is the primary focus of this book. We aren’t going to be able to get anywhere unless we’re able to get everyone on the same page and agree to move in the right direction. That’s what getting support is all about: convincing people that the way we’ve solved the problem will make it easy for our users and is, therefore, the best possible choice for a great user experience. You need to create an

environment where everyone understands what you’re doing so that you can move on to the

next thing.

In order to get the support we need, we have to understand our designs by asking ourselves:

Why is this better than the alternative? Implicit in this question is that we know what the

  alternatives are, we’ve considered them or even tried them, and we’re prepared to explain why our solution is better.

  Everything we design has another way of doing it. For each thing we create, there is an

alternate, often opposing, way of solving the same problem. This is the whole reason we have

disagreements about the solutions to begin with and a key problem with articulating design decisions. Designers can be really good at coming up with a solution for the problem, but we’re less adept at coming up with all the solutions to the problem. We get so myopic when

we think we’ve found it. Eureka! Our solution seems so obvious that there is very little need

to waste time considering any other approach. (After all, we’re on a tight sprint and need to


conversation that we’re not prepared to deal with: when the client suggests an alternate idea

that we haven’t considered.

  Ironically, we are usually cognitively aware of some of the other alternatives. We probably

tried them, moved stuff around, and eventually landed on the solution we believe is best. But

it’s all those little movements that we failed to make ourselves consciously aware of and so

we’re less prepared to help other people understand our thought process. Likewise, we often

know what our clients are going suggest. If you’ve worked with your stakeholders before, you can make a pretty good guess about how they’ll react (this is addressed in at length in

  chapter 4). Yet if you can guess how they’ll react but you fail to consider those alternatives

and understand why your solution is better, you will have a difficult time winning them over.

The point is this: be consciously aware of why your design decisions are better than the alternatives. Just like the previous two questions, write down your answers. Make a list of

the other ways that you could solve this problem. Create a bunch of alternative designs, don’t

throw them away, and have them available to show to the other people on your team. With

those alternatives, make a short list of why you think they don’t solve the problem as well as

your proposed design. When someone offers a similar alternative, you can show them that you tried it and are prepared to discuss why. Thinking critically about what you do will prepare you to discuss your decisions with other people.

  Sometimes I create very simple wireframes of the alternatives in addition to my

recommendation. When the client starts asking questions about my proposed solution, I can

quickly show these to visually demonstrate why my recommendation is the better.

Make it Happen


In summary, if we’re going to be successful at communicating with people about our designs

we have to be able to answer these three questions about our work:

  1. What problem does it solve?

  2. How does it affect the user?

  3. Why is it better than the alternative?

The purpose of answering these questions is more of an exercise in getting you to understand

your choices than it is a prescriptive method for documenting them. Don’t worry too much

about the details of how you write them down. If you can answer these three questions, you’ll

be well on your way to defending your decisions with the people who have influence over your project. These answers will form the basis of your response to every stakeholder concern about your designs.

  Your ability to be thoughtful about a problem and articulate any solution is more

important than your ability to design the perfect solution every time. When other people

realize that you've put thought into it and are being intentional, they're more willing to trust

you even if they disagree. That’s how you become a great designer: by describing and


In that sense, being a great designer is just as much about communication skills as it is about

design chops. You have to understand your decisions and then articulate them to someone

else who doesn’t know design as well as you do. Using these questions as our guide, you can

find better ways to explain your design decisions for the purpose of convincing people you’re

right and ensuring the best experience for users. While it’s easy to see exactly how being more articulate will help us succeed, in practice it’s

far more difficult and complicated than that. Being articulate is more than just learning to say

the right things, because nothing we say will have any affect if we don’t first consider the people that we’re communicating with. Recognizing the importance of communication in design makes it natural for us to take the next step on this path towards being a great designer: to begin seeing things from the perspective of our stakeholders.

Dokumen baru