The pain in a name — Is information architecture right to call itself architecture?

I have long felt uneasy about modern occupations associating themselves with high-status traditional professions.

This issue has been brought into sharp focus for me since I started a role last year focusing heavily on information architecture. While I have always done information architecture as part of my job, now I specialise in it more deeply than before.

So now, when someone asks me what my job is, I’m likely to say I am an information architect. (My actual job title is lead content designer. But I am not entirely comfortable with that either, for reasons that might become the subject of another post.)

Actual architecture

I describe my work as information architecture to the annoyance of my wife Alex, who is an actual architect.

Actual architects face a high bar before they are allowed to call themselves architects.

They must first study for five years to earn a master’s degree. Additionally they have to complete at least two years of work experience. They then must pass a written and oral exam before finally earning the title “architect”. Thereafter, they must annually pay membership dues (typically hundreds of pounds), and record a good amount of continuous professional development, to retain the continued right to call themselves an architect.

I can simply add the word “information” in front, and — ta-da — I am an information architect. OK, there was a bit more to it than that. But I understand why actual architects might be irritated.

The problem goes far wider than information architecture.

What is an engineer?

Software engineering is a classic example. Apparently design engineer is becoming a more common job title as well. There is a fine debate to be had over whether computer programmers or software developers or designers can reasonably call themselves engineers.

A 2015 piece by Ian Bogost in the Atlantic summarises the arguments against:

Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver.

The article goes on to argue that the adoption of the word “engineer” by the technology industry is a cynical ploy to engender trust vicariously, without earning it.

No trustworthy engineering firm would have ever used the motto: “move fast and break things”.

Software engineering certainly doesn’t hold itself to those high standards. Even if it possibly ought to.

I was once involved in user research with a professional association of engineers. I found out it’s a bugbear of many that the title has not been as well protected as they think it should be.

Another argument says: traditional engineering works within knowable, largely fixed constraints, requiring up-front planning. Software development normally works in uncertain conditions, and must be responsive to change amid unpredictable discoveries.

Some technology-oriented people happily emphasise that this requires an agile approach. Unaddressed is the contradiction in simultaneously ascribing themselves the title of engineer. A traditional engineer would, by necessity, follow the forbidden waterfall approach.

One interpretation of this line of thought is that software development is actually more difficult than traditional engineering.

The views of software engineers and engineers

Hillel Wayne published an analysis of similarities and differences between traditional and software engineering. It included interviews with 17 people who have worked in both.

You should read the article in full. But to summarise, Hillel Wayne found that it is nearly impossible to define what engineering is — just that engineers know it when they see it. 15 of his 17 interviewees considered software engineering to be engineering.

But one fact is given little attention in the article, even though it seems notable. Each of the 17 interviewees had become software engineers after they worked as a traditional engineer. None of the interviewees had started as a software engineer before becoming a traditional engineer. I struggle to imagine there are many who make that leap.

I can think of a few interpretations of this. Maybe it’s because software development is heavily in demand.

Perhaps it’s because the barrier to entry in traditional engineering disciplines is too high. Taking so many years out to study in the middle of your life might be too much to stomach. It’s an investment you can more comfortably make when you still have your whole adult life ahead of you.

But maybe, just maybe, it’s because traditional engineering is harder.

But is it wrong as a metaphor?

Even if engineering is harder or more important, would that still make it wrong for software developers to use engineering as a metaphor?

After all, it is common for abstract technology concepts to adopt metaphors to make them understandable. In this light, the phenomenon is a skeuomorphism of job titles.

But it is typical that we tend to adopt words like engineer or architect — aspirational professions with high barriers to entry. Jeremy Keith gave a talk, worth reading in full, that wondered if we ought to adopt a more humble metaphor like builder or bricklayer.

The first information architect was an architect

People doing the work of information architects in the earliest stages of the internet era didn’t really know what to call themselves. Peter Morville told a story that the problem of figuring out how to organise increasing volumes of information was known as: “the pain with no name”.

Information architects can seek refuge in the fact that the term was introduced by an actual architect, Richard Saul Wurman, way back in 1975.

(In fact, the first known use of “information architecture” came in the mid-1960s, although this early use seems closer to what we now call systems architecture.)

50 years have passed since then. But it seems that Richard Saul Wurman’s ideas — while perhaps ahead of their time — did not gain much traction until the 1990s.

By then, a new generation was grappling with the problems inherent in making information findable to people. People were working with increasingly sophisticated computer systems, amid an explosion of the availability of information, particularly through the world wide web.

Many of those web pioneers started adopting the architecture metaphor, apparently unaware that Richard Saul Wurman had already done so. Not many people latched on to Richard Saul Wurman’s ideas, which had been surpassed by the needs of contemporary technology.

Peter Morville, one of the 1990s’ information architecture pioneers, said of Richard Saul Wurman:

After reading his book, I remember thinking ‘this is not information architecture, this is information design’.

Andrea Resmini and Luca Rosati noted that, while for web-era information architects their discipline was about:

…what was between the pages of a website, meaning the links, the structure, the connections… for Wurman it seemed to be the design of the pages themselves”.

Reading between the lines, it seems as though Richard Saul Wurman’s work is viewed as being concerned with a simpler problem than the ones information architects actually ended up grappling with. This is an interesting corollary to the argument described above, that software engineers sometimes tackle harder problems than traditional engineers.

Interestingly, Jorge Arango, who has contributed to the more recent editions of the Information Architecture for the Web and Beyond (“the polar bear book”, the canonical resource of the discipline), studied actual architecture at university. Andrea Resmini, another prominent information architect, also has a master’s degree in architecture and industrial design.

Discomfort with the label

Nevertheless, information architecture practitioners have long seemed uncomfortable with the label. “Information architecture” may have given “the pain with no name” a name. But it is notoriously hard to nail down a definition of information architecture that everyone agrees on.

I noted recently how the polar bear book gives four different definitions. A classic case of cobbler’s shoes.

Similarly, many leading voices of the discipline give off impressions of feeling constrained by the architecture label.

Back in 2009, Jesse James Garrett gave an influential talk in which he implored the disciplines of information architecture and interaction design, which he saw as competing with each other, to ditch those labels:

There are no information architects. There are no interaction designers. There are only, and only ever have been, user experience designers.

People listened, and the 2010s saw a contraction in references to information architecture. Everything did indeed become about user experience.

Problems with the alternative labels

The trouble with that was, over time, that meaning of user experience became eroded. That is because people see the interaction design, but don’t necessarily see the information architecture.

Even though a successful interaction design must be underpinned by a strong information architecture (as Jesse James Garrett’s own brilliant diagram, the elements of user experience, shows), outsiders don’t see that. They just see that outer layer.

So because we stopped talking about information architecture, many people forgot it even exists. Many other people are yet to discover it exists!

In the meantime, while people talked more about user experience, the biggest tech companies cared about it less. People actually wrote books about making people addicted to — sorry, I mean “hooked” on — their products.

The world’s largest tech companies, such as Facebook, sought to make it harder to find a specific piece of information. They lurched towards using opaque algorithms, making the user experience more like playing pot luck. This dopamine-driven design made people addicted to information environments, without actually improving their ability to find information. It certainly didn’t improve people’s lives.

So we ditched information architecture as a label, then saw user experience gradually take on different meanings. The pain with no name still has no name!

Moreover, it is perhaps a greater pain than ever. We grapple for the leverage to solve the pain, and it may be because we still grapple for a name.

Abby Covert calls herself a sensemaker.

Jorge Arango wondered out loud if we should be “content-oriented UXers”.

Some of the greatest advances in the framing and language of our profession in recent years have come from Sophia Prater. Her excellent training programmes build on decades-old ideas from information architecture and adjacent fields like domain-driven design. This is breathing new life into the whole lot of it. She calls it Object-Oriented UX. I’m a huge fan of it.

These alternative labels are all very well. But they risk obscuring the need to focus on organising information to make it more findable.

The decline of information architecture is harming us all

The Google Books Ngram Viewer, which traces how often phrases have been used in books over time, tells a stark story about information architecture. From its first use in 1964, to slow growth from the mid-1970s, information architecture expanded steadily through the 1980s and 1990s. It then burst rapidly, in parallel with the world wide web. While a mid-noughties plateau occurred after the dot-com bubble burst, it resurged to a peak in 2012.

Since that point, it has receded to a level last seen in 2000.

Do we believe that people’s information needs have not increased in the past 25 years? Amid an explosion in the variety of devices, information platforms and output channels, all pumped full of search engine optimised drivel, try-hard content marketing, misinformation, disinformation and machine-generated slop en masse? I think not.

(Clue: These are the reasons why using Google is such a miserable experience compared to a few years ago.)

This instead ought to be the impetus for us to start talking with pride again about our discipline’s ability to organise information. At a time when it is harder than ever to discern trustworthy sources of information, we have the ability to help people find what they are looking for more easily. At the same time, we can help organisations manage their information more efficiently.

In short, we help people find things.

How about information cartography?

Speaking of helping people find things, sometimes I feel like our work is more like cartography — mapmaking. We study how people conceptualise an environment, and figure out what they need to know about it. Then we represent it in an abstract format that is intended to be easily understandable.

Interestingly, Richard Saul Wurman also thought of this. He defined the practitioner in our field as:

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

The map metaphor has been more readily used by user experience and service design practitioners, who commonly create journey maps. These maps often depict a linear, one-dimensional journey that goes neatly from start to finish.

Everyone knows that journeys are more complex and multi-faceted than that. A journey map is a synthesis of multiple perspectives boiled down to one. This is a deliberate simplification, made in order to tell a powerful story that makes the case for change.

It’s also because it is impossible to visualise the messy complexity of real-world diverse perspectives on a sheet of paper, an arrangement of sticky notes or even a digital whiteboard.

Information architects sometimes bristle at the notion of a “sitemap”, because it is most commonly associated with a top-down one-dimensional hierarchical site-structure. It normally fails to convey the realities of the relationships between different parts of information. It certainly struggles to communicate the possibilities modern digital systems give users to slice, dice, sort and filter through masses of information in multiple ways to find the one piece of information they came for.

Real maps work because, as complex as the real world is, it is still bound by the laws of space and time. This makes it relatively straightforward to understand it in a two-dimensional representation — a map.

A strong information architecture is not one-dimensional, or even three-dimensional. It is multi-dimensional, multi-faceted and polyhierarchical. The map metaphor fails us here.

This brings me back to considering information architecture as the name of our work.

Seeking forgiveness from actual architects

Back in 2010, Amanda Kolson Hurley, writing in Architect magazine, had reached the acceptance stage in the Kübler-Ross grief process.

She noted the prominent people bridging the two disciplines: Richard Saul Wurman, Andrew Hinton, Andrea Resmini and Jorge Arango. The latter saw a strong connection between actual architecture and information architecture:

People would be experiencing these mental spaces — which is how I saw a website — and there should be someone in charge of making sure that the design program behind those spaces got executed in a coherent way. Conceptually, there seemed to be a relationship between the two fields.

The article goes on to consider software architecture and IT architecture. This may be my bias, but I feel like the interviewees in these sections failed to make as strong a case.

Regardless, it seems to boil down to this: Architects never fully owned the word anyway.

…the second definition of the word in the Merriam-Webster Dictionary: “a person who designs and guides a plan or undertaking (e.g. the architect of American foreign policy).”

Plot twist: Richard Saul Wurman says it is this meaning he was thinking of when he came up with the phrase information architecture, even though he is an actual architect.

Despite the discomfort we feel about it, no-one has come up with a better label to describe our work. Moving to alternative labels like user experience has backfired. The best resources have called it information architecture for decades. For better or worse, most people who have a sense of what information architecture is, also have a sense that it is called information architecture.

For all its problems, using these two words seems to give the best chance of other people understanding what we’re talking about. If that’s what matches people’s mental models, we’d better adopt it.

Now can someone help me explain all this to Alex?

---