Andy Fitzgerald: Information Architecture for Digital Content – Episode 67

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Spotify | Android | TuneIn | RSS

Andy Fitzgerald is an information architect who focuses on content for digital experiences.

He helps organizations bridge the gaps between their users’ human needs and the constraints and requirements of their digital systems.

A website or other digital product will always have an information architecture. Being purposeful and intentional about its design yields better digital experiences.

As Andy says, “Information architecture always happens – either by design or by default.”

Andy and I talked about:

• his background in information architecture, interaction design, and user research
• his definition of structured content: content that makes the relationships between its fundamental units clear and machine-readable
• the importance of focusing on humans – information architecture is a human-centered design practice – while harnessing the power of computers to serve them
• how information architects make content findable and understandable
• the importance of orienting yourself in the domain you’re operating in as an information architect – and the important distinctions between domains and, for example, a website
• knowledge graphs and graph databases and how they differ from the tabular data formats that CMSs typically use
• an intermediate narrative/syntactic layer in content structure, between simple tabular data and semantically organized graph data, that can be organized serially to tell a story
• the complexity inherent in natural language, e.g. “Time flies like an arrow. Fruit flies like a banana.”
• the standards that underlie the creation of knowledge graphs
• how his Ph.D. in literature gave him the academic skills needed to consume advanced information in this quickly evolving field
• how machine learning and natural language processing are advancing the modern Semantic Web
• how responsive web design permits different ways of expressing messages
• the story behind his recent article, “Delivering Information architecture”
• how separating the creation of a classification scheme from its expression as a website navigation scheme can help keep stakeholders aligned and discussions harmonious
• how “an artifact is the end 1% of the other 99% that’s thinking through the sets of problems”
• how “information architecture always happens – it either happens by design, or by default”
• how standards like ANSI and ISO guide his professional work and lend legitimacy to our craft
• how information architecture acts as an adapter, a bridge between two fundamentally different systems:
  • human users, who are associative, heuristic, and approximate, and
  • digital systems, which are enumerative, exhaustive, and exact
• his article, Delivering Information Architecture

Andy’s Bio

Andy Fitzgerald is an independent information architect and digital experience designer. He works with organizations of all sizes to create elegant solutions to complex information problems. Prior to forming his own practice, Andy held design and director positions at Deloitte Digital, Anthro-Tech, and Frog, where he tackled the problem of effective communication in complex information spaces for a wide range of client organizations in healthcare, education, financial services, retail, entertainment, and transportation. Andy is an active member of the IA and experience design communities and speaks and leads workshops at UX and IA Conferences all over the world.

Video

Here’s the video version of our conversation:

Podcast Intro Transcript

Content professionals face a vexing problem when we try to organize information for digital media. The humans we serve want engaging stories and quick solutions. The machines that help us serve our human users are pedantic know-it-alls. The discipline of information architecture helps bridge the gap between these conflicting approaches. In this episode, Andy Fitzgerald shows how information architects use data, stories, and meaning to organize content and bring it to life for the human beings who need it.

Interview Transcript

Larry:
Hi everyone. Welcome to episode number 67 of the Content Strategy Insights podcast. Really happy today to have with us Andy Fitzgerald. Andy’s an information architect in Seattle, Washington. Operates independently, he has his own consultancy there, and Andy, welcome to the show. I’d love for you to tell the folks a little bit more about what you do.

Andy:
Great. Thanks Larry. Thanks for having me on the show. I’m very happy to be here. So I am an information architecture consultant. I also have a background in interaction design, user research into sort of a broad user experience palette. I’ve worked at Dolby Digital and Frog Design, and a few other consultancies throughout the years. And now I focus almost primarily on information design, and information architecture, and content strategy. And primarily for healthcare, higher education, and government spaces. So those are all spaces that they tend to have really gnarly information problems, and they’re the kind of things that when we get them right can actually make a pretty profound difference in people’s lives.

Larry:
Great. Those are big important institutions and organizations. And that confluence of content and information architecture and all that, the way I think about it from a content strategy perspective is that’s to my mind structured content. And we’ve talked about that. That’s a thing. That’s a term. How would you define structured content?

Andy:
I think of structured content is content that makes the relationships between its fundamental units, its pieces, clear and machine-readable. Let me take that apart a little bit. If we have, let’s say a memo, or a restaurant menu, we can look at that, and we can see the size of the font, we can see the spacing, we can see the line spacing, we can see the colors, we can even see any decoration there might be on a printed page. And we automatically make sense of that. We are pattern recognition machines. But it turns out the machines that we’ve built are really poor at recognizing patterns. So if we want a machine to understand that something is a dish versus an ingredient, we have to be able to express that in a way that a machine can understand. And there are lots of ways to do that. And I hope we’ll get to talk about some of them, but to begin with, we have to know ourselves, what those relationships are, and we have to give ourselves the opportunity to make them clear in whatever format we need to express to them.

Larry:
Got it. And so your practice would be like, okay, whatever realm or domain you’re operating in, what have we got here? What does it look like? How can we make this information useful and usable to human beings, but also make it machine-readable so that we can stitch it together. I’m assuming that things like responsive design and the evolution of, we’re not consuming just web pages anymore, we’re looking at web apps, and doing it on a variety of different devices and places. And so that separation, I forget exactly how you said it, but it’s sort of having the units structured in a way that you can put them back together in different ways. That’s a big part of it.

Andy:
Yeah, yeah. And part of that definition is, yeah, we do need to make them intelligible to machines, but machines aren’t reading our recipes. They’re not reading our blog posts. It’s always for humans. It’s always a human-centered design process. But, as you know, and I think we all know, we’re now in this situation where we’re creating all of this content, all of this data, and there is this, I didn’t even know the metaphor anymore, tsunami just seems so quaint, of all of this content and information, and there is now just no possible way that as humans we can sort through this and find what we need. So really, we need algorithms, and machines, essentially, to help us find what we’re looking for, understand what we find, and really be able to think critically about it, and put things together in order to meet our goal. So it’s all about people, but people need the help of machines to make sense of what we have wrought upon ourselves with the internet, essentially.

Larry:
We’re just kind of not putting the genie back in the bottle, but, holy crap, we’ve unleashed this fire hose on the world. Now let’s try to put it into some taps, and organizing that. Tell me some of the tools of your trade. There’s practices like taxonomies, and other ways of organizing and ontologies to stitch things back together. But tell me what’s the toolkit of an information architecture, especially as it pertains to… and I assume that most of your work is around content, right? I know there’s other ways you can be an information architect.

Andy:
Yeah, yeah, it is around content, and really it’s around making things findable and understandable. And you touched on a minute ago, the idea of structuring content around a domain. So one of the tools is really more of a conceptual tool, is understanding what the domain is. And then one of the challenges is you start to think about structured content within a particular domain. For instance, I’m working with a client now who is a labor organization representing home healthcare workers. So that is healthcare, but it’s a very particular kind of healthcare, that has sort of tendrils in the insurance space, and tendrils in the healthcare space, but not in a facility setting, in a home healthcare setting. So it’s a very particular domain. So understanding what’s important, what the important content objects are in that domain is important, because that then helps you understand what the fundamental units of meaning are.

Andy:
So when we look at structuring content, this is kind of getting right into the nuts and bolts of it. This is really the tool of the job, is like what’s the smallest unit? So you can think, for instance, if you have a list of employees, an employee might be the smallest unit, or maybe an address is the smallest unit. But if your address is 123 Main Street, the smallest unit isn’t the 123, because that doesn’t mean anything on its own. So there are units like 123 Main Street, Seattle, Washington, 98102, that means something. But once you break it down any smaller than that, the context that gives those individual data elements meaning is no longer there. And it might be that in some domains, an address alone isn’t enough to give you context, to give you meaning.

Andy:
So it’s really the domain that determines when we start to break things up and we say, okay, we’re going to identify this piece, and this piece, and this piece, in order for them to be understandable by machines that help us understand them. It’s always in the context of the domain that that happens. So that’s really one of the key tools, and it’s a super abstract kind of thinking, especially for web design, which for so long has been all about the screens. But it’s the kind of thing that as we’re relying on algorithms to help us find and make sense of information as we must, is becoming increasingly necessary.

Larry:
Yeah. And there’s a bunch of ways you can get that. We were talking before we went on the air about our mutual friend Carrie, Carrie Hane, and I love their book Designing Connected Content. The book that she coauthored with Mike Atherton.

Andy:
Yeah, it’s a brilliant book.

Larry:
And one of the upshots of that, and the whole book is about domain modeling, which is great. Back in a prior life I did a lot of relational database design, and it’s a tiny leap from a domain model to an entity relationship diagram that a database designer would use, but it’s a significant leap, because it takes it, and I think it kind of gets at what you’re talking about. The domain model is kind of making it a human understandable thing. Whereas the entity relationship diagram is making it a machine readable thing. Is that a correct analogy?

Andy:
I think yes, and I think when we talk about structure like that, there’s an idea that I’ve been kicking around. I’ve been learning more and more about knowledge graphs, and graph databases, and learning how to bring on knowledge models to datasets in order to make sense of them for people of course. And I’ve been thinking about structure, kind of in the way that you’ve been talking about, and we have relational databases, with sipes, the WordPresses and the Drupal sipes, and scores of other CMSs. And that’s all tabular data. So its relating two points together. Or appointing an attribute. With a domain model, we’re really looking at graph data. So we’re looking at how two points relate relative to a bespoke connection, right? Or a custom defined edge, right?

Andy:
So it’s not simply that something is a parent or a child or has an attribute like you might have in a relational database. And I think there’s a space in the middle. So if we have tabular data, and we have semantic graph data, there’s another space in there between them that I think is narrative, or syntactic data. And there’s a headless CMS called Sanity.io. It’s available for use. I’ve played with it a little bit. And what Sanity does is they use a, I think it’s called the open text model or open content, I forget exactly what they call it, but they developed, and it’s open source, but a model for serializing narrative content. And essentially what they do is they’ll take a block of body text, and every bold face, every heading, every link, every italic, every piece that’s not just running text is actually broken up in a JSON file.

Andy:
It is addressable, and is identified as what it is, and what it means. And what that means is that you can deserialize ot on a website, or a voice interface, or on a screen reader or however else you want to deserialize it, and use that content in a machine-readable way. And to my mind, it’s a different kind of content than either tabular or semantic content. Because semantic content, you can put it in a line, it doesn’t have a natural sort of syntactic structure it’s got a semantic structure. So this idea that there’s this third narrative space, and we’re narrative creatures, we live on stories. That’s how things make sense to us. And it’s interesting that there’s now a group of people who are thinking about what this third space might look like. So I think there’s a lot more than relational databases available to us for structuring and communicating content.

Larry:
And as soon as you say that I’m picturing maybe there’s not just three, maybe this is a continuum, because you’re making me remember the attraction of databases is that they are tidy, and you make this normalized data to get it in there, and it makes the subsequent processing of that easier. Whereas in the semantic, that’s the other issue we were talking before about like kind of timelines and stuff. The idea of the Semantic Web has been around 15, 20 years. Web 2.0 wasn’t that far behind Web 1.0. And you’re talking about this narrative, but let me go back to that real quickly. When you say narrative, I think like you said, story, that’s how we think, these stories could be, they could be literature, they could be a story about how to fix your washing machine, they could be a story about how to navigate.

Andy:
My background’s in English, and French, but it’s in language and it’s in literature. And that’s what got me into information architecture, is this idea of how do we make sense of things with words. In narrative, we’re so good at it, that we lose sight of how much complexity is wrapped up in narrative, in the way that we can understand strings of words. So there’s a word game that linguists like, a joke, or maybe it’s more of a koan, it’s “Time flies like an arrow. Fruit flies like a banana.”

Larry:
I love it.

Andy:
I come back to this stupid little set of phrases a lot, but there’s so much complexity wrapped up in here, because even those two sentences put next to each other invites a whole sort of examination of what language is and how we make sense of it. And you can see pretty clearly why a machine would have a hard time with this. Because there’s so much context in it. And actually that time flies like an arrow, fruit flies like a banana, it’s not about time or bananas or flies. It’s about language. So there are levels and levels of meanings that because we’re linguistic narrative beings, we can start to access, and we can think about, but there’s a ton of complexity in there.

Larry:
Yeah, no, you’re just making… I’m all of a sudden thinking like why a database is just so attractive, because they sort of simplify that. But what you’re saying, it’s balancing finding… discovery is important, and you want to be able to find things, but it’s that understanding it. And I think that’s kind of what you’re getting at is a good story is how you actually understand whatever the concept or information you’re trying to convey is. God, I kind of don’t want to get into tools, but there are, for each of those, like you mentioned like Drupal and WordPress and conventional CMSs is kind of operate from the database model, and Sanity with that kind of intermediate model. Are there examples of the knowledge graphs, and I think of like Facebook and Google search results, or the way they operate. That’s kind of the first thing that I think people think of when they think of knowledge graphs. But are there CMSs, or I’m thinking also of like CCMSs and DITA and things like that, and they stitch stuff back together.

Andy:
Yeah. Yeah. So a knowledge graph mercifully is based on a set of web standards. So knowledge graphs are composed of RDF, which are Resource Description Frameworks, which are a set of subject predicate object triples. They’re simple statements. So you could say, entity Larry has last name Swanson, right? So it’s those really simple kinds of statements, and they’re always in three parts. Some people identify the graph that they’re a part of as a fourth part of the triple, but really, they’re just these really simple statements. And in putting these together, we run into… I’m trying not to go off on a tangent here, and it’s really hard to not do that, because language. We run into these situations where you could say, I don’t know, Larry talked to Andy, or Larry talked to Andy about content. Now we’re outside of the realm of triples, because they don’t have two things that relate, right? There’s an indirect object in that phrase. And that it turns out when we’re talking about knowledge graphs, you have to, it’s called reification.

Andy:
You have to abstract that out so that everything is these really simple statements, because as soon as we start to get into individual nodes that can have more than one relation, we’re actually in the realm of what are called hypergraphs, which are like exponentially more complex, and like our systems of formal logic can no longer make sense of them. So let me get back on track.

Larry:
A quick aside there, I just want to point out that you have a really deep and strong academic background in this, and that’s why you’re able to get into this stuff, and why we’re able to have, I think that’s got to be super helpful, because so many of us have come to this just like, I’m a journalist and a publisher, and I’m just figuring out databases on the fly. Whereas, you actually went and studied the underlying principles.

Andy:
My degree’s in English. When people ask, because I have… in English and French. And when people say, “How did you get into UX?” I’m like, “Well probably the most important thing I learned in grad school is how to sit in one place and read for nine hours.” I think a lot of this stuff, I mean there are certainly people at the like Hasso Plattner Institute in Germany, and in Stanford certainly that are studying this as advanced studies that are getting into it. And I’m chipping away at the surface, like everybody else. But it’s fascinating, and it’s being built as we go, or the users are being built as we go. I mean as you mentioned a minute ago, it’s been around for decades.

Andy:
I think it was in 2006 that Tim Berners-Lee sort of gave the talk that laid the foundation for the Semantic Web, and Web 3.0. The thing that’s changed is the advance of the kind of machine learning algorithms that can make sense of it and that can use it. I think voice is changing it as well. Because that’s all very algorithmically driven. The natural language processing, it takes up a lot of computing power, and that stuff is spilling over into the Semantic Web as well.

Larry:
Well that’s it. That kind of gets into like innovation in general. There’s all these necessary components that have to be there. You’ve got to have the conceptual understanding, which has been around, I think of Vannevar Bush, and Doug Engelbart. They had a lot of this stuff figured out. But the tools, and then all of a sudden, oh wow, we have machine learning, and artificial intelligence, and these not just tools but other methods by which we can do these things now. So I guess we’re getting to that point.

Larry:
And I just want to quickly, and I think it’s kind of related to this. We were talking before about, I have this sort of, as I try to stitch together in my head, try to explain to my friends what I mean by when I say structured content, I kind of think of three elements. The way I think about it, is there’s a place you keep the information that you’re architecting and organizing. Its expression in a user experience, user interface somewhere down the road, whether it’s voice or a webpage or a mobile app or whatever. And then there’s also this component of the connection part, the knowledge graph stuff, and how it’s all stitched together. But you said you have a tripartite way of looking at this. I’m really curious how you organize this.

Andy:
So my tripartite idea was that idea of tabular data, syntactic data, and semantic data. That was my other sort of shift on that. Although with this idea of that middle layer between message and expression, and the way you put it that the website, so maybe it’s Drupal or maybe it’s a voice-operated device. That’s an expression of a message, and you have a message you want to communicate, and then there’s a way of expressing that. I think we even see some simple examples in going from a laptop to a mobile device. In that you, to begin with, and Karen McGrane has some brilliant examples of the bad old days of this happening. To begin with, people just crammed desktop sites onto phones, or they made M Dot sites, that were not meeting the user needs.

Andy:
And now with responsive web design, at least for the last handful of years, most organizations are realizing that you have to, in your order to communicate the same message, you need to it differently in a different context. And we’re certainly going to see the same thing in voice. I mean, voice doesn’t, the linear instant nature of voice communication, there’s not a residual set of menu links that stays on the screen. You can’t have a list of seven things. People have forgotten the first four by the time they hit the last one. So that’s going to make for a different kind of expression that happens. It’s going to require a different layer of logic in the middle.

Larry:
Yeah. And to get a little meta about this, we were talking, you shared with me right before we talked, the article you’re writing on information, which will be out, I’ll link to it in the show notes.

Andy:
Oh great, thank you.

Larry:
It should be out by the time we do it. But you talk in there about the difference between the arrangement of the thing and the method by which you arrange it. And it sounds like to me there’s an analogy in there between these artifacts and expressions, and the underlying message to that. There’s sort of like yeah, there’s this thing that you saw, but there’s this method by which we put that together. And you use the example of a site map, which is a classic IA deliverable in there. Can you talk a little bit about that? Because I’m super curious about that.

Andy:
Yeah, yeah. The quandary that led me to that article, and the article is Delivering Information architecture. And it’s in part a way, sort of a love letter to my clients to say, “Hey, this is what information architecture is, and this is how it can help you, and these are the risks you run if we don’t go down this road. And part of the context I paint is I see this all the time. Clients that have a big full feature, expensive CMSs, and they’re using just the bare minimum of features. They’ve got all the Google analytics, it’s hooked up and everything, but nobody’s ever looked at it. All of these pieces that come together, and often, maybe not with the analytics, but the failure to use these pieces is not thinking about the systems that sit, the information systems, not the technical systems, but the way that we relate ideas and concepts together that sits underneath all of that.

Andy:
And a sitemap is one of the places that that happens. So in the article, I use the example of putting together a site map for a consulting client. There was actually two clients who had recently merged, and they wanted to bring their sites together under a single umbrella, and I made a recommendation for where their case studies should go. And the recommendation was that the case studies go under topical areas. There’s not a case studies link in the global now, and one of the stakeholders saw that, and was like, “Oh no, these have to go into global now. This is who we are. This is what we do.” And if we had only been talking about a site map, and I’ve seen this scores, if not hundreds of times, we would have taken positions, and argued about those positions. But in this case, the site map was just an expression. This is back to that expression, an expression of underlying systems.

Andy:
The underlying systems were a classification scheme that had been worked through, guided by, agreed upon design principles and in using accepted industry standards, and a navigation model that that followed the same kinds of rules and guidelines. So we were able to move back to those recommendations, and get at the intent of what she was after. And really through this conversation, what we found was that the stakeholder in this case was using case studies metonymically to stand in for, know really what she wants people to find. It isn’t the case studies. She wants them to find the demonstration of this consulting firm’s expertise within those case studies. Okay.

Andy:
So now we can even think about, okay, so this is actually what you want, now we’re all pulling in the same direction. Okay. How do people get there? Do they get there by looking for the format that they’re in, or do they follow, for example, I anonymized the example in the article to be a fictional company, but that fictional company has expertise that’s operations, and strategy, and extra-planetary stewardship. I’ll let you read more about that in the article. Or is that where people are going? So then we were able to have a discussion about what the actual goals of users and the business were, not of the position of, oh case studies have to be in the map.

Larry:
Interesting. That kind of gets in, I was having a conversation earlier today with a friend about, my intent is to democratize content strategy. And I hold to that intent, but she made the point, as soon as you democratize something, everybody thinks they can do it. I mean Don Norman has been criticized for trying to democratize design as a discipline, for the same reason. And I’m like, yeah, there’s a point to be made there. And her point was that like, we’re a legit profession, and we’re worthy of not veneration, but we’re legit professionals, and the craft that we ply is worthy of that. But at the same time I think there is a benefit to giving people access to the methods and things like that.

Larry:
So to me I guess the fundamental thing there is kind of about transparency about how things work. And I think that a domain model, like you were just talking about, it seems like that having done that work on, I don’t know what you call it, I think of it in my head as domain modeling is like one of the ways you get that that’s another artifact, kind of, that that functions in a different way that lets you go back and say, “Oh yeah, no we’re talking about this thing in the domain, not this type of expression of it.” Does that make sense?

Andy:
Yeah. Yeah. Yeah. And I think the artifacts are important, as long as they are the result of actually doing the design work. Because an artifact is the end 1% of the other 99% that’s thinking through the sets of problems. It’s possible to just skip that thinking part, and just draw a site map. And then, and this again is part of what motivated writing this article. Then we’re just arranging the pieces. We’re not thinking about the systems. And then we don’t know how this system works. And the other problem that I see with particular agencies that have big complex sites, or governments, governments are classic for this, bless ’em. They’ll have all of their content, and they’ll narrow it down, they’ll do a content strategy process of improvement, and then they’ll arrange it all, and they’ll put it on the web.

Andy:
But that arrangement, as soon as you add new content, as soon as priorities shift, as soon as the government adopts a new program, or as soon as a department merger happens, which happens all the time, everything crumbles. Because the underlying systems that created that arrangement are either not understood, or they’re very, very brittle. We talked a little bit about this beforehand, but I’d like to say that information architecture always happens. It either happens by design, or by default. And if it happens by default, then you might end up with a system that it doesn’t work at all like you thought it would.

Larry:
I think there are probably a lot of content strategy and information architecture consultants listening to this. Do you have any tricks of the trade for addressing that dynamic you just set out? Saying yes, you could just copy some generic site map and have a thing you could put on your… a way to navigate the current site as it is. But do you have, I don’t know, tricks of the trade or professional techniques that you’ve used to really hammer it? Because that’s kind of the point of this whole conversation, but there’s different ways to get that across to different stakeholders I guess. Do you have any examples there?

Andy:
Yeah, I mean one of the things that… maybe it’s a trick of the trade. I consider it more a part of being a professional really, that I tend to go back to standards for designing. So for example, for classification schemes, there’s the monolingual taxonomy standard, the ANSI/NISO Z39.19 that talks about how you structure categories, and the labels in those categories. Now that particular standard isn’t designed especially for websites. It’s designed for indexing taxonomies, but it gives you a set of guidelines to follow. So for example, if you’re putting a structure together, there are different kinds of relationships that can happen in that structure. You might say that for example, Lassie is a kind of collie. A collie is a kind of dog. Well actually Lassie is an instance of collie. A collie is a kind of dog. In dog, you might also put dog food, but dog food’s not a kind of dog, shouldn’t be, anyway.

Andy:
So there’s all these different relationships that happen in categories. And intuitively, they all make sense to us. Again, this idea time flies like an arrow, fruit flies like bananas. We can make sense of it when we see it, but you’re building a system, it’s a linguistic system of making meaning, and when you’re building it for shared use, when you’re building it for content and context that might grow and change over time, sometimes in unpredictable ways, and especially when you’re building it for someone else. So you’re an information architect, you’re a content strategist, you’re a designer working on a project, you’re not building it just for yourself. The externalization of those rules has to be clear. So the not really trick, but the sort of staple of the craft is to come in with that kind of knowledge, and be able to talk about what those differences are, and then be able to illustrate sometimes how they go wrong.

Andy:
And often, again, going back to government websites, you can look at the governments, you can look at their own site, and you can say the reason that this is difficult for people to find is because you have these different kinds of categories mixed. And that’s not necessarily bad, but if you’re going to create a more complex system of mixed kinds of relationships, we need to make sure that it matches your user’s mental model coming into it. And then here we get to the human-centered design standard. I think it’s under like ISO 9241 or something. So there are these standards that as professionals we can lean on, and I actually go to the standard, human-centered design, you don’t need to have read the standard to understand it, but it lends legitimacy to our craft.

Andy:
So one of the points that you made earlier was talking with other professionals, “Hey, this is serious, we’re doing serious work. In every other craft, developers have got all sorts of certifications. You can get tests, and you can be an official et cetera and XYZ, I don’t want to lean on that too much, because I think that’s certainly a double-edged sword. But there are with these, like with the ISO standards, the distillation of a wide body of experts in our field, and when we know them, and even if you never cite a standard to a client, which I really don’t recommend, depending on the client. I think once you demonstrate that knowledge, then you can start to build that trust. And you can start to walk the client through the process, and and show them why this kind of attention is worth their time.

Larry:
That’s one of the things I admire about your work and your style, is that you’ve got that academic and intellectual and standards-based foundation, and you cite those in that article you shared with me. We’re coming up on time, Andy. This always goes way too fast. Before we wrap up though, I just want to, I always like to give my guests a chance. Is there anything last, anything that we haven’t talked about or that’s just on your mind about information architecture, or structured content, or just anything last that you’d like to share with the folks?

Andy:
Maybe I’ll leave it with, I like to think of information architecture as an adapter, or a fitting, or a shim, or a bridge between two really fundamentally different systems. You have human systems, us, users, that are associative, heuristic, and approximate. We get by, we get close enough most of the time, and hey, that works really well for us. But then you have these digital systems that are enumerative, exhaustive, and exact. And when approaching the kinds of problems that we’ve been talking about, I like to think that these, it’s a square peg in a round hole, they just don’t fit. Information architecture is how we can create that adapter, or the interface, literally the interface between the two systems to help them work together. And part of that is, I don’t know, almost beautiful, because we have to work together.

Andy:
There’s so much information in the world, and it’s worth our knowing. There are certainly lots of ways that information sharing has gone awry in recent years, but there’s the possibility there that if we can actually help ourselves understand what’s actually going on in the world, then it makes it easier for us to take a more active part in improving those conditions, or changing them in ways that we collectively might agree on.

Larry:
Nice. I love that. That’s a great analogy of the square peg in the round hole. No, you just need the adapter, and information architecture. Yeah, that’s great.

Andy:
It’s one of them, anyway.

Larry:
Yeah, one of them, yeah. It’s a great tool, but thanks. Well, thanks so much, Andy. I really enjoyed the conversation.

Andy:
Thank you. Thanks for having me.