This is episode 100 of The Informed Life podcast. To celebrate, I decided to dedicate it to you, the show’s listeners. So today, I don’t have a guest. Instead, I will answer questions sent by listeners of the show.

Show notes

Some show notes may include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory.

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Listener questions have been lightly edited for clarity. See links to the original questions in the show notes.

Photo by Jose Goulau

Transcript

This is the second of these listener QA episodes, and I plan to do more in the future. If you have questions you’d like me to answer on the show, please send them via email to live@theinformed.life.

Housekeeping

Before we get on to the questions, I have two bits of housekeeping.

The first is that we’ve launched a new website for the podcast. It’s still at theinformed.life, and still features full transcripts and notes.

But the focus of the new site is speed and findability. In particular, the list of episodes now lets you find conversations based not just on date, but also by the name of guests and the topics we discussed.

Pages load much quicker and there are also quality of life improvements like dark mode.

The new site is based on a different platform, so there might be some bugs. If you find any, please let us know by sending an email to live@theinformed.life.

The second bit of housekeeping is more commercial in nature.

I’m teaching a new cohort of my IA fundamentals workshop at the end of November. Over four weeks, I’ll guide a small group through a hands-on introduction to the discipline and practice of information architecture.

It’s a great opportunity for UX and product designers who need to know about structuring websites and apps but don’t expect to specialize on IA. If you like the subjects we cover on this show, this workshop will give you the opportunity to dive more deeply.

There are only a couple of places still available, so if you’re thinking about participating, sign up today by visiting IA.WTF.

And now, on to listener questions.

Circling back to the IA

The first question comes from Vinish Garg. Vinish asks,

When smaller orgs with around 40-50 persons have validated their product and market, they see the [value] of specialized roles in design, including IA. How do they move backward from a working product to the foundational IA steps to bring more structure and scaleability-proofing to something that is already working?

If I understand the question correctly, it implies that you’ve created a system that works, but you’re considering circling back to “do it right” so it can grow later. I’m going to question the premise of this question.

There’s a lot to be said for effective structures that develop organically. Conversely, it can be difficult to plan ahead without trying to address particular needs.

One of my favorite design principles is Gall’s Law, which comes from John Gall’s book Systemantics. It says,

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

This jibes with my experience. The best systems evolve incrementally over time to meet the needs of the people who use them. It’s difficult to predict those needs in advance.

One implication of this principle is that the best time to expand the system’s information architecture is when you have a real need to do so. That may be because the organization is expanding its portfolio by releasing a new product. Or perhaps it’s acquiring a competitive product that comes with its own structures and needs to be integrated.

When integrating a new product, you can think about structural elements that span across multiple products. This sets you up for future growth, but it does so under real-world conditions and not in theory. It also allows you to measure the results of changes, so you don’t go too far in formalizing things that haven’t been tested.

It’s worth noting the difference between the actual semantic structures that are present in the product — its labeling and navigation systems, for example — and the documentation of those things. They’re not the same.

It’s useful to document the information architecture of products in a portfolio. That way, you can have a big-picture view of the distinctions and relationships between concepts in the system and avoid reinventing the wheel or inadvertently using terms in ways that overlap with what other product teams are doing.

This documentation can be produced when redesigning to integrate a new product or feature into the system. That said, this documentation can quickly become outdated. Usually, organizations don’t have anybody responsible for updating IA documents in response to changes in the product. This can lead to trouble down the line.

An analog here is building plans. Large buildings have sets of drawings that describe their spaces, structures, electrical, HVAC, and plumbing systems, and so on. These drawings save a lot of time and money if you want to remodel or alter the building in any way. But they’re only useful if the drawings accurately reflect the physical building. As a result, it’s important to update the drawings if something changes.

Something similar can be said of information architecture. Fast-growing organizations have teams generating lots of semantic distinctions. Most aren’t being formally documented in a centralized way that can be used by other teams working on similar challenges within the organization. This can be a source of trouble as the system grows.

Early adopters

The next question comes from Nigel Rawlins. Nigel asks,

One of the problems I have with tools for thought using Roam with 11K+ pages and feeding it with Instapaper, Matter and other notes is that it needs some understanding of coding. It annoys me that there is this learning curve. With new shiny ones appearing, what are non-geeks to do?

Yes, I recognize this as well. Many of the new “connected thinking” tools like Roam Research, Obsidian, etc. require a lot of tinkering. That’s understandable because it’s fairly early days for this stuff.

Well, that’s not really fair — many of the ideas behind these products have been around since at least the 1970s, mostly in research contexts. But over the last couple of years, we’ve seen new, more mainstream hypertext note-taking tools attract a new generation of users.

As happens with many tools, you can draw a bell curve that describes who’s adopting them. The classic adoption curve has five stages. First come the innovators, who are pioneering new ways of being through tools and practices.

Then come early adopters. These folks get excited by the potential latent in the new tools, processes, or whatever, and are willing to put up with a bit of pain to integrate them into their workflows. This may be because early access costs a lot of money. But it could also be that it requires specialized knowledge.

The next wave is the early majority, followed by the late majority. Ultimately, come the laggards, folks who only start using the new technology reluctantly because they basically no longer have a choice.

Many of the tools in the current tools for thinking space are still in the early adopter stage. As Nigel points out, some, such as Roam, require quite a bit of tinkering. I’m doing amazing things with Obsidian, but I’ve put in a lot of time to learning the system, installing plugins, struggling with uneven documentation, and so on.

I find it appealing to have so much control over the tool. But for the “early majority” crowd, these things represent friction. And friction hinders adoption.

It’s worth noting that it’s often early adopters who smooth out the rough points to expand the system’s appeal. So I would say, Nigel, even though it may be annoying, it’s still early days. And it’s up to folks like you and I, who are adopting these tools early, to smooth the path for others.

The use of friction

The next question comes from Digoamaje Refiloe Digoamaye. Digoamaje asks,

Can friction in getting things done be considered a good thing? I say this as I believe that when designing a user journey, for example, a point of friction can serve as a “pitstop” for a user in that they are able to reflect and learn on w/ever is they had to [do] get from A to B.

This is a great point. I do believe some things work better when we slow down.

For example, studies suggest that taking lecture notes by hand is more conducive to learning than typing them into a computer. This is at least in part because many people can type faster than they write longhand, so they tend to transcribe what they hear verbatim when using computers. By introducing a bit of friction — in this case, the literal friction of pencil against paper — you listen and capture differently.

Another example that comes to mind is agreeing to terms and conditions when going through the onboarding process for a digital app. There are competing forces at work here. On one hand, product teams want users to complete the process as quickly and smoothly as possible. On the other hand, compliance teams want to ensure users know what they’re signing up for.

If users rush through the terms and conditions process, they might not understand what they’ve agreed to. But if you make these legal documents too long, most people will just skip reading them. So there’s a balance to be struck here.

Our social and economic environments nudge us to move ever faster onto the next thing. We get impatient if we have to wait in long lines, like those we find at security checkpoints at airports. Those are mostly a waste of time, and we should work to reduce the friction of going through security.

But we should give some things more time and attention. For example, here in the U.S., it’s not unusual for people to order food from the driver’s seat of their cars — and sometimes eat it there, too. This seems like a problem we’ve over-optimized. Eating isn’t something to be dispensed with so we can get on with our day; it’s an activity worthy of our attention.

Taking Digoamaje’s lead, I’d encourage us to consider that some interactions require more contemplation than others. Intentional friction can serve a purpose. So mindful pauses can be another color in our palette, something that we can use in interaction design, to get people to interact more mindfully with the systems that we design.

The last question comes from Ruben Stegbauer. Ruben asks,

What search-related trend are you most excited about?

I’m not sure if you’d consider this “search,” but the most interesting development I’ve seen in this space in the last few years is how we’re interacting with AI-driven image generators like DALL-E and Stable Diffusion.

As you may know, in these systems, you enter an English language query, and the system uses a language model to build an image, whether it’s something that looks like a photograph or an illustration, that tries to match the query that you’ve issued.

At first, people entered English prompts to see what came out. But as they experiment more, they started writing prompts that more directly address the underlying language models to achieve particular results.

There are a couple of things that interest me about this.

One is that these systems try to hide the underlying complexity through language interfaces. But people quickly figured out they could get better results by reverse-engineering the model based on the results of various queries. Then they can issue more direct commands.

People train the system, and then the system trains them right back.

The other interesting idea is that similar interfaces can be used for more traditional search use cases, such as looking through large text repositories. Today, you must know specific aspects of the text you’re looking for when issuing a search, whether it’s a verbatim text string, the document’s title, or the author’s name.

But there are already systems in the market that let you search using much vaguer queries, where you’re looking for something even if you don’t know quite how to formulate the query. For example, I’ve been beta-testing a service called Elicit, which uses language models to help you search through academic literature. The results are pretty good.

So I expect that we’re going to see more AI-driven search interfaces, and that’s pretty exciting.

Closing and thanks

So that’s a wrap for listener questions, for now. Like I said, I’ll be doing more of these episodes. If you have questions you’d like me to answer on the show, please email live@theinformed.life.

We’re coming up on podcast’s fourth anniversary. When I first started, my goal was to get through the first twenty shows or so to see if I liked it. The number 100 kinda snuck up on me. It hasn’t felt like work.

Frankly, this show has been something of a mind-saver for me over the last few years. I love talking with people, and the pandemic constrained my ability to meet people “in real life.” So it’s been a real privilege for me to host these conversations over the last few years and share them with you. I plan to keep doing this as long as you keep tuning in.

And on that note, if you enjoy the show, and would like to help, the best thing you can do is tell others about it. The world we live in demands that we all get better at organizing information. We’re all called to be information architects to some degree.

I hope to help by sharing conversations about how others do it. The easiest thing you can do to help is rate or review the show in Apple’s podcast directory. Ratings help increase the podcast’s visibility. You can find a link in the show’s website at theinformed.life.

Before signing off, I’d like to thank Sarah Clarkson, who provides editorial support for the show. Sarah’s help makes it possible for me to publish regularly on top of my busy work schedule. Thanks, Sarah!

And of course, thank you for tuning in. I hope to continue sharing these conversations for as long as you’d like to listen. Here’s to the next 100!