Workshop: From Strategy to Structure (and Back Again)

The products and services you design should address the needs of your organization and of society as a whole. As a designer of information environments, you need to think beyond the user interface to the underlying structures that bring order and coherence to the artifacts people interact with.

This half-day workshop teaches tools to help visualize product strategy, and translate that strategy to an information architecture to produce products and services that address the real needs of people and organizations.

The workshop is structured in three parts divided by two hands-on exercises. However, this is not a rigid structure: The workshop is set up to be a conversation focused the attendees’ interests.

There are no slides; instead, I lead participants through a series of ideas and concepts by drawing diagrams live using an iPad Pro. This format is more engaging and interactive than traditional slides.

By participating in the workshop,

  • You’ll learn how to visualize product strategy and to connect it to purpose
  • You’ll learn how to bridge that strategy to semantic structures that inform coherent UIs
  • You’ll learn how pace layering can help you create information environments that better stand the test of time
  • You’ll get an overview of conceptual modeling as a tool for designing better information environments

I’ve given versions of this workshop at Euro IA 2016 (Amsterdam), the Italian IA Summit 2016 (Rome), and plan to do so at the IA Summit 2017 (Vancouver). 

3 Placemaking Lessons From the Magic Kingdom

If you design software, you need to know about placemaking. Why? Because the websites and apps you design will create the contexts in which people shop, bank, learn, gossip with their friends, store their photos, etc. While people will experience these things primarily through screens in phones, tablets, and computers, they actually perceive them as places they go to to do particular things.

Your users need to be able to make sense of these information environments so they can get around in them and find and do the things they came for, just as they do with physical environments such as towns and buildings. People need to form accurate mental models of these environments if they are to use them skillfully.

As a discipline, software user interface design has only been around for about sixty years. However, we’ve been designing places for much longer. There’s much we can learn from architecture and urban design to help us create more effective apps and websites. This article is a short case study in the design of a particular physical environment that has valuable lessons for those of us who design information environments: Disneyland.

Why Disneyland?

To start with, as a designed place, Disneyland is unarguably successful. Since its opening in 1955, it has received over 650 million visitors and has become a cultural touchstone. (And it’s not even most popular of Disney’s “castle” parks!)

Aerial view of Disneyland in 1956. Image:
Aerial view of Disneyland in 1956. Image: Wikimedia (Public domain)

Disneyland is also a large-scale environment (smaller than a town, but larger than a building) that has been carefully designed and managed by a single entity — the Walt Disney Company — for over sixty years. This allows us to examine the evolution of major placemaking principles in a very crisp way over a long period of time.

Another reason to study Disneyland is that it was designed with storytelling in mind, so it has rich semantic and narrative layers that separate it from most other built environments. As a result, it has more in common with interactive information environments than many other physical places.

A “hidden Mickey” in the queue for Gadget’s Go Coaster in Disneyland. Image: Loren Javier

And finally, Disneyland is a lot of fun! It’s not only fun to visit: it’s also fun to read and write about. But as we’ll see, Disneyland is serious fun, since it addresses and reflects the anxieties and aspirations of the time and place it was created in. In fact, Disneyland is a perfect example of what the architect Christopher Alexander calls good fit: a successful relationship between a form and the context it was created to address.

So in this article we’ll be looking at Disneyland as an information environment that happens to be built in the real world, and see what we can learn from it. Let’s start at the beginning: with the core vision that animates the design of the place.

Lesson 1: Start with a vision that resonates with your users

One Saturday in 1947, Disney animator John Hench drove into the parking lot at the studio and saw a peculiar sight: his boss, Walt Disney, was pacing an empty lot across the street. When Hench asked Walt what he was doing, he told him he had this idea for a “Mickey Mouse park” to entertain studio visitors.

World fairs and places like Coney Island, Kennywood, and
World fairs and places like Coney Island, Kennywood, and “trolley parks” such as Oakland’s Idora Park (pictured here) had been entertaining people since before Walt was born. Image: Wikimedia (Public domain)

Amusement parks had been around for a long time prior to the mid-1940s. These parks were groups of independently owned attractions, and tended to be chaotic, dirty, and seedy. Walt had a different idea for his park: He wanted a clean, family-friendly place that emphasized storytelling through unified theming, a place where the people who loved Disney movies could come to experience them “in real life”.

The initial plan was to create an Old West-themed park in the narrow lot across the street from the studio where Hench had seen Walt pacing. However, Burbank city officials rejected this plan (remember, amusement parks were seedy!), and Disney was forced to look elsewhere.

Unbound from the constraints of the small lot, Walt’s ambitions grew to encompass more than just the Old West. Given this broader scope, the design team divided the park into sections, called lands, which represented various themes. For example, one land would be devoted to fairy tales such as those featured in Disney movies, another to the Old West, etc. (Lots of different themes were explored at first, including clunkers such as Lilliputian Land, in which everything would be miniaturized — including tiny hot dogs which could be purchased and eaten!)

Early Disneyland map 2.png
Early Disneyland map. Image: Disney (via Malia Munday)

The park would eventually open with five themed lands:

  • Fantasyland, which brought fairy tales to life,
  • Frontierland, a recreation of the American Old West as understood by 1950s audiences,
  • Adventureland, an expression of exotic locales and cultures,
  • Tomorrowland, which presented an optimistic view of a future made better through science, technology, and corporate largesse,
  • and Main Street U.S.A., a nostalgic recreation of the type of small-town American Main Street that automobile culture was displacing at the time.

These themed lands became the conceptual framework around which the entire Disneyland experience was organized. It’s worth noting that this exact framework also served as the organizing principle for Disney’s first foray into the new medium of television — a show also called Disneyland — which appeared concurrently with the park’s construction (and which helped finance it).

Stills from the first season of the Disneyland TV show (1954). © Disney
Stills from the first season of the Disneyland TV show (1954). Image: Disney

The Disney organization is often cited as an early case study in corporate synergy: different, but related, businesses working in concert to improve each other’s position in the marketplace. The TV show would promote the park, the park would promote the movies, the movies would promote consumer products, in a virtuous cycle revolving around a consistent set of themes: nostalgia, fantasy, adventure, the old frontier, and new frontiers, all of which informed the products of the Disney studio (and many of its competitors) in the mid-1950s.

Mid-1950s map of Disney's various interrelated businesses. Image: © 1957 Disney
Mid-1950s map of Disney’s various interrelated businesses. Image: © 1957 Disney (via Phillipe Boukobza)

This was no coincidence. In 1950s America, the economy (and the population) was booming, the automobile (and the interstate highways and suburbs it enabled) was changing the ways people lived, and the Cold War (which brought the ambivalence of technology to the fore) cast a shadow over everything. The themes that informed early Disneyland (the opening of the frontier, nostalgia, the promise of tomorrow) resonated deeply with this primary audience. More than an amusement park, Disneyland would be a place where Americans could physically indulge in fantasies about their past, their future, and the innocence of youth.

This is a powerful vision, and it would prove an important competitive advantage for the park when it opened. You’re reminded of it every time you enter the park; it’s engraved in a little plaque that hangs above the entrance. It reads:

Image: Cburnett

A clear, compelling vision such as Disneyland’s can inspire and guide design teams around a singular direction. That said, having a compelling vision and a clear conceptual framework is not enough. The vision and framework must be organized in a way that makes it possible for people to relate to it, to interact with it. This brings us to our second lesson.

Lesson 2: Organize the experience into a coherent structure

The second lesson is the importance of having a coherent, extensible structure. This structure brings order to what could otherwise be a chaotic environment, and helps create a clear mental model so people experiencing the place can understand where they are, what they can do there, and where they can go next.

Disneyland’s structure makes it easier for new visitors to understand the place. It also allows the park to change and grow gracefully. Let’s examine three key structural aspects of the Disneyland experience:

  1. Its taxonomy
  2. Its topology
  3. The use of language and metaphor in the park

The taxonomy of Disneyland

As I mentioned previously, Disneyland is divided into various lands, such as Tomorrowland, Fantasyland, and Adventureland. This group of lands, and the attractions they contain, can be represented as a traditional taxonomy. For example, the Jungle Cruise attraction is located in Adventureland, and only makes sense there.

1963 Disneyland map. Image: © Disney
1963 Disneyland map. Image: Disney (via Tom Simpson)

You could create an outline of the lands in Disneyland and the attractions and other elements they offer, and it would look much like the outline for the structure of a website. You can think of this taxonomy as a map to the content of Disneyland: the specific things it offers.

The topology of Disneyland

When you examine this taxonomy, you’ll notice that even though each land contains things that are unique to it, such as the Jungle Cruise in Adventureland, all lands offer the same types of things: They all have attractions, restaurants, shops, and guest services facilities (such as bathrooms, first aid stations, etc.) I call this self-similarity between the main areas of the place its topological structure.

Topology is a term that comes from mathematics: It’s the study of the properties that are preserved when something undergoes non-destructive transformations such as twisting, stretching, and scaling. Think of a circle. If you stretch the circle, you create an ellipse. The ellipse and the circle are topologically equivalent. However, if you tear the ellipse in half, it would no longer be topologically equivalent to the circle.

Even though the lands in Disneyland feature very different attractions, they share a common structure that make them topologically equivalent with each other. The attractions-restaurants-shops-services template is an invariant structural construct: all lands in all Disneyland parks use it.

The topology of Disneyland
The topology of Disneyland

This arrangement has an important effect in the way visitors understand and navigate the park. For one thing, the themes are made clearer because they are presented as narrative variations on top of an invariant, predictable structure.

For another, this also makes the environment easier to learn, since the affordances provided by one land are present in all the others. Should the Tomorrowland visitor feel the sudden urge to use the restroom, he doesn’t need to rush back to Main Street U.S.A. since he knows all lands have at least one restroom facility.

It’s worth noting that this invariance doesn’t mean the relationships, proportions, and amounts of the elements are identical in all the lands. Adventureland has more attractions than Main Street U.S.A., for example. What’s important is that the underlying structure itself remains constant as the visitor moves from one land to the next.

This topological structure has made it possible for Disneyland to change and grow over the decades while preserving the clarity of the environment. Park designers occasionally add and remove attractions, restaurants, shops, and services to the park. Every once in a while, they also add a new land, with its own set of attractions, restaurants, shops, and services. (There’s a new one being built right now, based on the Star Wars movies.) And of course, the entire park-land construct can be replicated. (It has been, once per decade, over the past sixty years. There are now Disneyland-style parks in Florida, Tokyo, Paris, Hong Kong, and Shanghai.)

The latest Disneyland park opened in Shanghai in June 2016. Image:
The latest Disneyland park opened in Shanghai in June 2016. Image: Baycrest

So how does this apply to UX? Consider how a key function of content strategy is identifying and defining content types so large-scale information environments can change organically while maintaining coherence and understandability. These content types are a topological construct of the sort I’m talking about. That said, topologies are applicable to more than just content-heavy systems; they’re an important consideration for any large information environment that must adapt to change over time. (Don’t they all?)

Language and metaphor in Disneyland

Another cunning use of structure in Disneyland is the way Disney designers use language and metaphor to influence behavior. For example, the people who work in the park are not called employees; they are cast members. These cast members don’t wear uniforms; their on-the-job clothes are referred to as costumes. And did you notice I referred to park visitors as guests? This was another semantic innovation Disney brought to the amusement park business. (The traditional term used in the industry was marks, which says a lot about how park operators thought of their customers.)

Underlying these terms is a ubiquitous metaphor: that the park and its employees are putting on a show. This metaphor informs everything about the Disneyland experience. For example, areas of the park that are forbidden to guests are said to be backstage. When something in the park is broken in plain sight of guests, it is said to be bad show.

Custodial staff member entertaining guests. Image:
Custodial staff member entertaining guests. Image: Loren Javier

The choice of words we use to describe elements and actors in information environments has an important effect in how we act with and within them. Think about the way your team talks about the people who use your information environments. Do you refer to them as users? Maybe you may think of them as customers? Or perhaps you have some other term, particular to your industry, such as patients. Whichever the case, the term you use will have a subtle influence in the way you design for and interact with these people. Because Disney refers to its customers as guests, Disneyland cast members are more willing to accommodate their whims than if they thought of them as marks.

This showbiz metaphor, as expressed through particular language, is an important part of the semantic structure that organizes and directs the Disneyland experience. This structure establishes the divisions and connections between the elements that compose the information environment. A coherent structure can make the environment easier to learn and navigate, and makes it possible for the environment to grow and change over time.

Semantic structures have a huge influence in how people think and behave when they interact in an environment. That said, these are abstract ideas. For people to be able to relate with the environment, these structures must be made into things people can actually experience. That brings us to the final lesson: the importance of using traditional placemaking principles to create an environment the people can actually interact with.

Lesson 3: Use traditional principles to create a sense of place

With a structural framework in place, we now face the challenge of making a place that people can move around in and enjoy. This is where the learnings from urban design and architecture really pay off.

The Image of the City (1960)

The study of how people form mental models of the places they inhabit can be particularly useful. Kevin Lynch’s book The Image of the City (1960) offers insights into this. It presents five elements that define how people experience urban environments:

  • Districts: The sections of the town or city, which have their own character, and which people have a sense of being “inside of”.
  • Paths: The means by which people get around the environment.
  • Landmarks: Physical structures that give people a sense of bearing.
  • Edges: Boundaries between two phases, lines that break continuity in the place.
  • Nodes: Areas of concentration of activity that serve as focal points for people to go to or from.

Particular combinations of these elements make cities and towns different from each other and allow people to create mental models of the one they’re in. Because Disneyland is an urban-sized environment that has been designed and maintained by a single entity, these elements come together in a particularly harmonious and focused manner. Careful attention to the hierarchy of the various components of the environment, the transitions and boundaries between areas of the park, and the connections between them, create a place that is not only easy to get around in, but also coherent, learnable, and memorable.

When navigating an information environment, we also need to make sense of where we are, what we can do there, and where we can go next. Studying these elements can help us design information environments that make this possible. Let’s examine how they come together in Disneyland.

Paths, nodes, and landmarks

Let’s start by looking at how people navigate the environment. When UX designers think of navigation systems, we usually think about navigation bars and search engines. The purpose of these things is to make it possible for people to move from one area of the website or app to another, to get closer to what they’re looking for.'s primary navigation system allows visitors to go to the main areas of the site.’s primary navigation system allows visitors to go to the main areas of the site.

Navigation in Disneyland has similar purposes. However, since the park is a physical environment, it takes its design cues from architecture and urban design.

Disneyland implements a “hub and spoke” navigation model: There is a central hub, and all lands radiate off it. The park’s original design had a single entrance, located in the front of Main Street U.S.A., which led directly to this central hub. (It’s worth noting that this, too, was a Disney innovation in amusement park design: when Walt consulted other amusement park operators during the design of Disneyland, he was told this scheme wouldn’t work because it would limit the amount of people that could enter the park.)

Visitors enter the park from two tunnels underneath a train station. They then head down Main Street U.S.A. towards the hub, from which they can choose to visit any of the other four lands. Main Street U.S.A. is an example of the paths Lynch presents in his book: a way for users to get from one place to the next.

Main Street U.S.A. in the 1950s. Image:
Main Street U.S.A. in the 1950s. Image: Major Pepperidge

People instinctively know to walk down Main Street because their attention is drawn to a very unusual element at the end of the street: Sleeping Beauty Castle, a sight never before seen at the end of a traditional American Main Street. The castle is an example of what Walt called a wienie: a prominent vertical element meant to pique the interest of guests and entice them to move in that direction.

The TWA Moonliner rocket served as an early Tomorrowland landmark. Image:
The TWA Moonliner rocket served as an early Tomorrowland landmark. Image: Tom Simpson

Once in the hub, guests would look around and see other wienies beckoning them: the Swiss Family Robinson’s tree house in Adventureland, the Mark Twain riverboat in Frontierland, and the TWA rocket ship in Tomorrowland. In Disneyland, these wienies serve as landmarks: they not only attract people by standing out, but also help keep them oriented as they move around a potentially chaotic environment.

Placemaking elements in Disneyland's original (1955) layout.
Placemaking elements in Disneyland’s original (1955) layout.

Walking toward the weinies, Disneyland visitors eventually find themselves in a central opening, or plaza, where they can experience the theming, attractions, etc. that are unique to each land. These are examples of nodes in the sense Lynch talks about.

This combination of nodes, paths that connect them, and landmarks that draw people’s attention towards them, makes Disneyland easy to move around in. We have equivalents to all three in user experience design. As I’ve mentioned, navigation bars and search systems provide means for users of information environments to go from one part of the environment to another. Semantic elements such as labels and icons provide the landmarks and affordances that indicate where people can go within the environment, and second-level screens serve as nodes by providing concentrated access to related information elements and a sense of local identity for different areas of the environment.

With its prominent location, the iconic Amazon shopping cart serves as a wienie, always beckoning the user to initiate the checkout process.
With its prominent location, the iconic Amazon shopping cart serves as a wienie, always beckoning the user to initiate the checkout process.


These different areas of the environment can be thought of as districts in the sense Lynch talks about. As you may have guessed, Disneyland’s individual lands — Fantasyland, Adventureland, Tomorrowland, etc. — are districts in this sense; they all have unique characteristics that set them apart from each other and give them particular flavors.

The lands convey these concepts and narrative — i.e. the things that make them different from each other — through incredibly thorough and detailed theming. For example, everything in Adventureland — the architecture, the foliage, the music, etc. — has been carefully designed to make you feel like you’re standing in an exotic jungle outpost.

The main sections of the USA Today website are differentiated using color and particular semantic structures.
The main sections of the USA Today website are differentiated using color and particular semantic structures.

When I think of theming in the context of UX, two main areas of focus come to mind:

  • Visual presentation
  • Style of writing or tone of voice

In both cases, style and theming should be in service to the conceptual framework that underlies the work. Many designers understand the importance of choosing the right style or tone when it comes to language. However, when it comes to visual design, we are still much too driven by trends.

For example, think of the move we saw a few years ago towards “flat” visual design, which eschews “skeuomorphic” (or “realistic”) details in favor of a more pure “digital” esthetic. While I have nothing per se against this style, I don’t like it when designers select it for their projects just because everyone else is doing it. Visual style should reinforce and support narrative.

Disneyland would’ve been much less successful if its designers had decided to have the environment reflect the “pure” nature of the materials its made from: fiberglass, wood, steel, etc. Instead, designers harnessed the plastic capabilities of those materials to reinforce the differences between lands, in support of the conceptual framework that makes the park such a compelling experience.

“Gratuitous”, “skeuomorphic” (or to be kinder, “whimsical”) theming is not only ok to do — sometimes, it’s the right approach.


Finally, let’s look at edges. One of Disneyland’s most interesting design features is how it deals with transitions: those between the individual lands, and those between the park itself and the outside world.

The park’s lands have been carefully designed so their themes blend smoothly into each other. If you’re walking from Adventureland to Frontierland, you won’t experience an abrupt change. Instead, the architecture, foliage, etc. subtly blend together to achieve what has been compared to a cinematic cross-dissolve in real-life. (Many of Disneyland’s designers came from the movie industry; the park’s design is heavily influenced by cinema.) These smooth transitions are what I refer to as “soft” edges.

The opposite, “hard” edges, are transitions that have been intentionally designed to keep things apart. Disneyland also offers a prime example of these. Walt wanted to keep visitors from seeing the outside world so their experience of being in the park could be more immersive. To do this, he surrounded Disneyland with a train track atop a raised earth berm, which occludes sight lines into and out of the park. When the park first opened, this berm was crossed at only one point: the entrance tunnels leading to Main Street which we have spoken of earlier. So you could say this is a very hard edge.

In order to occlude views of the outside world, Disneyland is surrounded by an earth berm with a railroad running on top of it. Note the tunnels passing under the tracks on both sides of the train station. Image:
In order to occlude views of the outside world, Disneyland is surrounded by an earth berm with a railroad running on top of it. Note the tunnels passing under the tracks on both sides of the train station. Image: Imagineering Disney

In UX design, we often have to deal with edges between different parts of information environments, and we need to decide how hard or soft they need to be. For example, many financial services websites include areas of the environment that are meant for public use and the more private, “logged in” areas meant for customer use only.

The public and private areas of look similar, but are in fact very different places. Crossing this boundary requres entering a user name and password. This is a rather hard edge.
The public and private areas of look similar, but are in fact very different places. Crossing this boundary requres entering a user name and password. This is a rather hard edge.

Some of these transitions need to be very hard, with the user being explicitly presented with stops when they try to cross over from public to private. In others, this boundary is much softer: the transition happens more gradually. Knowing these edges can have different levels of softness helps us frame the conversation with the design team so that decisions happen in an informed manner.

The Citibank iPhone app, on the other hand, offers an intermediate state between logged in/out that offers the user some information about her accounts before she's logged in. The user can also log in faster using Touch ID. This is a much softer edge. Image: Citibank
The Citibank iPhone app, on the other hand, offers an intermediate state between logged in/out that offers the user some information about her accounts before she’s logged in. The user can also log in faster using Touch ID. This is a much softer edge. Image: Citibank

Let’s recap

People form mental images of urban environments, such as towns and cities, using five elements: districts, edges, nodes, paths, and landmarks. Information environments have comparable elements that help people make sense where they are and what they can do there.

These placemaking elements are most effective when they work together to implement a semantic structure that brings coherence to the environment. This structure implements differentiations and metaphors that allow people to relate to and understand the environment.

This structure is most effective when it’s informed by a clear vision. In the case of Disneyland, this vision was set forth early on in the design process. It guided the design team towards the creation of a new type of environment that had never been experienced before, and which resonated deeply with its users.

These three components — vision, structure, and placemaking elements — build upon each other respectively. It’s difficult to create a meaningful structure if the vision isn’t clear, and designing placemaking elements without a clear semantic structure supporting them can only lead to an incoherent environment.

As they do with physical environments, people who use an information environment need to be able to create a mental model of the environment so they can act skillfully in it. As designers, we can help them along by using traditional principles to create a strong sense of place, informed by a coherent structure that articulates a resonant vision. Disneyland offers a perfect model for us to study.

Postscript: Crafting a vision statement for your environment

While all three components — vision, structure, and placemaking — are critical, designers most often take for granted the vision component. Design projects usually start with some sort of brief that lays out high-level requirements and objectives, but the vision of what the place is going to be (and how the people who use it will experience it) is seldom discussed. Because everything that follows will build upon it, it’s critical that the vision of the place be clear from the start.

In order to help clarify the vision for the design team, I’ve started doing a small exercise at the beginning of projects to produce what I call a “here you”, or vision of place, statement. This is a short sentence that articulates succinctly and powerfully what this place will be about, and how it will act on the people who experience it.

It’s called a “here you” statement because we use as our model Disneyland’s vision of place statement. (“Here you leave today and enter the world of yesterday, tomorrow, and fantasy.”) We take out everything but the words “here you” from Disneyland’s statement, and fill out our own words from there on:

A few guidelines to help you create a “here you” statement:

  • Keep it short! (It should be able to fit in the brass plaque above the entrance to Disneyland.)
  • You’re not writing a vision for your team or your organization. You’re writing a vision for the place you are creating.
  • It should not reflect your point of view of the place, but that of the people who use your place. (That’s why it starts with the words “here you,” addressing the visitor.)
  • The language should be energizing. Visitors should be excited to visit this place; avoid clichés.
  • Be realistic about what you’re trying to achieve with the place you’re making. That said, don’t be afraid to aim high!
  • You’ll have better traction if you work on this together with your team.

A well-crafted vision of place can help energize the design team, and get it working in a singular direction. When the time comes to make difficult design decisions, the vision of place statement can help the team make the right decision by honoring the intent behind the project.

This post was originally published in Medium.

Leaving Our Mark

This post is based on a speech I wrote for two back-to-back keynotes delivered in November 2016 at Interaction South America (Santiago, Chile) and the Italian IA Summit (Rome). The U.S. election was decided on the eve before I flew to Rome.

When architects tour Rome, one of the things they learn is that buildings can last a long time. When I was younger, I had the privilege of studying architecture for two semesters in the city, and one building stood out for me: the Basilica of San Clemente al Laterano, a beautiful church built during the middle ages. I was struck by the fact that the basilica had been built on top of an earlier building: a 4th century church which you can visit by descending to a basement under the main structure. That church, in turn, was also built atop an earlier building which was used by followers of the cult of Mithra, and which you can also visit today. The Basilica of San Clemente has been used as a place of worship for almost twenty centuries. When you visit it, you have a tangible experience of the evolution of Western spiritual practice over that span of time.

Buildings serve more than mere utilitarian purposes, such as keeping us dry from the rain or giving us a safe place to rest. They’re also physical manifestations of the political, social, and cultural environments that produced them. Buildings tell stories about who we are — and who we were — as a people. As an architect, I often think about the longevity and cultural import of buildings and how it contrasts with what I currently design: software. If buildings are among our longest-lived cultural artifacts, apps and websites are among our most ephemeral. Software is changing all the time, sometimes in big ways. For example, iOS 7 introduced a completely new visual design to the iPhone’s operating system. From one day to the next, the feeling of the entire information environment changed. Perfectly functional applications that didn’t immediately implement the new style suddenly looked old and out-of-place. This change was experienced by millions of people, literally overnight.

There's some irony in the fact that the first cell phones were derided as
There’s some irony in the fact that the first cell phones were derided as “bricks”.

Unlike building materials, such as brick, wood, and steel, software is malleable, reproducible, iterative, and ubiquitous. These characteristics have allowed it to address a wide variety of problems, and to get better, faster, and cheaper all the time. As a result, software is taking over more and more tasks we previously did in buildings. It wasn’t long ago that you would’ve visited a record store if you wanted to buy music. Now you pay for the (temporary) privilege to stream to your phone the bits that represent music. Record stores are all but gone, and many musicians have had to shift to other means of earning a living. This transformation is a clear illustration of the phenomenon described in Marc Andreesen’s Wall Street Journal essay Why Software is Eating the World, in which he proposed that

we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy.

And it’s not just information-based industries, such as music, that are being “eaten”. We’re also adding a layer of information on top of the physical world that changes how we experience it. Think of an app like Yelp, which allows us to locate the best nearby gelateria. You’d expect ice cream — that most sensuous of gastronomic pleasures — to be immune from being eaten by software, yet many shops and restaurants are coming to depend on digital information as the primary means for people to find them.

Software also makes possible things that were previously impossible. I recently traveled to the Netherlands, where I had the opportunity to test Google Translate’s “Word Lens” feature, which uses my iPhone’s camera to provide a live translation of non-English words in the environment. This allowed me to get on the right train, and to order food from a menu, even though I can’t read Dutch. The ability to act skillfully within an environment encoded in a language I don’t understand is a superpower I now have, and it was made possible by software. This changes my relationship with the physical environment.

We need to recognize that in some important ways, software is taking over from architecture as the medium where many of our day-to-day activities happen. The writer and designer Edwin Schlossberg has said that “the skill of writing is creating a context in which other people can think.” Well, I think the skill of designing — especially designing software — is creating contexts in which other people can work, learn, play, organize, bank, shop, gossip, and find great gelato.

As someone tasked with designing these information environments, I find this exhilarating. We have such a broad scope of action! However, when I speak with other designers, I get the impression that often our focus is too narrow. Many of us are thinking about very small parts of these environments; one component of one screen of one version of one app on one platform at a time. Enthralled by the amazing artifacts we’re creating, we’re oblivious to the bigger picture. Again, the things we’re designing are complementing — and often obviating — physical environments that have served as our contexts for centuries, and we’re doing so with extremely ephemeral mechanisms. If we’re going to build our society upon software, it’s not unreasonable to expect that it provide us with the sort of contextual stability we’ve come to expect from our built environments. So the central question for me at the moment is: How can we design information environments that support wholeness in the long-term?

Harvard Business Review, September 2015
Harvard Business Review, September 2015

This is easier said than done, in no small part because designers have been blindsided by success. Design is now accepted as key aspect of business, and competent designers are in high demand. At a time when the middle class is shrinking, salaries and jobs for designers seem secure. Even the Harvard Business Review touts our accomplishments! Why should we be concerned about wholeness and longevity? Well, we should be concerned because we — and our kids — need to live in the world we’re creating. As you may have surmised, I’m not convinced we’re going about the design of information products and services in a way that leads us to a viable future.

In the early 1990s, the U.S. Army War College created an acronym to describe the geopolitical situation after the Cold War: VUCA. It stands for volatility, uncertainty, complexity, and ambiguity, four characteristics they saw as defining the multilateral post-Cold War world. The rise of information technologies — and the internet in particular — has radically transformed our political, economical, and social reality. We are all now living in a generalized state of VUCA. We see signs of it everywhere.

VUCA is when a few disenfranchised citizens come together in a social network and start a movement that topples a 30-year-old dictatorship in a matter of weeks.

Source: Wikimedia Commons
Image source: Wikimedia

VUCA is when our appliances start attacking us.

Image source:
Image source:

BREXIT is a sign of VUCA. So is the election of Donald Trump.

The things we design are the mechanisms more and more people are using to understand and interact with the world and with each other. Information environments can either help open our minds and increase our understanding, or mislead us by feeding us “fake news”, or trapping us in “opinion bubbles” that make us believe everyone thinks the same way we do. Information environments can help us act more skillfully in a VUCA world, or make us victims of our circumstances. Designers need to approach our craft with much greater conscientiousness. With that in mind, I’d like to offer three perspectives to help us design information environments that create more viable contexts in the long term.


The first perspective is that all information environments have underlying semantic structures that support them. These structures exist whether they’ve been designed intentionally or not. I’m talking about information architecture, which includes (among other things) the categories, hierarchies, and particular language that make one information environment different from another.

For our purposes here, it’s important to recognize that these semantic structures change more slowly than the user interfaces they support. When I was working on the fourth edition of the polar bear book, one of my tasks was updating the examples in the book. This required that I re-visit many of the websites featured in previous editions. One of those websites — — had a very different visual presentation in the mid-2000s (when the third edition of the book was written) than it did ten years later. However, when I started examining the site’s semantic structures, it struck me how little they had changed over that decade. I’ve seen this in my work as well: It’s not uncommon for organizations to overhaul their websites’ and apps’ “look and feel” while leaving their major categorization and language schemes largely untouched.

Of course, this phenomenon is not unique to information environments. There are many other things in the world that don’t change in a uniform way. In his book How Buildings Learn: What Happens After They’re Built, Stewart Brand explains that buildings are composed of layers that change at different rates. These layers are (from slowest to fastest): site, structure, skin, services, space plan, and stuff. “Site” — the ground upon which the building rests — changes very slowly, at geological pace. “Stuff”, on the other hand, refers to the things we put inside buildings, such as furniture and appliances, which can easily be moved and therefore change much faster. As buildings adapt to change over time, the form they take is affected on the differences in malleability of the various layers.

Brand’s “shearing layers” model (1994)

In a subsequent book, The Clock of the Long Now, Brand extended this “shearing layers” model to explain how civilizations change. This broader model is also composed of six layers (again, from slowest to fastest): nature, culture, governance, infrastructure, commerce, and fashion. Brand explains that because fashion (and art) change so quickly, this is where the civilization experiments with new ideas and ways of being. Worthwhile ideas are assimilated into the underlying layers, where they become more permanent parts of the civilization. As Brand explains,

The combination of fast and slow components makes the system resilient, along with the way the differently paced parts affect each other. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation an occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power. All durable dynamic systems have this sort of structure; it is what makes them adaptable and robust.

Brand’s “pace layers” model (1999)

This is a very useful insight. It helps us understand how the unevenly-changing parts of a system can help make it stronger as it evolves.

As I’ve been thinking about how to make information environments more resilient, I’ve started mapping my work to a pace-layer model. These are the layers I’ve come up with, from slowest to fastest:

  • Purpose: Why the organization, team, or product exists. This is not a goal, since it can never be achieved; it’s an aspiration that the system is always working towards.
  • Strategy: How the organization aspires to do things differently in order to strive towards its purpose; how it’s going to compete.
  • Governance: How the organization shapes itself to implement its strategy. The rules and means of engagement, including the organization’s internal hierarchy.
  • Structure: The information architecture that will inform end products and services.
  • Form: The user interfaces that people use to interact with the organization’s products and services. This is where the structure is articulated as artifacts that humans can experience.

I separate form from structure for two reasons:

  • As I mentioned earlier, the structure that informs these products and services changes more slowly than the user interfaces that are built upon it.
  • We experience the things we design through apps, websites, social media, and a variety of other touch points. For the sake of coherence, an organization’s various user-facing artifacts should share a common semantic structure.

Many designers spend a disproportionate amount of time focused on the user interface layer. This is understandable. The UI is where the “new and shiny” action is happening. It’s also much easier to discuss UI artifacts, since structure is more abstract.

Note that the first three layers aren’t normally thought to be the domain of designers at all; the last two are where we’re usually brought in. However, in order to be successful, designers should be conversant in all of the layers, and move effortlessly between them. Understanding which layer we’re acting on at any given time is key to being effective as change agents, since all the layers require different approaches. I’ve found this pace layer model useful to not only understand the relationship between form, structure, and strategy, but also in helping us navigate complex design challenges at Futuredraft.

In any case, as designers we need to acknowledge that structural decisions are going to be a part of our information environments longer than its user interfaces. If we expect these environments to last, we need to pay careful attention to their structural underpinnings.


The second perspective is that the products and services we design don’t exist on their own: they create and participate in systems. As a passenger, the Uber app in your phone would be useless if there wasn’t someone out there driving around with a complementary Uber driver app in their phone, and an infrastructure — invisible to you both — which brings you together. Uber isn’t really a product or service: It’s a marketplace; a system. The touchpoints you experience — the driver app, the passenger app, the Uber website — are merely how you interact with this system. They can’t stand on their own.

What is a system? Simply, it’s a set of elements connected to each other in ways that allow them to form complex wholes. Think of your body. It’s composed of various organs (your liver, brain, lungs, etc.) and sub-systems (your digestive system, your circulatory system, etc.) working in concert to make a more complex whole: you. The system that is your body serves a purpose: keeping you alive. It has feedback mechanisms that let it know when it needs more energy (sleepy! hungry!), when it needs to cool off, and more. You’d be in deep trouble if these mechanisms failed.

What I’m saying here should be obvious. Systems are everywhere. They’re part of our day-to-day experience. However, understanding systemic relationships requires looking at things holistically (looking at the “big picture”), a skill that seems to have atrophied after three centuries of mostly reductionist thinking. We like to break things down into smaller chunks we can understand. We want quick, easy answers. We want someone to blame when things go wrong. As a result, we suffer from a cultural blindness to systems and their implications.

Systemic failures are everywhere. For example, recently Wells Fargo — the third largest bank in the U.S. — was engulfed in a huge scandal. Bank personnel had been pressured to sell new accounts, and some of them resorted to “selling” close to two million accounts to existing customers without their consent. The bank’s management denied any “orchestrated effort” to defraud customers, and blamed employees. Orchestrated effort or not, the incentives to meet sales quotas at Wells Fargo (which reportedly included denying bathroom brakes to underperforming employees) were clearly stronger than incentives to obey the law (and common decency). As Steve Jobs said,

Incentive structures work. So you have to be very careful of what you incent people to do, because various incentive structures create all sorts of consequences that you can’t anticipate.

Misaligned incentives, like the ones in the Wells Fargo case, are a systemic problem.

For an example closer to our discipline, consider iTunes. It may not be obvious now, but iTunes was once considered an example of a well-designed system. As the folks from Adaptive Path pointed out in their book Subject To Change (2008), the success of the iPod was due in part to the fact that it was designed to be a participant in a broader system in which the device itself took on the minimal possible functionality (playing media) while other required functions (such as acquiring and managing media) were delegated onto iTunes. iTunes was never a simple application, but it was simple enough to get many jobs done well. Over the last decade, however, the ecosystem around it has become increasingly complex: Instead of merely “ripping, mixing, and burning” music to load on their iPod, today’s iTunes users can also buy or stream music, buy or rent movies and TV shows, subscribe and listen to podcasts, sit in on university courses, manage their ringtones and audiobooks, examine their iOS (but not macOS!) apps, manage device backups, and much more. Although iTunes has changed cosmetically over the past decade, it hasn’t scaled to serve these new functions of the system in an elegant way. The result is often frustration.

So how can designers think more systemically? One way to start is by mapping out the elements that will be part of the system and the relationships between them. Before architects start to design the form of a building, they often explore the possible relationships of its spaces using bubble diagrams, simple sketches that eschew such critical details as materials and physical structures in favor of more abstract representations. This allows architects to run quick what-if scenarios to solve high-level project goals such as meeting functional requirements, establishing the right balance between private and public spaces, and enabling efficient circulation. The building’s “look and feel” can be resolved later, once these deeper issues have been thought through.

An architectural bubble diagram. Source:
An architectural bubble diagram. Image source: Lily Glover.

In experience design, the equivalent of a bubble diagram is the conceptual model. These are diagrams that articulate the concepts the users of a system will be interacting with and the relationships between them. As with bubble diagrams, designers can use conceptual models to quickly evaluate high level what-if scenarios without getting mired in aesthetic discussions. Conceptual models are key to the design of effective information environments, and a good tool to help us start thinking more systemically about the work we do. (For a deeper discussion of this subject, see Conceptual Models: Core to Good Design, by Jeff Johnson and Austin Henderson.)


Let’s move on to the third perspective. As we saw with iTunes, systems aren’t static: they’re always evolving as they react to changing external and internal conditions. Perhaps the means people use to interact with the system have changed in some fundamental way (e.g. iPhones versus iPods), or the system must provide a new service (e.g. streaming music). In any case, change will happen, and the system should respond in ways that allow for (at least) its continued operation. In other words, the system must be sustainable.

When you see the word “sustainable”, you may think of the physical environment. For example, you may have heard it’s unsustainable for us to keep relying on fossil fuels for our energy. Why? Because we now understand they will run out at some point, and burning them can harm the environment. These factors cast fossil fuels as a threat to the long-term viability of our civilization. If we left our dependency on them unchecked, the system would eventually collapse.

You can think of sustainability as creating the conditions necessary for a system to meet the needs of its present stakeholders without compromising the needs of its future stakeholders. In the case of the physical environment, our primary goal should be to ensure it can sustain life in the long term. When dealing with an information environment, our goal should be to ensure that it can remain viable and useful in the long term. In order to do this, it must sustain:

  • Itself; it should be able to generate enough resources to support its continued existence.
  • Its purpose; it should generate these resources without compromising the reason(s) why it exists.
  • Its social context; it should achieve its purpose(s) without compromising the societies that host it.

These goals mirror the goals of sustainable development formulated during the 2005 World Summit on Social Development: the economic, social, and ecological “pillars”, or fundamental aspects of the system. Let’s see how they map to our work.

The Economic Pillar

Creating and maintaining an information environment requires resources. This includes labor to design, create, test, and manage software, servers to host it, energy to power them, infrastructure to deal with logistics, and more. The system should be able to generate enough value to produce the resources necessary to ensure its continuing existence. This seems like an obvious statement, perhaps one not even worth mentioning. However, in the past couple of decades we’ve seen many information environments capture our attention without generating enough value to remain viable in the long term.

The Social Pillar

Information environments exist within a broader social construct. In order for them to remain viable in the long-term, society as a whole must remain viable as well. Again, this seems like an obvious thing to say. However, many information environments are based on business models that, while viable from the economic perspective, may be unsustainable from the social perspective. For example, advertising-based business models can be problematic, since advertising drives us towards more consumption and does so by targeting us as members of ever-narrower demographic segments. Given the challenges we face as a society, we should be striving to be more mindful of our consumption and more focused on the things that unite us.

The Ecological Pillar

The third and final pillar is the least obvious, yet no less important: the ecological pillar. The things we design participate in and create communication ecosystems that can either sustain or harm our societies’ long-term prospects. We need to consider the impact our information environments have on these ecosystems.

Media critic and educator Neil Postman pointed out that communication happens in semantic environments that have parallels to physical environments. If you consider the “goal” of the physical environment to be sustaining life, then the goal of the semantic environment is conveying meaning. Both types of environments can become polluted, making them incapable of achieving these objectives. In the case of the semantic environment, pollution happens when the language, rules, and purposes of one particular semantic environment (e.g. science) start to be blurred with those of another (e.g. religion).

For example, after the 2016 U.S. election, there has been much talk about the problem of “fake news” in social networks. What this means is that a particular semantic environment (social media, which we’re using to inform our worldview) is becoming polluted with material from another semantic environment (outright propaganda, or in some cases, satire). This is not new, of course — disinformation has been around for a while. What is new is the pervasiveness of the problem, and the fact that now we move much more fluidly between different semantic environments. This makes it more challenging for us to understand how we’re supposed to interpret what we’re looking at. As the designers of these systems, it behooves us to understand how they can become polluted, and work to ensure that the transmission of meaning can happen as “cleanly” as possible.

Non-renewable Resources

When we discuss sustainability of the physical environment, we often talk about non-renewable resources. These include things that are essential for our survival, like air and water, and some that are key for our current way of life, such as fossil fuels. The essential characteristic of these resources is that they’re limited: once they run out, the system collapses. Because of this, responsible stewardship is essential for the continuing survival of the system.

Information environments also have an essential non-renewable resource, one without which the entire system collapses: the attention of the human beings who will be interacting with the products and services we design. We only spend two-thirds of our (already short!) lives conscious enough to use a smartphone. What are we doing with the precious time of our apps’ users? Are we helping them be more effective parents, co-workers, citizens? Or are we merely giving them a quick dopamine fix so we can show them more ads?

Every day, people are spending more of their time using the apps and websites we create. We should honor this privilege by not squandering their attention.

Towards a Co-creative Design Practice

Let’s summarize. Information is changing the world. Information environments — experienced through digital products and services such as apps — are becoming the contexts in which people are carrying out more and more of their day-to-day activities. In some important ways, these systems are assuming roles that have been served by architecture. As with buildings, information environments affect how we understand ourselves and our societies. Because they’re made of an incredibly malleable material — software — the contexts they create are in constant state of change. This is new for us. As designers, we need to accept responsibility for the long-term viability of these environments and the societies which host them. We’ve examined three perspectives that can help us do this:

  • The semantic structures that underlie our systems change more slowly than their user interfaces.
  • The products and services we design don’t stand on their own; they participate in and create broader systems.
  • These systems should be able to adapt to changes sustainably.

Design, as it’s been traditionally practiced — with its “hero” designers and its emphasis on the form of individual artifacts and achievements over the systems they create — is incompatible with a world that is characterized by rapid change, systemic challenges, and ambiguity. At Futuredraft, we believe designers are being asked to show the way towards a more complete utilization of existing knowledge, which in turn produces the comprehensive and sustainable solutions needed today. This requires we become aware of — and master — our own filters, opinions, and preconceptions, which interfere with the emergence of clear seeing. By doing so, we can move towards a more co-creative practice that integrates the design skills of those who will actually live and work with (and in) these information environments. Only by working together to design new possibilities can we overcome the enormous challenges we currently face. This sentiment was expressed more succinctly (and beautifully) by Christopher Alexander:

Making wholeness heals the maker.

This is my wish for us: that we learn to use our craft to heal ourselves and our world. We are all stakeholders in the design of a more viable future.

This post was originally published in Medium.

Leaving Your Mark

Update 2016-12-26: I’ve published a post based on this presentation.

Closing keynote for the 10th Italian Information Architecture Summit, delivered on November 12, 2016 in Rome.


What mark are you leaving in the world? Look around you. Rome is a testament to the power of architecture to create places that stand the test of time, marks of people long gone. Stone, metal, wood, pozzolana: Architects design for the ages.

Digital information environments, on the other hand, are among our shortest-lived designed artifacts. What was once a cutting-edge application quickly becomes outdated as device form factors and operating systems evolve. It seems those of us who design and produce websites, applications, and other information products and services are constantly trying to catch-up so our designs can remain relevant. Instead of designing for the ages, we work for and within an ever-smaller now.

But not everything changes at the same speed. The structure of information environments, in particular, evolves at a slower pace than its forms. Because of this, information architects can and should design for the ages too.

In this closing keynote, we will look at information architecture as a discipline in the broader context of design for purpose, and how as an information architect you can leave a mark that endures.

Lands, Hubs, and Wienies

Powered by Blueprint

Update 2017-01-12: I’ve published a post based on this presentation.

I delivered this presentation at the 2016 IA Summit in Atlanta, Georgia

Presentation Summary:

Digital products and services are new types of places that alter how people understand information. This presentation distills lessons in placemaking from one of the most successful places ever created—Disneyland—to help you design more effective information environments.

When designing a digital product or service, you are engaging in a new type of placemaking: one that alters how people perceive and understand information. As with (building) architects, digital designers seek to create environments that are understandable and usable by human beings, and which can grow and adapt over time to meet their needs and those of their organizations. This presentation will help you create more effective digital products and services by distilling lessons in placemaking from one of the most successful physical environments ever designed: Disneyland (and the subsequent Magic Kingdom-style theme parks around the world). You will learn how to create conceptual frameworks that allow users to make sense of and find their way through your information environment, and how those frameworks can inform a clear structure for your user’s experiences.

Slide deck:

Architect Everywhere

This year, World IA Day was celebrated in 57 locations around the world. That’s a lot of people gathering to learn and talk about information architecture! This article, which is based on the keynote presentation I gave at WIAD San Francisco, is inspired by the thought of all these folks — mostly designers — coming together around this year’s theme: “Information Everywhere, Architects Everywhere”.

I think most of us who design digital products and services have a pretty good grasp of what we mean by “information”. Information is our raw material; we are immersed in it every day. However, I suspect “architecture” is more elusive. In what sense is what we do architecture?

Earlier in my career, I used to think that architecture was a useful metaphor for the work I was doing. I would tell clients that “I’d do for their websites what architects do for their buildings” or that “site maps are to websites what plans are to buildings”. However, I’ve come to realize that architecture is more than a metaphor in what I do. In this article, I hope to persuade you that the apps and websites we design are architecture in a very real sense, and to make you more aware of your role in the creation of architectures made of information.

Architecture is important to us as a species. In his book Fit: An Architect’s Manifesto, architect and educator Robert Geddes offers two reasons why we can’t live without architecture. They are:

First, as human animals, we must protect our bodies from hostile environments, so that we can live as individuals.

Second, as social animals, we must create protected places in our environment so that we can live together as groups.

Obviously the digital products and services we design can’t satisfy the first condition, but think about the second one. Increasingly, many of the interactive products and services we design fulfill the second role.

Eighty years ago, if you wanted to influence the way that office workers went about their duties, you needed to tweak the physical environment within which they carried out those duties. For example, the “Great Workroom” of Frank Lloyd Wright’s Johnson Wax Headquarters—one of the first open-plan office spaces—was created, in the words of architecture critic Paul Goldberger, “to give the company’s clerical workers a sense of community and nobility”.

The Great Workroom in Frank Lloyd Wright’s Johnson Wax Headquarters. Source:

Today, if we want to talk about creating a sense of community at work, we have to think about how we organize our information environments. For example, in Futuredraft much of our work happens in Slack; we have one collaborator who has never stepped in our physical space. Arguably, the way we’ve structured our Slack channels has as important an impact in the way we go about our duties than our physical office does.

Increasingly apps and websites such as Slack are taking over many of the roles that used to be served by physical places. Besides work, we use them to learn, shop, bank, organize, gossip, and more. These information environments set the contexts for many of our day-to-day activities. So in a very real way, the stuff we make satisfies Geddes’s second condition: They create protected places so that we can live together as groups.

In this article we will look at three ways in which we are creating architecture when we design information environments. The three are different but tightly related. But before we dive into the subject, a disclaimer: One of the occupational hazards for information architects is that we tend to obsess about labels, and one of the labels we obsess about is job titles. I don’t think this is a productive discussion. So it doesn’t matter how you describe what you do: interaction designer, product manager, visual designer, developer, researcher, or what have you. If you are doing any type of design for information environments such as websites or apps, you need to know about information architecture. In this article I will not be using “architect” as a noun — something you are — but as a verb — something you do. As a reminder that we’re talking about doing, not being, I will talk about “architecting” instead of “architect”.

With that out of the way, let’s explore the three ways in which we architect.

Architecting as Structuring

The first sense in which we architect when we design an information environment is when we are structuring it. What do we mean by structuring? Again, I’ll quote professor Geddes:

Architecture as “structure” has two meanings: one involves the materials and methods in its construction; the other involves the arrangement of parts in its organization.

It is the latter that we are mainly concerned with here. When “building” architects start working on a design, one of the first things they do is break the problem up into its program: the list of needs that the building must serve. They then analyze possible solutions by means of sketches such as bubble diagrams, which explore possible relationships between the spaces that will satisfy those needs.

You may do something similar in your on work, perhaps using sticky notes instead of bubbles. Whether you’re designing an app or a building, you want to 1) figure out what people will be doing there, 2) how you will enable them to do it, and 3) how they will move around in the environment as they go about doing it. These rough sketches help you explore different ways of structuring the environment to accomplish these things.

Information architecture is deeply rooted in structuring. My first experience with seeing the phrase “information architect” in print was with Richard Saul Wurman’s 1996 book Information Architects. Given the novelty of the phrase at the time, this book lays outs three definitions of the term in its cover. The second of these definitions gives structure a central role:

a person who creates the structure or map of information which allows others to find their personal paths to knowledge.

This concern for structure is very obvious in Wurman’s work. For example, in his design for the Tokyo subway system map you can see a very clear structure being employed to make a potentially complex diagram legible and memorable.

Wurman’s design for the Tokyo subway map

The polar bear book — one of the foundational texts in the “IA for UX” discipline — also features structure as a central concept in information architecture. For example, starting with the first edition, discussions of “narrow and deep” versus “broad and shallow” structures have been a key part of the “IA for the WWW” narrative.

As a result of this focus, UX designers have long associated information architecture with structure, to the point where many believe that structuring experiences is the sole remit of IA. But while structure is definitely central to the practice of information architecture, there is more to architecting than just structuring. We’ll see how a bit later, but for now let’s try to nail down what we mean by structure.

It’s been said that the human brain is a pattern recognition machine. Evolutionary forces have honed our senses so that they are highly attuned to rhythms and variations in our surroundings. Environments that are predictable and ordered are more easily understood than those that are chaotic or in constant flux. Structural and ordering principles allow us to use this pattern-recognition feature of the human mind to our advantage when organizing information environments.

Architects have been employing structure and order for centuries to help us make sense of our physical environments. For example, examine the façade of a public building such as this one:

Chandigarh High Court, by Le Corbusier. Source:

The first thing you’ll notice is that this building is not a homogeneous blob: It is made up of various components such as columns, windows, and slabs which are different from each other. The edges between these elements are clear, and this differentiation allows us to identify patterns in the form of the building. There is also a clear sense of granularity to how these different components are put together: the colored panels are contained in the sun shades which are contained within the wall units which are contained in the facade. The skin of the building has been shaped in such a way that the columns create a sense of rhythm. Where this rhythm is broken, you get a sense that something important is happening, which is appropriate since that is where you enter the building. We call this hierarchy. All of these elements and ordering principles come together in an environment that serves our basic physical needs, and communicates to our senses the affordances and constraints defined by the building’s design.

Now take an information environment like Twitter. It, too, is made up of components that are different from each other and which are nested at different levels of granularity. Individual tweets are contained in a timeline, which is a list of tweets. There are various such lists in the system, and their names hint at the information they contain: the “home” list, the “notifications” list, the “messages” list, and so on. Like the building’s facade, these streams of Tweets have a rhythm, following a very particular form that has evolved over the years (a user avatar, a user name, a user handle, a time stamp, the text of the tweet, any associated media files, etc.) Twitter’s main navigation bar, on the other hand, has a very different structure and rhythm. (It is not an accident that the labels in this navigation element consist of a single word; it would be very strange if one of them was as long as a 140-character tweet, for example.)


The relationship between Twitter’s navigation bar and the tweet stream varies between different platforms. On the Twitter website, the main navigation bar is located at the upper left of the window, above the tweet stream, where most website navigation bars reside. However, in the iOS Twitter app, the navigation bar is below the tweet stream. This is a standard location for navigation bars in iOS apps: within reach of the user’s thumbs. This variation between platforms is an example of opting for coherence over consistency. In the placement of these elements, Twitter’s designers demonstrate a clear understanding of the hierarchical relationship between these components in the information environment in the abstract, and an understanding that different platforms express such hierarchies in different ways.

One of the most interesting and challenging aspects of our work is that increasingly the things we design need to be able to be used through a variety of different means. These structures that we design “in the abstract” need to convey meaning clearly when instantiated in different channels, which have different ways of expressing such meanings. The particular arrangement of these elements — their granularity, hierarchy, and relationships between them — and the labels that we use to describe them, are what make Twitter “Twitter”, independently of whether we’re accessing it in Twitter’s website or in a third-party phone app. These structures set Twitter apart as a unique place where we can go to “live together as a group”. Which brings us to the second sense in which we architect…

Architecting as Placemaking

The second sense in which we architect when we design an information environment is when through it we are creating a context where people go to do particular things. This placemaking role of IA is less commonly acknowledged than its structuring role.

Sir Winston Churchill once said that “We shape our buildings; thereafter they shape us.” He was right; the contexts created by our environments define what we can and can’t do in them. As a result, they set important parameters for our lives. Look around you. Even though you are reading these words on a small screen, that screen — and your body — are currently located in a physical environment. Whether that place is your office, a library, or a subway car as you head home for the evening, it’s probably been carefully designed to allow you to accomplish certain things and keep you from doing certain others: this is where you walk, this is where you sit, this is where you interact with others, etc. We’ve internalized our physical environments’ affordances and constraints to the degree that we don’t think about them much as we go about our day-to-day activities.

We bring this awareness of place to information environments as well. Just as “building” architects work to design physical structures that express and support their functional and cultural purposes, so must we work to ensure that the semantic structures of the information environments we design do the same. For example, today users expect a certain set of features and information from a bank’s website. They have also come to expect that a bank will call these features by certain names, and expect to see labels such as “deposit”, “transfer”, and “accounts”. Seeing these features and labels in a website — even one with no branding at all — would lead a user to conclude that she is in a bank’s website, and this would affect the way she understands information published in that site.

At this point, we must note that we interact with these software-based contexts mainly through semantic elements such as labels, icons, and images, and the relationships between them as they are presented to us in the user interfaces of these apps and websites. In the “real” world, we can easily tell the difference between a bank and a church, and we have a clear idea of when we are in one and not in another. In information environments it’s often not that easy. For example, if you’ve used Slack, you know that it provides three different types of contexts for conversations:

  • Direct messages, which are between you and one or more other people.
  • Public channels, which are persistent discussions that everyone who has access to the account can see.
  • Private channels, which are only visible to the people who have been invited to that channel.

Unfortunately, the structure of all three contexts is identical, and by default the only way to know which one is which is by looking at small icons next to each channel’s name.


Given the potentially disastrous consequences of sharing something private in a public channel, Slack would be a better experience if these different contexts were more explicitly set apart.

Let’s now talk a bit about the importance of precedent in placemaking. It’s no accident that you have no trouble telling the difference between a church and a bank in the real world. For centuries, “building” architects have been creating places that solve this problem. A bank is configured differently than a church, and some places are more bank-like than church-like. The long nave with pews, an altar at the end, and stained glass windows tell us that we are in a church, and we are likely to listen and behave differently there than we would in a bank. The forms and spaces that define these places and make them different from each other have evolved over many centuries, to the point they we have internalized many of them.

A basilica plan. Source:

There are reasons why hospitals, banks, restaurants, churches, and homes are organized the way they are: They have evolved over time (and in different cultures) into their present forms. For example, the church typology evolved from an earlier Roman building type called the basilica, which was meant to enable gatherings. The basilica form has been evolving through the centuries to the point that now we thoroughly identify it with churches and other religious places of gathering. If you were to design a church today, this would probably be your starting point. (That does not mean that there isn’t room for innovation, but tossing out precedent whole cloth is usually not a good idea.)

Banks, on the other hand, have evolved to meet different needs and uses: They usually have places for people to queue, stations for them to fill out papers, a large vault in the center, etc. A bank’s customers, the people who work there, and the people who will build the bank’s building are used to banks being structured a certain way; creating a new bank building that completely shunned conventions would carry a large cost in both monetary and cognitive terms.

The same is true with information environments. For example, at this point the web has been around long enough for certain structural conventions to have emerged that are by now standard to various website types. Today, most major bank websites have similar features, publish similar information, and refer to these features and information with similar names. In particular, the structural duality of a private “logged in” experience that shows the user his or her accounts, versus a public “logged out” experience that presents the bank’s products and services, is common enough in the bank website typology that it would probably be difficult to launch a new bank website that completely eschewed it.

We can use typologies to our advantage. Studying what has come before can help us create information environments that are familiar and usable, and can allow us to focus on the aspects of the experience that truly differentiate one information environment from another.

To summarize: information environments like Slack and your bank’s website are different contexts, and provide different contexts within them. It’s important that these contextual differences be made clear if these information environments are to fulfill their goals. Which brings us to the third and final sense in which we architect…

Architecting as Embodying a Strategy

The final sense in which we are architecting when we design an information environment is when, through this design, we are explicitly seeking to serve the needs of a chosen strategy. This is a thorny statement, so let me unpack it. A strategy is simply a plan to achieve one or more goals under conditions of uncertainty. Because of this, strategies are formulated at a high level.

Let’s illustrate this with an example. Imagine that you have a goal of climbing to the top of a mountain which is shrouded in mist, so you can’t see where you’re going. A strategy for reaching the top could be “when given a choice, always go towards higher ground”. Contrast this with the sort of super-detailed instructions that come with an Ikea bookshelf. Before you start building the shelf, you know 1) the exact form you want to arrive at, 2) the tools you will be using, and 3) the parts that will go into it. A person assembling Ikea furniture doesn’t face uncertain conditions, so he can be given very detailed and clear instructions. The mountain climber requires a higher-level approach.

Many modern information environments are experienced across various device form factors in different times and contexts. They also seek to solve sets of strategic objectives that are by definition unique to each particular project and are often unclear when the project starts. In other words, design projects are ambiguous challenges, more like mountain climbs than Ikea furniture. Under these uncertain conditions, designers are asked to make decisions that will impact the system’s ability to achieve its strategic objectives. When these choices get baked into the structure of our product, it becomes very difficult to change them. And if we make the wrong choices — especially at the beginning of the project — the product can fail.

Many years ago, I saw a project for a housing subdivision. The subdivision consisted of narrow lots that were perpendicular to the street. An architect had been hired to design the model house that would be built in these lots, and the design he came up with had the roofline of the house set perpendicular to the direction of the lot so that the roof was lower at the front and back of the house and taller at the middle. The architect liked how this looked.

However, these houses were meant to appeal to low-income buyers. This meant that the houses needed to be expandable over time. The only place for the houses to grow was into the back yard, and having the roofline perpendicular to the lot made that much more difficult than if it was parallel to the lot. So the proposed design failed as an embodiment of the desired strategy.


You could say that in this case there were two forces pulling the design in opposite directions: One approach was optimized for mutability, or growth, while the other was optimized for the architect’s aesthetic preferences. In this case, these forces were in conflict. All design projects have forces such as these pulling them in different directions.

1*Gd5_Rr_gAHIB_3BUHmoQAw.pngThe design process consists in defining hypotheses of what the balance between these forces ought to be, and articulating them to two main audiences: stakeholders — the people who are commissioning the product and/or those who will be using it — and its builders. This articulation happens by means of models, which the designer creates to communicate the intended balance to these audiences. These models can take many forms: sketches, comps, prototypes, etc. Feedback from stakeholders and developers helps designers refine these models as the project progresses, and the models evolve from being abstract and ambiguous (rough sketches) to concrete (screen comps, prototypes). (By definition, models always stop short of being of identical fidelity to the final product.)


When designing something as complex as a multi-channel information environment, the main role the designer must play is ensuring that the conceptual integrity of the product vision is preserved as the project goes through this evolutionary process — unless, obviously, new information has emerged during these conversations that calls for a change of tack. Here it’s worth quoting computer scientist Fred Brooks, author of The Mythical Man Month:

Conceptual integrity is central to product quality. Having a system architect is the most important step toward conceptual integrity.

As the designer of an information environment—its “system architect”—you will be called on to help define (and often, defend) its conceptual integrity. Your ability to meet this challenge will often be the difference between a product or service that accomplishes its goals, and one that doesn’t. That said, I must again emphasize: conceptual integrity is valuable to the extent that it enables and supports the product’s strategic vision. The house may look beautiful from the curb, but if it can’t be expanded it won’t sell.

So how do you, as a designer, determine whether the system meets its strategic objectives? There is only one way, and that is for you to understand what those objectives are. This requires that you understand not just what drives your team, but also the goals of the broader organization it sits in, and at a higher level, those of society as a whole. In the end, you want to achieve what architect Christopher Alexander calls “good fit”: A tight relationship between the form, or product you have created, and the context that it was created for.

A Final Observation

So to summarize: you are architecting when you define the structure, create a place, and/or embody a strategy of and through the information environment you are designing. You do all three, whether you’re conscious of it or not. It’s worth noting that these three ways of architecting inform and support each other. We create structures because we want to create places where people can do things, and we create places because that is where people experience and enact our strategic intents.


As you go about your work, think about the repercussions of the structural decisions you are making, and their impact on placemaking, and — by extension — on your organization’s strategic intents. You are doing these things in your design projects already. The results of your architecting will be much better if you undertake it consciously.

… for everybody

This is a transcript of the keynote speech I delivered at the 2015 Information Architecture Summit in Minneapolis, MN.

Thanks for giving me this opportunity to stand here before you. This is my tenth IA Summit, so in many ways I feel like I’m addressing friends and family. As a result, I feel comfortable telling you about one of the most exciting and terrifying episodes in my life.

It happened in early 1994. It had been about 18 months or so since I had graduated from architecture school, and I was working as a junior architect in a small architecture firm in Panama, where I’m originally from. I was doing the sort of menial, entry-level design tasks that usually get delegated to junior architects – designing bathrooms, taking measurements on site, etc. – and I was frankly starting to feel anxious and panicky. I had started questioning my choice of career.


You see, I had spent five years learning about architecture: this magnificent, ancient, proud discipline where big, abstract ideas were turned into the environments within which – and through which – we conduct our lives. I had become particularly fascinated by a generation of architects who came into their prime in the first three decades of the Twentieth Century; people like Le Corbusier, Charlotte Perriand, Walter Gropius, etc.

What excited me about these people is that they weren’t just making buildings; they were doing so within the broader framework of having their work be a catalyst for change. They were living through a period of great turmoil – what is often called the machine age – in which industrialization was changing the world. In the span of a few decades, people had gone from horse-drawn buggies to motor-cars and airplanes, from hand-crafted to mass-produced, from brick and mortar to concrete and steel. So, lots of changes!

These early Twentieth Century architects saw the world changing around them and started to ask questions like: How do you live a human life under these conditions? How do you mold these societal forces into something that makes the world better for people? How do we create products that honestly express the technologies and materials of the age, but that also allow people to flourish, to be human?


There is a word that comes from German – zeitgeist – that I like very much. It means the spirit or mood of a particular period in history as articulated by the ideas and beliefs of that time. These architects were engaging their work in a dialog with the zeitgeist, quite self-consciously. Their work had a deeper meaning than just the buildings and furniture they designed. There was an ideology behind it, a drive to make the world a better place. Because their zeitgeist was centered on machines, their agenda was harnessing this industrial spirit of the times in the service of humanity. Many of their ideas haven’t stood the test of time very well – they were of their time, after all – and some of their legacy is considered controversial today. But the notion that design can be a catalyst for change at a societal level – at a structural level – while also exploring the possibilities of the technology of the time, stayed with me. It’s what excited me about architecture.

And here I was 18 months into a career in architecture, and was being asked to design poolside cabanas for rich people in a poor country. Given the zeitgeist of our time, I was having trouble seeing how there was a path from the type of work I was doing in architecture to the sort of human-centered, tech-driven, world-changing impact that excited me.

In parallel to this, I had started to become increasingly fascinated by the Internet. I first saw the Internet in 1992 when I was still in the university. I was exposed to gopher and was intrigued. But it wasn’t until a bit later when the first web browser came out that I really felt like I was experiencing something truly special. An understanding of what the web was trying to do would lead any learned person to conclude that here we were witnessing the birth of a potentially world-changing technology of a magnitude that we hadn’t seen in centuries. Here was what the zeitgeist was moving to! Moreover, the more I learned about it, the more obvious it became that my architectural training provided many tools that would come in very handy when working in this space.

Exciting (and terrifying) story

So this is where the exciting/terrifying part comes in. In early 1994 I went on holiday with my parents. They had rented a little cabin in a rainforest – a primeval place, with no electricity or telecommunications – and this is where I had “the conversation” with my dad. I told him that I had decided to leave my career in architecture to start a company “doing computer stuff.” Perhaps many of you who are of similar age to me experienced such a conversation. It’s worth noting that this was before there was even commercial Internet access in my country; as a matter of fact, my first web design client was our first commercial ISP! It’s fair to say that my dad was concerned.

I had no idea what I was doing or what I needed to do next. I would need to start a company, since no one would hire me to do this type of work. How would I do that? Did I need to incorporate? Did I need a lawyer? Should I get an accountant? How would I get clients? How would I let them know that I could help them, when they didn’t even know they needed help? How would I learn how to do things that I didn’t even know I needed to do? It was all very confusing. I felt disoriented and scared. But I also trusted this gut feeling I had – that by entering into this new line of work, I was coming closer to the force that had animated those Twentieth Century architects I so admired. I was aligning my work with the zeitgeist, so it would be OK.


This brings me to the reason why we’re having this conversation. After nine IA Summits, I’ve seen a lot of change in this community. Whether this is your first time joining us, or you’re an old-timer, the fact that you’re here means you are participating in an evolving conversation that has been many years in the making. Together, we are engaged in a dialog with the zeitgeist so that this new area of practice we are forging – information architecture – serves human needs. And not only do I believe it does serve human needs – I believe IA is the most important area of practice to be engaged in today if we are to craft a humane, dignified existence for ourselves and our fellow humans given our current conditions. We’ll get into the reasons why a bit later, but for now I’m putting that out there.

The problem is that while many of us understand this – even if we don’t express it as such very often – it hasn’t been easy to let the rest of the world know. The details quickly become esoteric, and it’s not like all of us understand them in the same way. So it should come as no surprise if my dad still doesn’t fully understand what it is I do. That said, there are many colleagues and “friends of IA” – people within our own ranks – who still don’t seem to get it either. Some are explicitly questioning the relevance of our discipline. I was going to read a few Tweets here, but I don’t want to put anyone on the spot. These are not ill-meaning people. Their idea of what IA is is simply informed by the state of the field a decade ago. They are not aware that the conversation has moved on. And frankly, perhaps neither are many of us. As a discipline, we haven’t done a very good job of articulating the case for information architecture in today’s environment.

I was given the opportunity to do just this recently – in a big way – and I’m going to share with you what I’ve learned. To do so, I need to get back to my exciting/terrifying story. A few years had passed at this point. I had incorporated, and had a couple of employees helping me out. I even had a business card that said “Information Architect” on it! So: legit. Our company was a few years old, and the web was getting hot! It seemed everyone wanted a website, and quite inadvertently I had become one of the few “experts” around.

But frankly, we had no idea what we were doing. We were winging it! In those early days, we were very focused on the technical aspects of the work: basically, cajoling early HTML into presenting things that looked as much like printed page layouts as possible given incredible constraints. New technologies were coming out all the time – Perl, Java, Flash, and more – it seemed like there was a new one every week! It’s fair to say we were paying more attention to the surface than to the underlying structures of things. We understood instinctively that our products needed to be usable and understandable, but we had few frameworks to help us achieve this.

Information Architecture for the World Wide Web

Then, along came this book. [Holds up a copy of “Information Architecture for the World Wide Web”, first edition.] This is my copy of the first edition of the polar bear book. It’s even autographed by Lou! This book came into my life at exactly the right time. I knew enough at this point about the materials I was working with to know what they could and couldn’t do, but wasn’t disciplined enough to do anything significant with them. Through insights from a field I knew close to nothing about – Library Sciences – this book gave me frameworks that allowed my work to get to the next level. I started to think about structure in a disciplined way, and started to rediscover the relevance of tools I’d learned about in architecture school – like conceptual diagrams – which I now saw presented back to me in a different guise as a key component for the creation of effective websites. Upon its release, the polar bear book quickly shot up the best seller charts for IT books. Clearly I wasn’t the only person in the world who was struggling with these problems, or who needed to hear this message at this time. This book engaged the zeitgeist of its time and offered solutions to issues many of us were facing. In many ways, it was the catalyst that led to the creation of the very conference we are kicking off now.

This was seventeen years ago. Back then, we had a concept called “Internet Years”: basically, innovation online was happening so fast, that one year in the Internet equaled x number of years in the “real world.” It’s kind of like dog years: if your dog is 5 years old, his equivalent human age would be 35. Well, if we go by Eric Reiss’s calculation that sets x for Internet years at 4.7 human years, then the first edition of the polar bear book is almost eighty human years old! The context that the book was written for – the zeitgeist it tapped into – is very different than today’s. The hyperlink is not an exotic novelty anymore. Experimentation in website navigation has taken a back seat to standardization and familiarity. Search is now ubiquitous and taken for granted. We no longer have to worry about incompatibilities between browsers. There have been two further editions of the book since 1998, and while they’ve improved upon the first edition, they have remained relatively consistent in their focus. And so much has happened since the last edition came out in 2006!

By the early 2010s, this situation had come to a head. Designers were now interested in creating apps for mobile devices, and clients were investing in social media like Facebook and Twitter. It wasn’t clear how IA could contribute to making either of these better. Fairly or not, the web stopped being the sexy new thing, and IA had remained closely tied to web navigation in most people’s minds. Our discipline seemed to have come out of sync with the zeitgeist.

As many of you know, there is a fourth edition of the book in the works. I am honored to have been asked to help Lou and Peter produce this new edition. So I’ve been living with this book for the past year, going over it very closely, asking questions: how has the broader context changed since this was written? Is it still relevant today? How can we best illustrate this particular point now? In other words, how can we address recent advances in our discipline’s conversation with the zeitgeist?

In revisiting the previous editions of the book, I found something interesting: even though most of the examples seem quaint now, the fundamentals have been there all along. People are still striving to find and make sense of information, it just happens that now they have different means to do so. We are still creating semantic structures, but now they are being manifested in small mobile devices which bring with them a different set of constraints and opportunities, including the ability to experience them in wildly different contexts. So one of the keys to reframing the conversation so that we can move forward is to stop thinking about the products of our work as websites, and start thinking of them as information environments that can be experienced in many different ways.

Information environments

As part of this reframing, we have also identified three principles that underlie information architecture. The first of these is that we experience these information environments as places made of language.

Places made of language

Think about the way we describe these experiences: we “go” online. We meet with our friends “in” Facebook. We visit “home” pages. We log “in” to our bank. If we change our mind, we can always “go back”. These metaphors suggest that we subconsciously think of these experiences spatially. And we interact with these products and services primarily through language: labels, menus, descriptions, visual elements, content. These semantic elements and their relationships with each other create environments that differentiate these experiences from each other and facilitate 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 and structure help define them as distinct “places” that people can visit to accomplish certain specific tasks.

In his book Understanding Context, our colleague Andrew Hinton argues that we make sense of these experiences much like we do physical places: by picking up on particular cues – words and images – which define what can and can’t be done in the environment, be it an idyllic open field in the English countryside or a Web search engine. These information environments we are designing are new (and very real) types of places, which are made of language.

Coherence across contexts

That brings us to our second principle: making these experiences be coherent across multiple contexts and still serve their business, usability, and findability goals. 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 has to work in abstractions to derive principles that can translate in multiple ways depending on the needs of different channels. A navigation structure that works well in a laptop web browser should function differently when presented in an app on a 5-inch touchscreen, but the language should be consistent in both.

In their book Pervasive Information Architecture, Andrea Resmini and Luca Rosati argue for consistency as a critical component of what they call a pervasive information architecture — that is, one that is experienced across multiple channels and contexts. In other words, when an organization serves its users via multiple channels, the users’ experiences between those channels should be semantically consistent and familiar. For example, a person using a bank’s mobile app should experience consistent semantic structures when using the bank’s website or calling the bank’s phone-based service. While the capabilities and limitations of each channel are different, the language structures employed in each should let the user know that they are dealing with the same organization. In order to do so, the semantic structures must be abstracted from actual implementations.

Systems thinking

The third key principle is that information architecture is a discipline focused on describing systems, as opposed to the parts of a system. You can’t design products and services that work effectively and consistently across various interaction channels if you don’t understand how they interact with and influence each other and with various other systems that affect them. 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. Polar bear co-author Peter Morville’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. As a discipline, information architecture is ideally suited to thinking about these problems at a high level, systematically.

I must say this upfront before I scare you off: when I talk about systems thinking, I’m not suggesting that we need to design these systems upfront. We’re well aware that designing large-scale systems in one go is a fool’s errand. The best expression I’ve seen of this idea is Gall’s Law, which was postulated by systems theorist John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.

Design is an iterative activity. The process of defining a large, complex system begins with a focus on a simpler, core system that evolves naturally over time as it comes into contact with real users, business conditions, and the constraints and opportunities inherent in the design and development process. So I don’t see systems thinking and agile methodologies as fundamentally opposed.

That said, 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, another challenge for which IA is ideally suited. In his book Introduction to General Systems Thinking, computer scientist Gerald Weinberg uses a short story to illustrate what he calls fallacies of absolute thought. The story goes like this:

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.”

So you need to 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 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. With its focus on systems instead of individual artifacts, 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.

So, three principles: places made of language, coherence across contexts, and systems thinking. In addition, we have also identified two key goals that information architecture strives to solve for. They are: making information findable, and making it understandable.


Let’s start with making stuff findable. When we talk about findability, we mean facilitating people’s access to the information they need. Findability has been within the purview of IA from day one. The foundations for our perspective on findability is based on the field of Library Sciences and the work of pioneers like Marcia Bates. I would venture that most people who know about IA think that structuring information for ease of retrieval is the primary – if not exclusive – purpose of IA. Much of the first edition of the polar bear book was focused on findability, and making information findable has been central to our discipline’s engagement with the zeitgeist thus far.

That said, it’s important to acknowledge that IA is not just about creating taxonomies, configuring search engines, building synonym rings, defining metadata, and all the other wonderful tools that we have to make information easier to find. Findability is not an end in itself. Central to the work we do is the realization that people use the products and services we design because they have an information need. It may be that they need to file an expense report in their company’s intranet, or perhaps are looking for details on the cancer that their parent has just been diagnosed with. Findability is about solving human needs through access to information. It is our job to facilitate that access. This is what I refer to as the “information” focus of information architecture.


Now let’s talk about understanding. As it applies to information architecture, I see understanding as creating a framework within which information is presented, which sets information in a particular context. One of the many things I’ve learned from the work of Richard Saul Wurman is that we only understand things in relationship to other things. The frame around a painting changes how we perceive it, and the place the frame is hanging in changes it even more. For example, we understand an image displayed in the Walker Art Center differently than one hanging in one of the bathrooms in this hotel. So context matters. Place matters. When designing an information architecture, we are engaging in a new type of placemaking: one that alters how we perceive and understand information.

When you visit a bank’s website and peruse its navigation structures, headlines, section headings, images, and other information elements, your senses and nervous system are picking up semantic cues that tell you that you are now “in a bank.” You would be hard-pressed to confuse the bank’s website from that of a hospital. Just as you can tell the difference between a bank and a hospital in the real-world by picking up on features of their respective physical environments, you can tell the difference between a bank’s website and a hospital’s website by picking up on semantic elements of their user interfaces. You understand the information presented in the site differently because you see it framed as “a bank”. It is our responsibility to frame information so that it can be understood correctly, regardless of the context it is being accessed in. This is what I refer to as the “architecture” focus of information architecture.

Information architecture is distinct and valuable

So three principles: places made of language, coherence across contexts, and systems thinking. And two goals: findability and understandability. These are unique characteristics that make our discipline distinct and valuable. No other design discipline has this particular focus. And importantly, these principles and goals are independent of particular technologies. Today we’re still abuzz about smartphones with their everywhere-access to the net and touch-based paradigms. But we can already see that voice-driven interfaces like Siri are going to be a big thing, and if you believe the hype, soon we’re all going to be wearing devices with screens that make yesteryear’s smartphones look luxuriously roomy. And of course, networked devices keep getting smaller and cheaper, permeating our physical environments and adding smarts to connected doorknobs, thermostats, cars, and all sort of unexpected everyday tools both on our bodies and our surroundings.

These devices need to interoperate among themselves — and with us — and they will generate and collect unprecedented amounts of data. Issues like privacy, the relationship of the individual to society, and our systems of governance, are under tremendous strain as a result of these changes. These technologies can either empower us through previously unattainable insights into our collective and individual patterns of behavior and increased engagement with the social fabric, or can serve as tools of unprecedented oppression and inequity. Given the nature of our zeitgeist, it is not enough for designers to focus on the design of individual artifacts. Our challenge – our responsibility – is to help ensure that these brave new information environments – and many others we can’t even imagine now – serve human needs first. Because of our particular focus, I believe that information architecture is uniquely suited to help us engage these challenges in a meaningful way.

Information archtiecture is for everybody

It’s on us to find ways to make this case compelling and clear, both to ourselves and to the world in general. For a good example on how to do this, see IA Institute president Abby Covert’s new book How To Make Sense of Any Mess. It’s subtitle – Information Architecture for Everybody – perfectly captures the essence of the mission we are on: making sure that people in all walks of life understand that IA is about meeting human needs through better access to information.

I’m going to start winding down this talk now, but I’m not planning to wrap up my exciting/terrifying story. You see, I still don’t know how it turns out! It’s still evolving. A little over a year ago, my family and I moved to California, and I’m now working as a partner in Futuredraft, a digital product design consultancy in the Bay Area. Like other big changes in my life, this one has been a exciting, yet also a little scary and disorienting. Before moving to California, I’d been told by friends that IA was barely discussed there anymore. This was disconcerting, because the most important and influential information environments in the world are being created there. In my experience, the situation is less daunting, but I still sense echoes from that earlier part of my career when I knew I had the answers to questions people were about to start asking. To me, the signs are clear: advances in technology keep changing our context at an ever-faster pace, driving us toward ever greater interconnectedness. As a result, we are hitting the limits of artifact-centric thinking in our increasingly ecosystem-driven world.


Change can be scary and disorienting. It’s also inevitable. But if you go back to examine your core principles, and realize those principles are fundamentally sound, you can more easily see how they can help you best create value for people by engaging the zeitgeist. I believe that the need for designers who can think systemically, who can create these places made of language that work well across contexts, is becoming more important every day and will continue to do so. And when mobile apps are no longer where it’s at, and long after the phrase “Internet of things” sounds as quaint as “horseless carriage,” people will still need to find information, and understand it once they do.

Information architecture

So you could say that I’m doubling down on information architecture. I believe that the world needs thoughtful people working to ensure that information environments serve human needs. Those people are in this room. But they’re also out there in the world, self-identifying as user experience designers, interaction designers, product managers, content strategists, and a whole range of other titles. Many of these folks don’t yet understand why they need to know about information architecture. It’s our job to help them do so.

So now I invite you to enjoy the rest of the Summit. As you attend presentations and participate in hallway conversations over the next few days, I ask that you put our principles and goals to the test. How is what you’re hearing conducive to effective placemaking? Does it work well across contexts? Is it considering the big-picture, whole systems perspective? Does it primarily facilitate finding, understanding, or both? Discuss these issues among yourselves, and – more importantly – in public, with your peers and colleagues from other disciplines. Thank you!


Thanks to Andrew Hinton, Peter Morville, and Louis Rosenfeld for providing feedback on drafts of this speech. 

Give a hoot! Mapping (and caring for) the semantic environment

I delivered this presentation at the 2014 IA Summit in San Diego, California.

En Castellano: El diagramado y cuidado del entorno semántico

Presentation Summary:

Before an architect designs a building, she must first understand the environment it will be designed for: the plot size, shape, and location, the conditions of the ground, exposure to the elements, access to essentials like water and sewage lines, traffic patterns, and more. Only after she’s carefully measured and analyzed the place can she propose a meaningful and practical intervention.

Information architects must also understand the environment we will be designing for. However, ours is not a physical environment but one made of signs: instead of earth, vegetation, roads, and neighboring buildings, we deal with words, ideas, rules, roles, and relationships. Ours are semantic environments, and just like architects do, we must thoroughly understand them before we start proposing designs that change them.

This presentation will introduce the concept of the semantic environment, as it has been developed in the field of general semantics, and will teach you a method for mapping the various semantic environments that affect your project. I will argue that one of the information architect’s responsibilities is to avoid polluting these environments (“Give a hoot!”), and will show you specific ways in which you can do this. I will also present a case study that explains how this technique helped in the creation of a multi-channel information architecture for a service-focused organization.

In this presentation, you will learn:

  • What the semantic environment is, and why it’s important to your projects.
  • How to avoid polluting the semantic environment.
  • How to create a map of your project’s various semantic environments.
  • How that map can inform the design of a cross-channel information architecture.
  • How my team helped develop a cross-channel IA for a service-focused organization by using this technique.

En contexto

(In Spanish)

I delivered this presentation at the first Experience Design Summit in San José, Costa Rica, in September 2013.

Presentation summary:

We can’t talk about design without in the 21st Century without talking about information. The majority of products and services that we interact with are part of information environments that teach, entertain, guide, and influence us. This presentation examines the importance of context in the way that users understand and navigate information, and what we can do to create more successful information-based solutions.