Nate Davis is an independent information architecture consultant and a longtime contributor to the global IA community. In this conversation, we discuss his ideas about IA sub-disciplines that influence the construction of digital user interfaces.

Show notes

Show notes 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:
https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200

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

Transcript

Jorge: Nate, welcome to the show.

Nate: Great. Thank you for having me.

Jorge: I’m very excited to have you. I’ve known you for a long time, and we’ve crossed paths in so many conferences, mostly conferences, right? And information architecture conferences at that. But I feel like you and I have actually had little time to sit down and talk, like properly talk. And I see this podcast as an opportunity to correct that. For folks who might not be familiar with you and your work, would you mind introducing yourself?

About Nate

Nate: Sure, thanks. My name’s Nate Davis, and I am an information architecture consultant. I specialize in an area, at the moment, that I’ve been researching and developing for a while called what I call UI structural engineering, and it’s really about what happens once you design a structure. Can you reference it? Can you evaluate it? Can you systematize the structure of your right? And most recently, what does that look like in the age of artificial intelligence? And so, I’m still exploring that.

I was led into this part of the practice through my theoretical and scientific programs about information and architecture, and I’m really interested in its properties and attributes and how information architecture impacts or has impacted a systemic level. And so, I was an early advocate of practice and discipline when I entered this field.

And so I spent a lot of time wrangling around that and what that meant, especially as someone who, at the time, was also a manager in a large Fortune 500 company that was managing information architects and experience designers. As a result, I’ve always had the responsibility to situate information architecture in the context of an organization that we have to serve.

And I guess going back to how I got into this, my origin story as a professional is really in marketing communications. And so, I naturally evolved and moved from print communications to digital communications and having a strategic responsibility. When you’re thinking about communications, you always have to be concerned about the outcomes. And so, what I had, the responsibilities, and the perspective that I had in the print medium transferred very well into the web.

And that landed me in the space of having to own and synthesize the framing of the goals of a client, of what they were trying to achieve. And it’s the same thing with the user interface is, like, well, what is the owner’s intention here, and how do we translate that into something that can be communicated effectively? As we know, the web and digital applications just add multiple layers of complexity. And that was like the main driver that just kept allowing me to go deeper and deeper into this practice.

Jorge: I feel like pinching and zooming on that phrase, “UI structural engineering.” And I’ll tell you what I heard in the way that you introduced yourself is that you inhabit what might be thought of as a kind of liminal zone between the very strategic part of this practice that has to do with figuring out what we’re doing, what’s in service to, and all that with the operationalizing of those decisions. Is that a fair take?

Nate: Sure. Yeah, I think I’m an information architect who’s trying to understand the information architecture of the practice, you know, in a way, and I’ve been doing that for a long time, knowing that understanding where the rest of the industry is in trying to have to deal with rapid and iterative development cycles and design cycles, but also knowing that at some at any point, my team or a digital organization, could experience this level of complexity immediately, like exponentially. And then the question, I always wanted to be able to say, “Okay, yeah, I know where we need to go next.” You know, I see how this really delivers value.

And I knew when I was getting into this that I really had to be in an enterprise environment because that’s where all the wicked problems were. And I had done a lot of consulting in startups — you know, smaller, midsized small companies — and some consulting, but it was like, this has to be much more complex in larger environments. So, I was fortunate to be able to spend about 14 years in a large enterprise, a Fortune 500 company, and that’s where I really played around and was able to put a lot of ideas to practice and test them out.

Four IA sub-disciplines

Jorge: One of the reasons that I reached out to have this conversation is an essay you posted to LinkedIn called Four Information Architecture Disciplines Every Team Should Consider When Building Digital User Interfaces. And I was hoping that you would tell us about that. And I’ll give a very high-level overview of how I understood it, but I want you to elaborate on it.

So, what I got from this is that you’re arguing that there are these four areas of interest or sub-disciplines within information architecture. As you said earlier, you’re concerned with the information architecture of information architecture as a discipline or area of practice, and you lay out four of them. And I was hoping you would tell us what they are and why write about this.

Nate: So though I wrote about this because one, as a consultant, it’s important for me to ensure that when I’m speaking to customers that they have a way to understand… or some type of educational material that they can also understand where I’m coming from. And so, I think I wanted to do this as a general way to educate the rest of the market to say, “Hey, this is what’s going on around information architecture.”

It was important also to do this because, as we know, over the years, it’s been very difficult for a lot of people to articulate information architecture in a way that’s tangible to people and practical in some cases, and also situational. And I think that it’s, I wanted to get at that is to help people to situate, to say, “Okay, this is how I can use someone with information architecture chops.

Or this is how, from a designer, this is how I can leverage some of the other thoughts and areas of concern that information architecture is considering and maybe improve my UX/UI design game a little bit more because it’s like it’s more than just these things. That’s why I wanted to get the idea out there that information architecture is more than just these popular ideas, which is the more tactical that we see.

In terms of setting it up, one of the patterns that I saw in my research also plays out in environments of human behavior; even though I’m studying information, I can look at a human space — behaviors and activities — and see correlations.

And so one of the things that I knew is that there was likely a better way to express to people what’s happening in information architecture to reduce some of that confusion because we try to take something that’s really large and complex and try to sum it up as one thing, you’re going to get a lot of different opinions on that because rightfully so, there is this diversity and variety in really everything.

And I’ve been doing this over my career as well, but it’s to try to say, “Okay, I’m going to open this up a little larger for people to see a few different lenses — patterns of behavior and patterns of practice — that are very distinct from each other, but they’re all very complimentary and necessary. And depending on what you’re doing and depending on the complexity of the interface that you’re working with, you may have to toggle up and down on any of these.

If you look at the different consulting firms that are out there that position themselves as information architecture firms — there aren’t many — but you can see a difference in that there are some information architecture firms or practitioners that are very interested in the architectural side of what we’re trying to do. And that’s where there is this modeling of intent. It’s not thinking about the interaction at all; it’s thinking about the genesis of goals and objectives and trying to get to that coherence.

And then the other area, this other section, the sub-discipline, which would be what I’m calling — what I will call — the design portion of our discipline. And this is the most popular. This is where, “Hey, we, we’re now trying to solve something, right?” And this is where we’re actually creating based on what you’re trying to achieve, and based on these goals, here’s the structure of a particular flow or a use case. This is how someone may have to navigate from point A to point C or point D, and they probably have different paths.

And so, designing those artifacts, designing those models, that’s the solution, and that’s where we find most people playing in that space. And so we end up with these artifacts, right? We end up with models, taxonomies, site maps, flows, and just a host of artifacts to help explain and describe what content is or how content and information need to be structured to support that interactive design, right?

And as I said earlier, the engineering piece of it, for me, is where I spend a lot of my time, and what happens is, most teams, ninety-nine percent of the teams that are out there, typically, whoever it may be, the team designers, when they’re doing some of this information architecture work, and they’re crafting the structural design, it usually ends there, in a document, in multiple documents scattered across the document-verse. And these are all documents where they’re the means to an end just to get to an interface. But then no one considers if you need to revisit that structural design, how do you do that in an efficient way, and for me also in a systematic way, especially if you think about scale.

If you’re creating a smaller website, some of these questions might not surface, right? Every site doesn’t need this level of engineering. However, when you are dealing with enterprise applications that have significant complexity with access to content with dynamic content generation, different modalities of where information can surface, business rules, yadda, right? All these things where there are concepts and rules that tie to these, it becomes really important to be able to quickly reference that and understand how all of these things are interconnecting. So that’s where I kind of like play in that space.

And then the last piece is the discipline of operations, right? And that’s recognizing that while some systems and UIs are not really that demanding, you can, kind of like, once it’s done and you put it up, and things are running pretty well, but again, when it’s complex, and we have multiple teams and business units and whatever, how you systematize workflows around maintaining that, that UI structure becomes important. Those are the four kinds of areas that help you address small projects, but also, when necessary, it positions you to be able to address these complex environments.

Jorge: I’m going to reflect it back to you because, when I was reading the essay, I had questions, and I now have the opportunity to surface them. In particular, questions about the distinctions between some of these lenses as you describe them. So again, I’m reading it back to you; the four are the architecture of the system, design, engineering, and operations. Right? And you just described what they encompass.

And what I got from the essay and also what I heard you say here, and I’m going to try to be pithy, is that architecture is being used here as a noun to describe the structural construct somehow. And it’s a noun that’s describing some kind of — I’m going to use the word “platonic” model. It’s like you have this model in your mind that you’re aspiring for.

Design is being used as a verb in that it’s the way to get to that model, right? And you use the word solving, you know, solution. It’s kind of like addressing some kind of user need, right? So you go through this process of understanding those needs and then addressing them through this architecture. And then, engineering has to do with the implementation of the thing you’ve designed, and operations somehow have to do with maintaining that thing over time, right? So it’s about how it addresses change over time somehow. Governance, right? Is that a fair read on it?

Behavioral lenses

Nate: One of the things of my theoretical bent is that I see information as a behavior. So, when I describe something like architecture, design, engineering, and operations, I actually view all of those as activities. They’re actually behaviors. So it’s an architectural behavior, our architectural pattern of behavior of, in this case, we’re talking about human behavior or in a collaborative environment when you see people in this active architecture, you will typically see the trending of people clamoring around and trying to resolve intent, right? They’re trying to align; they’re looking broadly, systemically, and we’re trying to get it to some coherent objective and goal.

So, that’s an architectural activity. I’m calling it architecture here because, in the article, it is just for the sake of communication, but if I were to get into the nuances of this, all of these are activities for me. It’s interesting that you said the engineering part is implementation. This could be another conversation, but I would describe the engineering activity actually more as instantiating the design.

Implementation, technically, would be when, let’s say, a taxonomist or an ontologist actually now has to build that structure in the system in some. existing infrastructure using said software. Right? I do want to separate that because the work that can be done as an information architect, I don’t want to doesn’t have to get as technical as people might think.

I don’t think you have to write code, write scripts at that level, and have to play with RDF statements, and deal with the types of syntax and standards that would be expected of a knowledgeable engineer that’s working in that space. So, that’s the implementation piece that comes in, but we definitely have to be able to have conversations with those individuals. And they are part of that – helping to realize that functionality that you want in a user interface.

Jorge: That feels like a very important distinction that you’ve just made, and it’s something that I’m, and I’m glad you brought it up because when you read “engineering,” I think that the tendency might be to assume that you’re talking about like, well, this is the person who’s actually going to be creating code that renders this front end or, as you said, populating this taxonomy management system or whatever.

Yeah.

But I think what you’re talking about here might be… the way that I’m hearing it, it’s almost like the four lenses that you’ve described talk about different stages in going from an abstract ideal of what the system is going to be to a more realized instance.

Nate: And consumable.

Jorge: Like, something that addresses real-world needs. Which, when you start — and to try to put an accent on it — whenever I’m working on a model, I have this very abstract, idealized vision for what the primary distinctions in the system are going to be. You might have the public side of the system and the private side of the system, and within those categories, you have other subcategories, and it’s all very abstract, right?

But then, when you actually start thinking through the implications of those distinctions at the level of things like, well, how does this impact the user interface? You start realizing that these sometimes overly simplistic distinctions don’t hold water at that level, right?

Nate: Yeah. Yeah. And as an engineer, I’ve gotten to the point where I’m looking at a whole different level of factors and dependencies, that someone who’s focused on the architect or the design piece of it, because now as an engineer, I’m looking at making sure that the proper use cases are addressing not just, say, a consumer of information on a customer side, but I’m also now looking at okay, these other archetypes, does this particular set of…

Now that we’ve established someone has designed this interface for a customer, for example, do some of the conceptual models or the flows or whatever we’re designing, does it also now, how does that connect to the owner of that system, for example, in their use cases? Managers have to be engaged to sustain this interface, as well as contributors right behind the scenes. So, there are all these other factors that contribute to the sustainability of any concept that you might come up with when you flow or anything that is structural because it’s not… you have to make sure that you’re looking at all the other factors.

And so, if I think of a building, for example, yeah, I want to put a building up, and I want to look this way. But okay, great. Now, the engineer comes in and says, have you considered the environment right? Have you considered time? Wear and tear? Use on the structure? The load of volume and constant use, right? So there are all these other factors that come into play that are very technical but that are focused on sustainability and durability as it pertains to practical use.

Do you want this to stand up for a month, or do you want this to stand up for two years? Or do you want us to stand up for a month and put in place the necessary structure that allows you to scale? So, you have to make sure that you’re not so solution-oriented. Let’s move away from very specific groups and categories and probably set up a higher-level framework so that you can scale and anticipate. So, I would raise those types of questions and conversations at times.

The real concern of IA

Jorge: Right. And then the operations piece, I get the sense that that’s about creating the ongoing structures that will enable this structure to remain relevant over time, right?

Nate: Yes, because one of the central themes that I carry through in my form and practice and in my research, I do adhere to, when I talked about this at the beginning of the article, is at this higher level, Hopefully, I don’t lose my thought because I’m going to back up a little bit. So this higher level relates to everything that any information architect who’s out there saying, “This is what I do.” They’re all going to boil back up to this idea. This central interest. And I’ve had to boil this down and deduce this, and I did this a few years ago.

But the idea is saying that information architecture if we were to look at it academically, say, what’s everyone really doing? And so, I say that we’re all really concerned with — and these are things that you’ll see repeated in conversation and in articles and played out — but it sounds like that we are concerned with — and we’re obsessed with in some cases, some of us are, right? with understanding how to facilitate shared understanding, right? And there’s a lot there, but what does that mean, right? Getting to get not just one person…

How do you get a hundred people aligned, or how do you get a million people aligned around something right? Some intention or some goal? But also, how do you facilitate shared alignment? And that alignment is more about what we all think we want to do. The first one is, what do we think we understand about some kind of space to make some kind of decision and have an objective? Then, how do we align all on that objective?

And then the trick where all the information architects you can see is that we have we go beyond that piece of it, we go to the point of, okay, we got it. But as we’re doing it, let us make sure that we can conceptually make that thread — all these threads and relationships — as clear as possible and boil it down to its simplest and as efficiently as possible, right? So, getting that clarity.

So, that’s something that should be seen, that should come out of any information architect. If someone comes across you, Jorge, and they attend a workshop, and they’re working with you trying to get something, get a project done, they’re going to get that. They’re going to say, Jorge came in here, and he boiled this thing down and made it so simple for us. It was unavoidable for us to see it, the problem that we have, differently. We have, once we see it, it’s like, “Oh, we can’t unsee what he just showed us. It’s clear.”

Imagine we do this on these smaller projects. Twenty-five years ago, when the field started, we were doing this in very simple ways. And over the past few decades and stuff, it’s become more complex, and so imagine saying, for me, I carry this as a pillar of what I’m trying to do for an organization. I’m trying to help some large enterprises sustain shared understanding in alignment with conceptual clarity.

So now that becomes operational tasks for someone who’s responsible for trying to implement information architecture for user interfaces in an organization. Now, my job has been: these interfaces are being architected, and the structures are being architected, designed, and engineered. Now, how do we maintain that for possibly thousands of people who have some need to reference or use the insights and knowledge that’s being captured in this either for an application or for simple business insights that can contribute from a data perspective, if you’re doing data analytics, or just from helping an organization to maintain the coherence of their data catalog or vocabulary for their business.

The impact of scale

Jorge: The sentence I wrote down when you were saying this, which to me serves as a synthesis of what you’re talking about, but of the field more broadly seen through this lens is, I’m going to read it to you and get your reaction to it. The sentence says, “clarity and order in service to shared understanding at scale.” Is that fair?

Nate: It could be at scale or could be at smaller levels. It doesn’t have to be at scale, right? It’s like walking into a room, and you can almost, you know, if it’s just two people… because information architecture as an area of study, as a concern, we almost don’t care what the domain is. We can walk into a room with two people, and we can almost do conflict resolution, in a way. Right? “Hey, I hear you. I hear you. And I also hear all these other things. Oh, this is where this is what’s going on here.”

Ideally for me, I’m interested in scale, right? But everyone’s not interested in scale. I would say that it’s just focused on getting to that clarity so that something can be done, whatever the intention is that is shared within that space, can be done in a sustainable way. And that’s the trick, too, because businesses sometimes are thinking about themselves, and product owners might be thinking about themselves, and they don’t realize that they are a part of or they’re sharing in this system.

And so, my intention, for me to be able to do what I want to do or achieve what I want to achieve, I have to make sure that it’s aligned with these other… or I have to recognize all these other intentions and objectives that are sharing the same space. And what is that? Am I aware of those things? And how does that impact me to sustainably achieve some of the goals that I have?

And sometimes, when we do this work in discovery and research, we find that your intentions are your intentions. However, to sustainably achieve what you wanna do, you may have to adjust what you’re really trying to achieve, and maybe what you’re trying to achieve may have to be restated or redefined or adjusted, and there may be some compromises. So, those are things that we end up finding in the process. You know, I find a lot of clients recognize, “Oh, this is what I really want, you know, and as a result, this is what we need to do in order to get there.”

The impact of AI

Jorge: That’s clarifying. I have two more questions for you. So, second to last here is about AI, which you alluded to at the beginning of our conversation. And I’m going to read a sentence from your essay. So, you say, “Any human-centered job displaced by technology that requires a command of human communication necessitates a proportionate number of human resources to maintain the reliable transformation of domain knowledge, conceptual integrity, and corporate accountability.” and, when I read that, the question that came to mind was, is this still true after GPT 4?

Nate: Yeah, that’s my thesis. So, here’s the thing — and I think that statement might not work for every domain that’s out there; I think there are certain jobs that will be displaced because of the efficiency brought on by automation that comes from using large language models and methods for artificial intelligence. Particularly as it relates to the work that I’m interested in and the work that a lot of information architects are trying to get at, what you will find is that some of the challenges for artificial intelligence or for large language models, more specifically is that it is now augmenting or becoming an alternative source for information, right? And because of the way that it technically is architected, it is not able to check itself. It doesn’t know what it doesn’t know. And as a result, it doesn’t, in some cases — in many cases — it doesn’t necessarily understand the meaning and the nuances of semantics or inferencing in some cases where it matters.

I know that there are efforts in trying to close a lot of these gaps, but… I guess what I’m getting at is that there is a level of accountability that will still be… that was actually going to be created, right? And I think a lot of the accountability doesn’t exist today. Hopefully, organizations will realize that, in order to be accountable — conceptually, or if a statement is made — there has to be… that statement that an agent is now making on behalf of an organization has to trace back to clear intent and understanding and making sure that it’s connecting back to what is understood in the organization and what is aligned to the organization.

And that’s a lot of work because you still need people to speak on behalf of the business. But then you also need now to make sure that there are people who are helping, who are translating what the business understands into smaller bits or chunks of information, content, and concepts that can be transformed into data and content so that large language models can use that internally in an organization to stay aligned.

So, there is this alignment issue of accountability that systems will always have forever until we decide to allow technology to act on our behalf. And it’s over then if that ever happens. So, I do think that especially now that there’s going to be — there should be — more effort in making sure that you have individuals who are thinking about, “Well, how do we make sure that what is said by and done by these artificial agents that they’re conceptually aligned with the organization.” And that’s where we play. It’s an opportunity.

Jorge: The way I hear that is that these large language models, in particular, can be really useful tools to do things like spot patterns, maybe sketch out possible solutions, etc. But ultimately, ontologically, the buck stops with humans. Right?

Nate: Oh, sure. Sure. Because these systems are operating on behalf of us. And so, as a result, they should always be accountable to us. And so, how do we put those measures in place? And that’s a lot of, there’s a lot… I mean, you’re talking about risk, compliance, just simple facts. What’s fact versus what’s fiction or what’s aspirational? And all these different levels and layers — all these other domains, there are other domains as experts that have to be connected to all this.

And I do think that information architecture practitioners have the skill sets to be able to help with a lot of that work of helping organizations transform a lot of these abstract concepts and begin moving them into conceptual data patterns or being part of the process of seeing these patterns and working with content strategists, for example — writers — to actually write the content so that the models can consume that. And then you have knowledge, engineers who are building ontologies, and they’re seeing those patterns and making those corrections. So, hopefully, we’ll see a new type of team come into play in the future that’s focused on conceptual integrity and provenance for the enterprise.

Jorge: That’s great. And this is such a rich subject. We could keep talking about this. Alas, the time is running short. So now I’ll ask you the last question, which is: where can folks find out more about you and follow up with you?

Closing

Nate: That’s a great question. You can find me on LinkedIn — I’m active on LinkedIn. And also, I have a consulting practice that is called Methodbrain. And so you can find me at methodbrain. com.

Jorge: Fantastic. I will include links to all of those things and to your essay in the show notes so that folks can check it out. Thank you, Nate, for your time, for being with us, and for sharing your knowledge and expertise.

Nate: Thanks, Jorge. It’s been a pleasure.