Mar 28, 2021
Jesse James Garret is a renowned leader in the user experience design field. He’s a co-founder of the influential UX consultancy Adaptive Path and author of The Elements of User Experience. These days, Jesse coaches UX design leaders. In this conversation, we discuss the relationship between leadership and information architecture.
Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links.
Jorge: Jesse, welcome to the show.
Jesse: It's good to be here. Thank you.
Jorge: Well, it's my pleasure and honor to have you on the show as a guest. I don't imagine that there are too many folks in the audience who don't know you, but for those who don't, would you please tell us about yourself?
Jesse: Sure! I'm Jesse James Garrett. I have been working as a professional in the user experience field for, 20 years or so now. If I am known to you at all, I am probably known to you, dear listener, from my book, The Elements of User Experience, which was published in 2002, or the work of my company Adaptive Path, which I co-founded in 2001 and was a part of through its acquisition by Capital One in 2014. I now work as an independent leadership coach working with leaders of UX design teams.
Jorge: And as we're recording this, I believe that the founding of Adaptive Path happened 20 years ago.
Jesse: Yeah! Yeah, yesterday was the 20th anniversary of the launch, a fun milestone to reflect on.
Jorge: Well, the influence that the work has had both in Adaptive Path and The Elements of User Experience is palpable in the field. I occasionally still run into people who bring that diagram — "The Elements of UX" — bring it up so many years later, and it's an artifact that has proven long-lived. And I'm wondering if you have any thoughts on why that might be.
Jesse: It's a little bit of a mystery because Elements seems to have an enduring appeal to people that other similar models don't seem to have that kind of traction. I think that part of it is that I tried with the model to capture — as much as possible — to capture the things that I thought were less likely to change. Although I put the date really prominently at the top of the document when I first published it, in part because I was expecting to update it. I was thoroughly expecting there to be multiple versions and each one would have a date stamp and there would be iterations and evolutions of the model. But then when people started using it and getting really attached to it, I changed my mind about it and felt like I should really leave well enough alone and not tinker with it too much. I've made some little adjustments to the language that I use in the model over time, but the model itself has stayed the same. And I think the fact that people keep picking it up and putting it into practice is surprising to me as it is to anybody, I think.
Jorge: Apart from minor tweaks to the language, do you feel like the model stands up overall? Even today?
Jesse: Well, I do really think that if it didn't people wouldn't be using it if it didn't produce some sort of positive result... It may not be the positive result I intended. Yeah, I mean, there's a lot more to be said than what is encapsulated in that model. It is intended to provide a basic level framework and obviously there's a lot more complexity to what it takes to actually get those things done. And there is a lot of nuance to how these issues play out. So yeah, in some ways it's not my call as to whether or not the model is still relevant. It's like, it's up to other people as far as I can see.
Jorge: Well, that's as good enough as any test for relevance, right? Whether people are using it or not. And for any listeners who might not know what we're talking about, this is a model that describes the work of user experience as happening in... would it be fair to call it five distinct layers?
Jesse: Yeah. I call them 'planes' in the book, but it's a visualization. It's this sort of layer cake, sort of visualization of all of the considerations that go into UX work.
Jorge: And they range from strategy at the lowest plane, scope, structure, skeleton and surface, which is the stuff that we see when we interact with a product that has been designed.
Now, I asked you to come on the show, not to talk about The Elements of User Experience, but because you and your fellow Adaptive Path co-founder and our mutual friend, Peter Merholz recently wrapped up what I'm describing as the first season of your podcast, Finding Our Way, and you and Peter had a conversation in that final episode where you synthesized the things you'd learned in the course of that first season. And you made a statement, you said, and I'm going to quote you back to you now, which is always nerve wracking! You said, "I think leaders are of necessity, orchestrators of systems. And systems instantiate knowledge as information architecture within them. So, the IA that gets embedded and coded, baked into your systems, becomes the way that the organization understands the world. And so, it is on the leader to imbue, infuse, enrich that IA with as complex and nuanced and understanding as they possibly can." There's a lot there...
Jesse: I believe that statement. So, so that's a good test.
Jorge: That's great. But I feel like there's a lot there to unpack and I wanted to talk about it with you. The context of the podcast, Finding Our Way, is about design leadership, but this strikes me as a statement that might apply to leaders in any field.
Jesse: I believe that's true. I believe that any leader, anyone who gives direction to people in an organization, is on some level a steward of the organization's understanding of the problems that the team is trying to solve. And that understanding — when that gets systematized -information architecture is systematized understanding; it takes the associations between ideas that give meaning to human endeavor, human behavior, the world, and makes that concrete in ways that systems can then use. So that knowledge, that insight, can be scaled.
And a lot of organizations run into trouble when their information architectures internally don't match the nuances and the complexities of the problems that they're trying to solve. Either problems that they're trying to solve for users or problems that they're trying to solve as a business. Businesses are often getting caught flat footed by market trends that they didn't see coming because they weren't paying attention to the right signals. Because those signals weren't part of the fabric of their understanding of the problem that they were facing.
So yes, absolutely. We were talking about the context of design leadership specifically because that's what the mission of that show is. But yeah, I completely agree with you. It is something that I think is a part of what leaders do for organizations is give shape to the ways that organizations, hold onto the ephemeral meaning that otherwise just lives in the heads of the people in the organization.
Jorge: Now, this is something that has been happening for way longer than we've had the phrase 'information architecture' and I'm wondering if there are any practices, tools perhaps, that have been around for a while that might point to this function of leadership, as a going concern for leaders.
Jesse: It's an interesting question because honestly, a lot of the sensitivity to this stuff, when you're talking about what data does an organization collect, what systems does an organization put in place to make sense of the data that it has collected — this kind of stuff often ends up being the domain of like IT and business analytics and people who do some serious number crunching, which is fine and great. And, in the case of a lot of organizations... I've done a lot of work with financial services organizations. Insurance companies are fascinating in this respect because the actuarial tables rule all, in that business. And the keepers of the actuarial tables really are, expressing a point of view about what constitutes risk in the world.
Jorge: And that is a formal structure of information that is stewarded by someone in the org, right?
Jesse: Yeah. It's the foundation of the business. If your actuarial tables, as an insurance company, don't reflect the reality of things, then you're a bad insurance company, because you're likely to take on risks that you shouldn't.
Jorge: What this implies for folks who are either in positions of leadership or aspiring to be in such positions, is that A) they need to embrace systems thinking, right? A systemic perspective of the work. And the other is that it would behoove them to look for the structures that best articulate the core of the business somehow. And there are formal information structures in a lot of organizations. You've pointed out that in the case of insurance, they're very manifest, but what you're saying there resonates for me in other fields as well.
Jesse: Yeah. It's definitely something that I saw in my consulting career across, a lot of different kinds of organizations. I feel like every organization has its own sort of arbiter of truth, internally. I think one thing that we've been doing for a long time as UX practitioners, or at least, one thing that we often did as UX consultants was encourage the leaders that we were working with to step into storytelling as a tool to be able to make their case for what they wanted to do from a design perspective.
Storytelling is a sense-making activity. It's a way of giving people an understanding of the world. It's very similar to information architecture in that way. So, for leaders of any stripe, whether you're leading a design team or whether you're leading any other kind of team, to take a step back and ask myself, "Where am I the sense-maker for the organization? Where am I the one who is interpreting and giving meaning to information?" And sometimes that is happening largely in Slack or emails to the team or other kinds of communications, and sometimes that's happening in the context of more formal data structures like you and I have been talking about.
So, if the leader is noticing and attending to sense-making as a core part of the value that they bring to the organization as a leader, then they can look across their communications and the various pools of data that they may be responsible for tending and to interpret what they're doing in terms of creating more robust and more nuanced and more accurate information structures.
Jorge: I'm hearing two things there. One is that leaders need to have the wherewithal to understand the organization, its context, its goals, its way of being in the world — understand it in some kind of systematic way. And the other thing I'm hearing is that they also need to be able to reflect that understanding back to the organization — through things like stories — in ways that affect how the team understands what they're doing, basically.
Jesse: Yes. It gives meaning to the team's activities by placing those activities in a larger frame — a larger context.
Jorge: In my experience in interacting with teams and organizations and their leadership, I get the sense that these two functions — the "let's first structure the environment for ourselves, and then, let's think about how we share that structure with others" — they're happening, to greater or lesser degrees, in different organizations. But they're happening somewhat informally. Like, I haven't seen too many processes to say, "let's now draw up the information architecture for what we're doing here." Usually, when people talk about information architecture, it happens in the context of redesigning the website or making changes to the navigation structure of our apps or what have you. And in some ways, those projects end up being kind of MacGuffin for these deeper conversations that need to happen. And I'm wondering if there's a way to overcome that gap where we do information architecture more explicitly in service of having the organization understand itself better, or the team understand itself better and its role.
Jesse: Yes. I have done work like that in the guise of process work, that engaging with a team, trying to understand what the different elements of the team are, what each element of the team is intended to accomplish, how those pieces are supposed to work together. In order to engineer any kind of a process like that, that has to be rooted in an understanding at a conceptual level of what are the factors that go into play in producing whatever the team is there to produce. Or achieving whatever the team is attempting to achieve. And how are you making sure that all those factors are accounted for? And how are you setting priorities among those things? These are all decisions that inform the process work, but that's not the process work. That's the IA work that underlies the process work.
Jorge: Is this more of a top-down or a bottom-up effort?
Jesse: I think of it as being more of a top-down effort, just because I am... I've been thinking a lot about stewardship as one of the elements of leadership that we don't really talk about. Which is that you have a group of people and a set of resources in your care as a leader. And that creates certain obligations from my perspective, on you as a leader, to ensure that you pass those things along to the next leader in the healthiest possible state that you can. And that means looking out for your team. It also means looking out for your processes. It also means looking out for your systems. And it also means looking out for that deep, underlying understanding that drives all of those things. I mean, where are leaders doing that information architecture work right now? I'd say they're doing it every time they structure a document that presents to their executive leadership what they want to try to accomplish with their work.
Jorge: What that hints at — to me at least — is the fact that this storytelling function that you were talking about earlier — the part that has to do with sharing with the rest of the organization, the understanding that we have of our own understanding — that act of telling the story influences the understanding. It's like the two are related, right?
Jorge: There's a feedback cycle happening, where you put it out there, you say, "well, this is how we see things." And maybe your peers and other groups might say, "no, it's not like that at all. From our perspective, it looks like this!" And that tweaks your own architecture, no?
Jesse: Yeah, I mean when we talk about cross-functional collaboration, what we're often talking about is the process of aligning the differing information architectures. The differing models understanding of the problem that these cross-functional teams have. That the design team has one understanding of a problem, technology team has a different understanding of the problem, business folks have a third different understanding of the problem. These things need to be reconciled in order for those teams to move toward a common goal together. So, we don't end up with the design team is designing a car, but the engineering team is building a submarine while the business folks have sold to the senior leadership that we're building an airplane!
Jorge: This is such important work, and it strikes me — just in hearing you describe it — that it's something that happens often as a side effect of other initiatives. It's not like you set out to explicitly build that understanding and compare the delta with the understanding of that other org. It's more that both of you are tasked with collaborating on something and the process of collaboration is what surfaces these distinctions.
Jesse: It forces it! Yeah. You're not really doing it as a separate explicit step because it's part of everything you have to do as a leader, in a lot of ways.
Jorge: It feels to me like we're talking kind of in the abstract when we talk about these understandings. And when we say that somebody is presenting to their colleagues, what might come to mind is something like a slide deck, right? And folks tend to gravitate towards things that they can see and understand. And the slide deck might be the manifestation of this understanding, but it's not... it might not be its purest expression. And I'm thinking of things like concept maps, where we map out our understanding of a domain, just not even for sharing with others, but to understand it ourselves. And I'm wondering if in the process of stewarding this understanding of who we are, what we do, what our role is, how we're structured, what our processes are... I'm wondering if there are artifacts that could embody that kind of abstract understanding?
Jesse: I think so much of it depends on the leader. And I feel like what you're reaching for, or suggesting, is a mode of leadership that is really kind of an IA-centered or an IA-driven leader. And that's a very interesting idea to me. I haven't met one. You know, I would say I have met some leaders who, because of their experience with collaborative ideation processes, are used to getting their ideas out in a way that is still abstract. You talked about concept maps. That's a great example. Mind mapping is a tool that I've seen business leaders use. That is definitely an information architecture tool. You're doing an IA process when you're engaging with mind mapping. But they wouldn't necessarily think of that as IA work. And they don't necessarily make it central to how they analyze problems or make decisions.
The people that I've worked with who have been those kinds of leadership roles tend to be a little bit more constrained and not have formal tools for getting their ideas out. They just communicate. And they do it in the context of structuring and organizing their communications. And a lot of times, that is what is foisted upon them by the communications culture of the organization. I have worked with organizations where there were such strong cultural... Taboos around what you could and could not do in the context of a slide deck. Where, you know, like I had worked with an organization, for example, where if you had anything that was going to the board of directors, the Deck had to follow a very specific structure and format. And if your idea needed more than three to five basic sections to express that idea, your idea was not ready for the board of directors.
Because they were consuming so much content from across a very large organization, they needed everything encapsulated and summarized and standardized so that they could make the decisions that they had to make. But what that forced on the entire organization was a communication style that drove out nuance. Drove out conversation. Drove out a lot of what you're talking about, which is that moment to moment flexibility in the decision-making process that you know, for a lot of decisions is utterly necessary.
Jorge: Yeah, it comes back to this notion of top-down versus bottom-up, right? Because the implication there is that there is a level of nuance that is inappropriate for folks at this level. And that's a questionable stance, I think.
Jorge: So, you advise leaders, you advise folks who are stepping into leadership. How would someone who is either in a leadership position or looking to get into leadership, how could they develop these particular muscles?
Jesse: The way that I talk to folks about design leadership, who have come from a design background -that is to say they've been doing design work — is that leadership is just another design problem. And you're working with different materials and you're working toward different outcomes and you're having to follow different principles, but the task is the same task. It is a creative problem-solving task. It is a systems-thinking task, as a leader. So, looking at the ways that you're already doing that systems-thinking, the ways in which you already doing that architecture for yourself in the work that you're already doing, and those will be your strengths. And those will be the pillars that you can lean on that are going to support your work as a leader going forward. They will evolve and they will not look like what they looked like when you were doing content inventories or task flows or whatever other artifacts you might've been working on as a designer. But the skill set that you're building is the same skill set.
Jorge: So, it's in you, you just have to recognize it as such, and build into it. Which is kind of what we've been talking about, right? Getting the sensitivity to read the environment and articulate it in a structured way.
Jesse: And also, to remain true to your own perspective. You know, I see a lot of people who step into leadership for the first time, and they start trying to emulate what they've seen of other leaders. Which is a totally natural thing to do. It makes total sense. However, every effective leader leads from their own strengths and recognizes that those strengths are going to be different from the strengths of the people around them, and leverages that difference. And leaders who try to emulate modes of leadership that don't suit their natural abilities, they struggle. And they create a lot of hardship for themselves that they don't need to have if they could just believe that they already had the power. Because I believe they do.
Jorge: Well, that strikes me as a fabulous place for us to wrap this conversation. It's an empowering exhortation to folks to be themselves and develop their own powers. Thank you so much for that, Jesse. Where can folks follow up with you?
Jesse: You can find me on Twitter. I'm @jjg. I'm also on LinkedIn from time to time these days. You can find our podcast, Finding Our Way, at findingourway.design, and you can find out more about my coaching practice at jessejamesgarrett.com.
Jorge: Well, thank you so much, Jesse. It's been a real treat having you on the show.
Jesse: Thanks, Jorge! It's been fun.