When IA fails (Spilling Ink #6)

Spilling Ink is the monthly newsletter from from Curious Squid, Dan Brown’s IA and UX design agency based in Washington, DC

Watercolor by Sarah Holden

I won’t mince words. I’m worried about the future of information architecture. There is a need – a clear, urgent need. But the at-large UX and product design community lacks an awareness of what information architecture can do.

Jorge says that part of the problem is that information architecture doesn’t have a clear object. That is, it’s not readily apparent what information architecture designs. Other fields of design have clear objects, like conventional architecture for which buildings, edifices, houses, and other constructions are the object.

My take is that the object of information architecture is the virtual structure.

But, I do agree with Jorge’s other observation, that information architecture is “inherently abstract”. Virtual structures are not easily pictured or manipulated. I understand that my capacity to visualize a virtual structure is something I’ve cultivated over the years, and not everyone has the need or interest or inclination to do so.

Because the object of information architecture – the virtual structure – is difficult for people to envision and understand, problems appearing in structures may not be readily apparent. Problems with a structure may appear to be problems with something else in the user experience.

Recognizing IA problems

One of the questions I will spend the rest of my life answering is “how do we know a structural problem when we see it?” What are the hallmarks of structural failures? What observable symptoms tell us that there is a “problem with the IA?” Can they even be observed?

Information architects are often called in at the very beginning of the design process. Since we’re seen as a close analog to conventional architects, people working on digital products and spaces see our role as planners – the designers who put the ideas down on paper before building.

We’re sometimes called in at the very end, after the product has shipped. Teams perceive the need to rework (renovate?) the structure of a virtual space when their product has long outgrown it. A site’s content no longer fits correctly on its virtual shelves. When I meet teams in this circumstance, they’re ready to scorch the earth.

But there are problems that occur in virtual structures that need an information architect’s eye even after the product is launched, and before it’s outlived its utility. Here are a few examples of IA problems that don’t require starting from scratch.

• New content has no clear home

• Content not getting prioritized or exposed

• Users not getting to important pages

• Users not completing a flow

• Business needs to add a new feature

• Users bending a feature beyond original intent

Ripping out the whole structure for any one of these problems is excessive. If they seem big, it’s perhaps because they are about the structure of the product. But in virtual spaces, even structural problems can be self-contained.

Dispelling myths

“All IA problems are big problems” is a common misconception about information architecture. Another is that we information architects only have one trick up our sleeves. In fact, having a variety of tools at our disposal means that we can come up with an intervention that minimizes the impact to “experience debt”.

That is, like any intervention, a structural intervention can create or exacerbate problems later. This isn’t a hazard of information architecture specifically, but all work on technology. And so, as with any expenditure of effort, the team must weigh the trade-offs of different interventions to find an acceptable risk for solving the problem.

Less invasive interventions

So, your information architect has a role to play after a product is launched, but before it is scrubbed.

Here are a few low-effort interventions that information architects can help with:

• Incorporating local navigation component

• Incorporating related content component

• Refining business rules for displaying content

• Adjusting controlled vocabulary

• Altering category labels

• Incorporating signposting in navigation menus

• Mapping new feature data needs to existing structure

These are interventions on the structure itself. They are not cosmetic changes, but they may have an impact on how the product looks. These are simple modifications, but not so deep as to alter the fundamental structure.

The advent of machine learning and generative artificial intelligence puts additional pressure on teams to ensure the underlying structure of their data is robust and reliable. In this pivotal article, Jorge reminds us that IA isn’t being replaced by AI, and AI needs information architecture. He explains that AI can help information architects do their work better, but it cannot yet replace a human’s ability to organize information, set context, and plan for change – the essential activities of IA.

As more stories of artificial intelligence emerge, we will see more cases where an information architect might intervene, and we will have an increasing sense of what those interventions look like. On the flip side, we will also have to recognize new symptoms of structural problems, or even new kinds of structural problems. The challenges I listed above might have something in common with each other, some underlying rule or characteristic that marks them as structural.

If they do, it’s hard for me to see it. I understand that these are structural issues, and I keep a running inventory of issues that are structural, but I would be hard pressed to define structural issues as a whole. Practically speaking, that may be OK. For now. But in the future it will become increasingly important for us to understand and recognize what a structural problem looks like.

New! Curiosity Brief: Marketecture

In addition to these informal essays in the newsletter, I’d like to develop a library of more formal papers to explain important challenges in information architecture.

The first of these is on marketecture, the structure of a company’s offerings and product catalog. Here are a few sample pages from the full Curiosity Brief:

Side Project Updates

It’s been about eight weeks since my last update, so there’s much to report:

• Podcast: Don’t tell anyone, but we quietly dropped our pilot episode. More to come.

• IA Writing: Between January and today I produced the Curiosity Brief on Marketecture.

• Trade-offs: The podcast has taken a lot of work, but I’ve also been working on slides for my Trade-offs session at the IA Conference.

Webinar: Build Your IA Playbook

There’s still time to sign up for the next webinar on Building Your IA Playbook. In this FREE session, I’ll cover how to model a domain, one of the most requested techniques in the playbook.

March 21 - 3pmET
🖥️ Webinar: Building Your IA Playbook - Model the domain
By popular demand, how to create a concept model

IA Conference 25

I’m excited to be attending the IA Conference again, and honored that Curious Squid is sponsoring. This year it’s in Philadelphia April 29 - May 3.

I’m on the program:

Product IA workshop: A full-day session dedicated to applying our IA skills to the design of products.

Trade-offs: A 30-minute talk digging into a decision-making framework for information architecture.

Hey, if you attend, come find me and mention this newsletter (Spilling Ink). If you do, I’ll give you a free copy of IA Lenses.

Let’s Talk!

Have some burning IA problems you need to talk out? Schedule time with Dan.

• Our current projects are wrapping up soon, and we’re actively looking for our next engagement.

• Consider us for information architecture advising or projects, user experience research and design projects, or fractional design leadership.

Thank you!

Thanks for reading! In these difficult times, it’s important to me to stay connected to the IA and UX community. You can help me do that by sharing Spilling Ink with a colleague.