Architects Everywhere

I am so proud to be standing here, on the fifth anniversary of World Information Architecture Day. Congratulations to the team here in Zürich for putting together such a stellar event for us.

As one of the founders of this event I have enjoyed seeing this community grow and change over the last 5 years to include people from all walks of life and perspectives on what IA is and why it is important. We have engineers and librarians, user experience designers and product managers, academics and marketers — all brought together around one simple idea: Information architecture.

The reason I believe in this event and have committed my career to teaching and practicing IA is simple:

I believe in information architecture.

Not just as a job, or an industry, or an academic specialty. I believe in information architecture as a life skill. I believe that IA is not a fad or a trend or a pattern or something that emerged to deal with the complexities of working on the web. Instead, IA is and has always been a fundamental part of how we communicate with one another. I also believe that IA is not something that was invented as much as it was something that was named. Information architecture is something we have always done as humans, we just keep changing the ways we practice it to make sense given the information and media we have to work with.

I am here today to convince each and every one of you that information architecture is a critical life skill that you already use in your work and play everyday. Regardless of what you do to pay your bills, what title you write on your business card or how you spend your free time: you are using the principles and concepts of information architecture to make things clear to other people.

When was the last time you decided how to label something in the world around you so others could find or use it? When was the last time you made a group of similar things for the ease of a task or someone else’s understanding? When was the last time you created a system of rules for how something works or ought work?

Maybe your answers are from your work life. Perhaps you were asked to propose the ways in which a user is able to navigate a product or service. Maybe your answers are personal. Perhaps you reorganized the pantry in your home or designed a chore chart for your children. Either way, the same principles and concepts apply. You architected information, whether for strangers, your family or yourself.

Along with architecting information everyday, you are also the users of information that is architected by other people everyday. The signage and environmental cues that directed you here today and will tell you how to reach the exit when you leave, the cafe menu you may use later to choose what to have for lunch, the train or bus schedule you will use to get home tonight. All of these are information architectures that deeply impact the quality of your life.

When the arrangement and rules that support these moments are well considered, we don’t think much about them. But think about how you feel when you encounter something that is not clear or does not make sense. Think about how alienating it feels to be mislead, miscommunicated to or misunderstood.

This raises an important question: If we are all walking around architecting information all day, why is the world such an unclear place? Why are so many systems, interfaces and places we experience so confusing and convoluted?

In other words, why aren’t we collectively better at this whole IA thing yet?

I believe the reason is that we seldom teach people how to architect information. We leave these lessons in the realm of common sense and don’t make explicit lessons clear.

Think back on your own education. When were you taught how to label and arrange things to make them clear to other people? If you were ever taught these lessons explicitly you were likely lucky enough to be educated as a specialist in the world of library science, graphic design, wayfinding design, technical writing or information design. But so much of this world is not architected by specialists.

How are the rest of us supposed to find out not only how to do these things but also how critical thinking about those decisions is?

In 2013, I was preparing to interview Lou Rosenfeld onstage at World Information Architecture Day in New York City. While doing my homework for the interview, I had the chance to speak with Peter Morville about the rise of IA as a field of practice.

 

He told me that before the term “information architecture” was popularized, people referred to something called “the pain with no name.” This term was meant to describe the issues that arise that are not visual nor technological. Instead this term described problems of understanding.

The phraseology of “the pain with no name” is powerful because it properly captures the anxiety involved in making structural and linguistic decisions. It is messy, painful, brain-melting work that takes a commitment to clarity and coherence.

Everyone has dealt with a situation where the pain with no name has reared its ugly head, leaving disinformation and misinformation in its wake. In your own work you may have heard or thought things like:

• “Our marketing team has a different language than our technology team.”
• “Our users don’t understand the language of our business.”
• “The way this is labeled or classified is keeping users from finding or understanding it.”
• “We have several labels for the same thing and it gets in the way.”

These pains persist on every project; disagreements about language and structure often go unresolved due to a lack of clear ownership. Since they’re owned and influenced by everything from business strategy to technical development, it’s hard to fit these conversations onto a Gantt chart or project plan. IA discussions seem to pop up over the course of a project like a game of whack-a-mole.

When I worked on an agency team, it was quite common for copywriters to want responsibility for coming up with the final labels for any navigation system I proposed. They rightly saw these labels as important brand assets. But it was also quite common for us to learn through testing and analytic reports that these branded labels were not performing as expected with users. In meeting after meeting, we struggled and argued over the fact that my proposed labels—while more to the point than theirs—were dry, boring or not “on brand.” Sometimes I won these arguments, but I was usually overpowered by the creative team’s preference for pithy, cute, metaphoric, or irreverent labels that “better matched the brand.”

In the worst incident, the label I proposed made sense to 9 of 10 users in a lab usability test of wireframes. The same content was tested again following development, but was now hidden behind a cute, branded label that made sense to 0 of 10 users in the same lab environment. Ultimately, the client was convinced by the creative team that the lab test had biased it in this direction. Once we had a few months of analytics captured from the live site, we saw the problem was, in fact, real. It was the first time I’ve ever seen 0% of users click on a main navigation item.

Seven years later, that label is still on the site and no users have ever clicked on it. The client hasn’t been able to prioritize the budget to fix it since they need to pay for campaign-based work (much of which is ironically hidden behind that cute but confusing label). This was the first time I fully understood how much of my job is to teach others to consider IA and not just listen to my recommendations around it.

I fear that we have become lost in a war of dividing responsibility. Clarity is the victim in these battles.

The lesson I have learned time and again is that it doesn’t matter who comes up with the label or who decides how something is arranged. What matters is that someone thinks about it and decides a way forward that upholds both clarity and intention.

There is more information swirling around in the world than ever before. There are more channels through which we disseminate content. There has never been such a pressing need for critical thinking about structure to ensure things make sense. Yet, I believe that the pain with no name is experiencing a second coming.

 

Fact: Most people practicing information architecture have never heard the term before.

I believe that this is why we aren’t collectively getting better at this important practice. In too many cases, educational programs in design and technology have stopped teaching or even talking about IA. Professionals in the web industry have stopped teaching their clients about its importance.

I truly believe that the need for clarity will never go out of style, and neither will the importance of language and structure. We will always need to have semantic and structural arguments to get good work done.

But there are some misconceptions that need to be addressed if we are going to deal with the reality of the impending “tsunami of information” approaching our shores. Today I would like to debunk four of these misconceptions for you:

 

Misconception #1: IA is UX / UX is IA

The number one question I get from folks is around the relationship of IA to UX. Are they synonyms? Is UX the new term for IA? Are IAs needed if UX people are involved? In the design and technology community I see these questions being asked in curiosity, but often met with frustrated answers by those sick of the swirl surrounding this conversation.

I worry that the DTDT-phobic amongst us are alienating a whole new generation that is starting to feel the pain with no name and asking important questions about how to make their work clearer.

The prevalence of these questions and the commonality of not wanting to answer them concerns me because it says that we within the design and technology community are lacking a clear controlled vocabulary about two critical components of our work. As an IA I see a clear ontological dilemma here. How can we teach the next generation if we don’t know what we mean when we say what we say?

I am going to attempt to break this down for you with hopes that you can be like an army of sensemakers taking on this misconception in your day to day.

Does someone called a User Experience Designer practice IA? Yes. These folks are often relied on to determine the language and structure of the environments they are designing the experience of. They often share this responsibility with content creators, copywriters, product managers, developers and marketing folks.

Does someone called an Information Architect work on user experiences? Yes. The choices an IA specialist makes in labeling and structuring things deeply impacts the user’s experience. Interfaces and processes that are built by others on top of these architectural choices reflect those choices and therefore deeply impact the user’s experience as well.

Is IA the only skill-set a User Experience Designer needs? No. User Experience Designers are asked to research, design and execute more than just the language and structure of an experience. They are asked to consider everything down to the componentry, microinteractions and visual design of the experience. They are also often responsible for building the interfaces either for prototype or production of these experiences. All of these things can impact the IA, but to say that UX designers only do IA would be a misnomer.

Is an IA specialist capable of doing everything a User Experience Designer does? Not in most cases. An information architecture specialist is likely to feel pretty out of their depth when things get closer to the interface level. Asking an IA specialist to complete the interaction design or visual design of the interface is like asking the architect of a building to do the interior design, construction and finishing carpentry. Some of them like it, some of them are good at it but many are not qualified and want to stay far away from this work.

Are IAs needed if UX designers are involved? Sometimes. As an IA specialist, I work with teams of UX designers who want someone to focus specifically and deeply on the structural and linguistic decision-making part of a project. I tend to work on large and complex assignments. UX designers are completely capable of doing this work, as are engineers, project managers, product managers and many other job titles. I am not magic. I am not special. The only difference between me and the folks who hire me is generally I am not as afraid of some of the large hairy messes out there in ways that people who do not specialize in IA tend to be.

The most common reaction I hear from answering questions like this is:

Isn’t this just mincing words? Does it matter if people conflate these two skills?

Well, I think talking about the differences is important because I believe that the conflation of these things is lowering the likelihood that people being trained and educated in UX will also be educated in information architecture. I worry that they are not often taught to semantically argue or to facilitate conversations about language and structure with clients and partners. I worry that they are not often taught the importance of documenting linguistic decisions or the ways in which a strong taxonomy should be thought about, documented and executed.

These weaknesses in education lead too many UX Designers to do more rework at the interface level. Because we use the tools we know to solve the problems we have. This turns into an increased number of versions of things like wireframes, prototypes and functional specifications.

So is IA really UX by another name or the other way around. No. IA is a critical skill within UX but it is not the same thing. Just like we have to work on a UX designer’s research skills or prototyping skills, we need to work on a UX designer’s sensemaking skills.

Misconception #2: IA is hierarchy, and hierarchy was killed by search & social media

Information architecture is primarily concerned with structure and much of the world is structured as a hierarchy. So it is easy to conflate one to mean the other. In terms of the web, there has been a trend away from the display of broad and shallow hierarchies as a horizontal bar across the screen. There has been a trend to move away from left and right hand navigation that runs down the interior pages. But this is akin to the residential architectural world moving away from formal living rooms in favor of open floor plans. There are still structural decisions being made, and labels being assigned to those places so users know what to do there. There are still rules dictating when users see what options. And guess what?! Whether your navigation is splayed across the screen as a bar or hidden in a hamburger menu, you are still designing a hierarchy. When you decide that your whole site is one single scrolling page, you are still designing a hierarchy of information, what goes first, next and last.

So hierarchies are not dead. In fact they are still the most prevalent pattern for how we arrange everything from grocery stores to websites and apps to people within an organization.

Search and social media added a complexity to the design of digital hierarchies. Making it possible for users to “appear” at any level to start their experience. It’s sort of like if all of  sudden you could appear in aisle three of the grocery store instead of having to use the designated entrance. This is complex to think about and as a designer, adds to the set of concerns you have in terms of making context clear to users on arrival, but it in no way makes the hierarchy no longer a hierarchy.

Outside of the realm of hierarchies, information architecture is an important set of considerations for getting your search to behave itself and deliver good results. Ask anyone who understands search and they will tell you that some of the key ingredients they rely on are a controlled vocabulary, synonym rings, object models to define the relationships terms and content have to one another and an understanding of the natural language users will use to navigate the content being searched. The lack of attention to these things is what makes so much of the world’s internal search engine implementations so ineffective.

Misconception #3: You cannot practice IA in an agile or lean-startup environment

When the language and structure that you are working on is critically thought about before the execution begins, time and money is saved. It’s an undeniable truth. But how does this apply when you are in an environment that is working quickly and without time to think before the making begins? I have had the pleasure to work with a few agile and startup environments and I think I have an answer for this. Talk about IA.

Don’t leave semantic and structural arguments unresolved. Take the extra few minutes needed to write down what you mean when you say what you say when defining a sprint for a new feature or when deciding what to call something in the database. The goal of Agile and Lean Startup organizations is to build something, something good enough that it can turn into something valuable and viable. If you, like too many of my clients, spend your first few years as a business throwing around language and structures in the silos of sprints without talking about it strategically, you will have a moment when it starts to hold you back.

These seemingly tiny decisions about where to put things and what to call things are not as impactful individually as they are when you add them all up.

Like barnacles on ships, you can sail around with quite a few of them without noticing the drag. But there will be a moment where if you don’t send someone down there to scrap them off, you will losing the speed that once defined you. It’s ironic but true: your speed will eventually slow you down.

Misconception #4: IA is a phase on the project plan

I left the largest and most prevalent misconception for last. Look, I will be honest with you. I wish IA was a set it once and forget it type of activity. My life would be easier. I have even tried to practice this way. But it just isn’t effective. The act of shaping an environment to be understood by other people involves a commitment to iteration and fluidity with other disciplines that conflicts with the idea that IA tasks can be taken on at the beginning of a project and held up as the gospel thereafter. There are a few ramifications that this misconception carries with it:

1. IA practitioners feel like their work is thrown away by others down the line. If you look at IA as something that should be set up front and never touched again you put IA practitioners in a tough spot. In places where IA is seen as a phase it becomes a battle of us vs them, as is well illustrated in my example earlier about the disagreement I had with my copy writer about the labels making sense to users. If we had looked at IA as something that was being fluidly discussed instead of something to be handed off, we could have been more successful.
2. Organizations are distrustful of IA if things keep changing unexpectedly. If you position IA as a project phase that is completed ahead of other steps, and then things change. The process, or even worse the person, might be questioned in its validity.  As I mentioned, we are not magic. We cannot predict the future rabbit holes the team might fall down or the changes in heart, mind and development platform that might impact what is being made clear. All we can do is listen, be present and help to filter out the noise so that clear solutions can be heard.

Do I think we need to think about IA upfront? Yes. Do I think that IA needs to be set in concrete before all other tasks? No. I think we need to have the ability to be flexible in the language and structure we are recommending. I think we need to not be protective of our ideas as things change.

Now that we have all those misconceptions out of the way, I want to ask for your help.

The first step to alleviate the pain with no name is to name it so it can be taught and discussed. Because un-named things are harder to wrap our head around. They remain monsters in our closets instead of tools in our workbench. So I have some ideas of how you can help.

When a structural or linguistic decision is being discussed, call it out as information architecture. Give people the label they’re searching for to describe the pain and anxiety being faced. If there is a semantic argument to be had, have it and make sure those you’re arguing with know the impact of leaving such things unresolved.

Teach others about the ramifications of IA decision-making. Warn your co-workers and clients that IA is not a phase or process that can be set once and forgotten. It’s an ongoing discussion that can be impacted during any stage of the work.

Share your IA struggles with colleagues and peers so our community can grow from our collective experiences. The next generation needs to hear our trials and tribulations, they need to know we still struggle to define how to make things clear. They need to know that experiencing anxiety and struggling to define things is part of the work.

Before I take some questions I want to thank you all for being here and for showing interest in information architecture. I truly believe helping people to get better at this important practice is how we can make the world a clearer place to live and work.

Happy World Information Architecture Day.