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

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.

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:

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.