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