Tent Talks Featuring Dan Brown: The Information Architecture of Products

[00:00:35] Chicago Camps: Dan, could you start by giving us an overview of what “the information architecture of products” means to you?

[00:00:41] Dan Brown: Yes and no. I’m still trying to figure that out. I feel like when we talk about information architecture, we talk about it so much in terms of content, right? We talk about it so much in terms of language and categorization and labeling and things like that.

[00:00:57] I’ve always defined IA as the design of structures. And that dovetails really nicely with this sort of idea of, okay, we’re going to create a set of categories, whether it’s hierarchical or whatever to fit content into. But structures are not exclusive to content driven sites. We need to design structures for all kinds of things that we find on the web.

[00:01:23] Whether those are content driven or other kinds of products. The last, what, 10, 15 years, we’ve seen this explosion of web-based products or digital products.

[00:01:34] And I feel like a lot of that design work happened without being mindful of the underlying structures. It’s not that it lacked structure. I don’t think you could come to design a product without a structure. It was that people were not being mindful of it. And we can talk about the myriad of reasons why that’s happened, especially in the last 10 or 15 years.

[00:01:59] So the way I’ve been thinking about it is products that have been We need an underlying structure in order for them to make sense, right. In order for users to engage with them, in order for us to maintain them. And the information architecture of product is being mindful of thinking about and being deliberate about what that underlying structure of a digital product is so that we can accomplish all of those things.

[00:02:26] The hard part, I think, is that it doesn’t look like a text, it doesn’t look like a content mapping. It doesn’t look like a site map. It doesn’t look like a navigation menu necessarily, right? There are all of these artifacts from content driven information architecture that are, again, meaningful in that context, but don’t necessarily have a meaningful analog on the product side.

[00:02:51] I’ll just say one more thing from a historical perspective. When we talked about IA. In the early days of doing IA, it was, we always made this distinction of sort of content driven or transaction driven or interaction driven, right? And I think that idea that sort of transaction or interaction perspective, I think has gone away to some extent because it’s become so pervasive, right?

[00:03:15] Because we do so much of that kind of stuff online. Now that’s not as prominent or meaningful distinction, but, where we used to do flow charts and wire flow diagrams and things like that to explain those kinds of pathways through those transactional products, that I think is the precursor of what I’m thinking of as the IA of products.

[00:03:39] If you then do what MVPs are supposed to do, which is teach you about what you got wrong and nobody does that or if they do, I have not seen or heard anyone do that very well yet. The problem is we have this notion that, that the MVP kind of sets some precedence, right? And any structural decisions that you make, whether you’re mindful and deliberate about them or not, any structural decisions that you make tend to persist throughout.

[00:04:08] One of the products I’m working on now has this problem. It wasn’t so much that they launched with an MVP, but they launched with a certain set of assumptions about what the underlying structure is. And now as they’re trying to scale to address different kinds of needs they’re extremely constrained by that precedent setting, first version of their product. I don’t know that a information architecture is an anathema to an M V P. I think you can start to conceive of the underlying conceptual model of a product without necessarily getting it all detailed, but have an understanding of what you want that structure to be and understand and think deeply about where do I need the GIF and what compromises are we make? What assumptions are we making? I think the biggest problem is not so much that the precedents are set. So that’s an issue. It’s that they haven’t thought about, okay, what if I got this wrong? I had Hà Phan on my podcast a couple of years ago about this. She talked a lot about sort of product planning and how crucial information architecture is for product planning, because it’s not just simply like, I’ve got this string of features that I want to start adding.

[00:05:17] It’s like a good product manager, good product team has that map in their head at the outset, hopefully right in the ideal world. Let’s map out what all the features are. Let’s map out how all this stuff fits together. And maybe we only can launch with this portion of the underlying conceptual model, but we know how the other features are going to fit in.

[00:05:41] If you don’t think about that, and again, this is things that I keep seeing on product teams over and over, we have to compromise the feature or break the existing structure, which confuses users and changes their expectations, right?

[00:05:55] There’s lots of things that can break. When you haven’t mapped out the whole season, you know how the show is going to end. You can only start with this much of it. You can only start with one episode.

[00:06:06] Chicago Camps: Could you provide an example of a product that, in your opinion, exhibits an exceptional information architecture and what makes it stand out?

[00:06:15] Dan Brown: No, is the short answer, but the longer answer is I used, in one of the articles I wrote about Product IAs, Harvest as an example. Harvest is, I would not say the heart and soul of 8 Shapes, the design firm that I run with Nathan, but it’s certainly a very important part… it’s a respiratory system, but like everybody who worked with us for us uses Harvest to track their time.

[00:06:36] And one of the things I love about Harvest is it’s super opinionated about how everything fits together. So when you think about a time tracking app, you think about, okay, I need projects and I need tasks and I need people, right? I’m naming nouns, right? Things that have to be represented in this product, right?

[00:06:57] When we talk about product IA, think about what are the big ideas that they need to represent in this product. And I need to think about how those things are connected to each other. Okay. I need to be able to record my hours, right? So with a certain amount of time that’s associated with a task that’s associated with a project and each person can be assigned or not assigned to a project, but it’s super opinionated about some of these things where it’s, you can’t add time to a project that’s not associated with a task.

[00:07:25] So always have to put hours associated with a task that’s associated with a project. And it means if I’m working on a project and maybe it’s a new task or I’m not sure where it’s supposed to go, I can’t just simply put hours into that project’s bucket, I’ve got to associate it with a task. To me, that’s a very opinionated underlying conceptual model.

[00:07:47] That doesn’t necessarily ring true for everyone, but Harvest is saying, this is how you have to do it. Another thing is tasks are not unique to a project. So you can create a library of tasks. That you can then assign to a project or project becomes a container for all the different tasks associated with it.

[00:08:08] But if I have a task that’s unique to a project to add it to the sort of global library of tasks, again, this is a very opinionated position on what the relationship is between projects and tasks relative to an organization. I don’t know if it’s right, you know, it’s good. It works for us, but. What I’m saying is what I love about it is that it’s opinionated and they maintained, at least from the outside, looking in, they’ve maintained the integrity of that conceptual model.

[00:08:37] And I think that’s appealing again, when you work on this in house, probably a lot of listeners are already thinking this, like how many times have I had to compromise on the underlying structure of my product because we’ve got this new feature that we’re trying to add, or we’re trying to do something new here.

[00:08:54] So now I need to break the model in this way or compromise the feature in this way. And Harvest, I think has done a good job of maintaining that level of integrity. In the old days, when we were thinking about transactional systems, things are very linear and they were very single role focused and what Harvest is, is a mediator between multiple parties, right? I think of enterprise products in one sense of it as a mediator, a way of using data to connect to different people who are connected to this process in different ways. Because of that there are enormous complexities with the underlying structure, right?

[00:09:35] It needs to collect the data from you, the expenseor, in, uh, one format and display it to the CFO, the person who’s making use of that data in a different way, right? That data is different. The way they make use of that data is different from the way you inputted it. So I think this highlights that underlying challenge of, information architecture.

[00:09:54] Ultimately, it’s a structural problem. We can talk about the interaction, we can, we can talk about the visual design. We can talk about the UI. All those things are relevant. I’m not dismissing their relevance, but the missing piece I think has been, how do we think about that underlying structure? How this information moves from person to person?

[00:10:14] Chicago Camps: How does the information architecture of a product influence user behavior and the overall user experience?

[00:10:20] Dan Brown: When we talk about mental models, we’re talking about how people imagine the structure of a product. So when I say to you, time tracking, I believe you have this mental picture. Even if you’ve never articulated it before of what are all the elements involved in time tracking or expense tracking? And how do they all fit together?

[00:10:39] You have that in your head for better, for worse, just sadly taking up space and everyone who’s done this kind of work. We have these mental models in our head and no product is going to match your mental model exactly. These are all hypotheses. I don’t know if this is true, but this is anecdotally, this is how sort of things have played out.

[00:10:58] So the mental models never match up perfectly, but our hope and our aspiration is that If you see something meaningful on the screen, using labels and relationships that are at least recognizable, you can potentially align it to your mental model, the mental model that you have. To the point what I’ve observed is that some people start to adjust their mental model to align with the product they see on the screen.

[00:11:27] If I were to go design a time tracking app now, having used Harvest for years, is my mental model of time tracking now influenced by the decade that I’ve spent using Harvest ? That’s an interesting philosophical question, put that aside for now.

[00:11:44] One thing that I get to do a lot of that has been reinvigorated my joy in this field is what I’m calling conceptual testing. And by conceptual testing, we’re going to show you a screen. That represent the structure and I want to see how different it is from your mental model of how you conceive of this idea. So one of the products that I get to work on is really about organizing people into groups. Let’s just leave it at that.

[00:12:13] And there’s a lot of nuance with this, especially when we’re talking about things for associations or volunteers, volunteer groups. There tends to be a lot of nuance around and every customer of this product is a little bit different in how they do it. So we’re trying to design a structure that appeals, that aligns with the mental models of volunteering in these different organizations.

[00:12:37] And we can’t design one that immediately aligns with everyone’s mental model, much less one of them. So how do we come up with a structure that they can at least adapt to or make sense of?

[00:12:52] I think that’s maybe a fairly abstract answer, but I don’t know how it influences user behavior, but it influences the overall user experience because it represents a certain amount of learning curve and cognitive effort. In order for me to adapt what I’m seeing on the screen to what my understanding is of this domain or this space.

[00:13:14] Now let’s make that smaller, right? Let’s just focus on the team. Does everyone know what they’re supposed to be doing? Does everyone have very clearly defined roles? Do you have mechanisms in place for managing tasks and making sure everyone knows what they need to be doing and getting done what they need to get done?

[00:13:28] Nathan and I were talking about this several months ago, and the way he put it was we don’t have standardized ways of working. And I really liked just that idea of we’re defining design standards, yeah, but what about standardized ways of working? And isn’t that a structure and don’t those structures become manifest in the products that we design?

[00:13:50] I’ve gotten very spiritual in my old age. I think that’s what this is.

[00:13:53] Chicago Camps: Can you share some tips for designers who are just starting to delve into information architecture?

[00:13:58] Dan Brown: It’s weird that we’re here. And by here, there are people who do this UX work, do design work who’ve never thought about IA. Maybe don’t even know what it is.

[00:14:10] I spoke to a graduate level class in user experience design. And I had to go back to basics. Like I was just doing a little guest thing on information architecture and they were like, well, but what is information architecture? And I was like, this is a graduate level program and user experience. I feel like the field of IA is hopefully re-emerging.

[00:14:33] There’s a lot more interest and focus on it. Maybe there’s an understanding that being deliberate about these underlying structures is important. And that a lot of the sort of bad places that we end up with our products come from a lack of focus on structure. I guess sort of two big things come to mind.

[00:14:51] One is try to articulate the problem, right? If you observe problems with a product, something that you’re working on, what is the underlying structural issue? And it’s hard, that’s hard thing to do, right? This requires some deep thinking, maybe a lot of conversations, but I think it starts to dredge up some weird existential questions, like in the case of Harvest, right?

[00:15:17] If you were working on that at the beginning, maybe take yourself back to the beginning of a product and go, what do we mean by project anyway? Or what do we mean by time tracking anyway? It’s weird, existential questions come up. And I think that’s the second thing I’m thinking. Try and diagnose and understand what the underlying structural issue is.

[00:15:36] But something that I think is a little easier to do is ask the naive question, whatever product you’re working on… What do we mean by this word anyway? What does this really mean? And again, it’s not an interaction design question. It’s not a visual design question. It’s a structural question.

[00:15:54] It’s what is this thing that we’re talking about? How do we define it? Because if you can align around one important concept then you can align around all the rest of them, but start with just that one. I think the challenge though, with that is that a lot of the literature that’s out there about information architecture deals more with that content stuff.

[00:16:14] That we were talking about, which is fine. The cognitive mechanisms that you use are very similar, but whereas content information architecture in a sense gets you one layer closer to the user. Product information architecture, Dan’s opinion and hypothesis here, is it’s a, it’s at a level of abstraction that may not even be visible to users.

[00:16:39] At such a core fundamental level to what the product is trying to do, the ideas, the labels, the definition that you come up with may not be immediately perceptible to the user, but they still influence the product. But yeah, by all means look at current IA literature, Abby’s (Covert) work is fantastic at speaking to a more common design audience.

[00:17:02] I think the harder part is making that leap from thinking about the structure of content to this, the underlying conceptual model. And I’m waiting for someone to say, Dan, you’re totally wrong. But this is the experience that I’ve had so far.

[00:17:20] Chicago Camps: Can you discuss the importance of understanding business objectives and user needs when designing the information architecture?

[00:17:27] Dan Brown: The three legged stool has not gone away, right? We were talking about three legged stool 30 years ago when we started doing this stuff, this idea that the design work needs to be informed, not just by, again, we were starting from a user centered approach, not just by user needs, but we have to understand the business objectives. What are we trying to do and accomplish with this product?

[00:17:50] And the third leg of that stool that you don’t mention here is the technical constraints. I bump up against these far more when I’m doing product related IA than when I ever did when I was doing content related IA. Not that content management is a solved problem by any stretch, but again, I think a little bit more accessible to talk about the categorization, the classification of content and modeling that stuff on the database side.

[00:18:16] But when we think about the underlying forces that put pressure on a structure, it really falls into these three categories. And that’s how I think of it is like the structure. We’re building a structure and it needs to withstand pressure from these three forces. The one force that you mentioned is the business objectives, right?

[00:18:36] The structure needs to be designed in such a way that it supports those business objectives and at the same time addresses any constraints by the business. I’m just thinking about time tracking and the fact that different organizations might have different needs relative to how time is tracked, how people have access to that kind of stuff, all of that is baked into those business constraints, business objectives.

[00:19:02] If there’s an organization that’s need to make sure that no projects can share tasks, Harvest is not the right tool for that, right? Cause Harvest as a structure in which tasks are shared among projects.

[00:19:16] Obviously user needs. I think in this case, it goes back to that mental model that I was talking about earlier. It’s not so much that a user has a need, they’ve got an objective and we need to design the product to meet that objective, but they’re bringing some cognitive biases into this as well. And we have to consider how well does our structure align with some of those preexisting biases.

[00:19:42] Doing this abstract work on the conceptual modeling side does not save us from doing any user research. We still need to understand what perspectives do people bring to bear on these domains, whether it’s time tracking or people management. And then the third leg of that stool is technical. And I’m running into this a lot that underlying conceptual model of how different entities relate to each other in the product ends up being baked into the data model of the product.

[00:20:10] A lot of the work that I do these days in order to take a product, adapt it and grow it and evolve it means working within the constraint established at the outset by that underlying data model, which has very opinionated views of how all of these different entities relate to each other.

[00:20:31] Chicago Camps: We have a question from our live studio audience “in your initial question, are you proposing the idea of developing a thorough future oriented design and subsequently breaking it down into smaller components so that you don’t have to change it to incorporate new features?”

[00:20:45] Dan Brown: I think it’s very similar to what we just talked about, which is: you can’t come up with anything that’s never going to change. That’s just not the nature of the work. But I think having an opinion of what the underlying structure is and being aligned with the rest of the team, and aligned is not necessarily agreeing with, but understanding and appreciating what the current definition of that underlying structure is.

[00:21:14] You also use the phrase future oriented design. I want to address that. I don’t think you need to design every last little bit of the product. It would be cool if we could, but if we’re making this sort of a TV show, we’re not filming every episode before we release it. Unless we’re Netflix, right?

[00:21:32] What we’re doing is we are outlining a script and a story arc, and we have a good idea of where it’s going to go. Even if the details are not fully fleshed out. But we’re still only filming one episode at a time. So I do feel like trying to answer some of those hard, fundamental, existential type questions, what do we mean by financing? What do we mean by policy?

[00:21:58] All these things that people assume they know the definition of, asking those hard questions, teasing out what those definitions are, how those things relate to everything else in the product. And at least mapping that out is as high fidelity as I think you can get.

[00:22:15] And it’s still pretty, pretty abstract and pretty low res, right? But it gives the product team a common language of what the product is, what it intends to be so that as changes occur, you’re still working from that same common foundation.

[00:22:30] Chicago Camps: Another question from our live studio audience, Upma asks, “I’m interested in knowing more about how you do the conceptual model and how that’s different from how I do the object map.”

[00:22:39] Dan Brown: I don’t know. I don’t know how you do an object map. It may be very similar, right? I know object oriented UX uses noun foraging and stuff like that. That may be very similar. I try and be chill about it. Let me just listen to how people are talking about stuff. Let me also not get too preoccupied with other people buying in to this.

[00:22:59] Maybe just use this as a tool for my own understanding of the domain. And the last thing I’ll say about it is I like the idea of concept better than object. And I like it because it doesn’t prescribe how it might manifest in the user experience. Whereas an object, I feel like you’re already starting to say this is going to be a named entity in the UX. It can be a named entity, it’s going to have properties, it’s going to have functions associated with it.

[00:23:30] And I don’t want to make any of those presumptions as I’m focused primarily on just trying to understand the domain and how all these things might could relate to each other. The other thing I’ll say is it’s just a framing thing as far as I’m concerned, and I think the framing in terms of objects may predispose you to think about, I’ve got to make sure all of these things have connections.

[00:23:54] I could be wrong about that, or what is the data connection between these things? And that may not be relevant for the particular product that you’re working on with within that domain. This is me guessing, but when I read those two things, conceptual model versus object map that’s what occurs to me.

[00:24:11] Chicago Camps: We’ve got a question from our live studio audience. Anthony asks, “do you feel that a return to basics in UX and modeling holds value? If so, how would you feel it might be best shared with the next gen UXers?”

[00:24:24] Dan Brown: We’ve done so much.

[00:24:25] There’s three decades worth of stuff that we’ve done. I go back and I read some of my old stuff and I’m like, oh my gosh, I’m still thinking about these same things. I can’t believe like Dan at 26 was thinking about the same things that Dan at 51 is thinking about, but also feel like things have come a long way too.

[00:24:47] I was just reading this article that I wrote a couple of weeks ago about design revolutions and how something like new technology can really just change how we do the design process.

[00:24:58] Remember design tools never used to exist in the cloud. And so we would have to save a file and share it with someone else so they could edit the file. And then if you had multiple copies of the file, things would become out of sync. That just doesn’t exist anymore if you’re using Figma.

[00:25:18] There’s stuff that we learned then that is useful and important, but I don’t know when you talk about basics, what occurs to me is not so much like how we did wireframing or things like that. I think instead of three things, one is writing. I feel like there’s been less than of an emphasis on just being able to articulate our thoughts with, uh, words.

[00:25:48] Another is presenting. These are the basics that I, I think are relevant. How do you take a bunch of ideas that you have and run a meeting about how this should be done. I think a lot of the designers that I ended up coaching, we talk a lot about, how are you going to walk through this stuff? How are you going to structure this meeting? How are you, what questions are you going to ask in order to draw people into this process?

[00:26:13] I think the last thing is. Being able to draw pictures to articulate your ideas. Collaboratively draw pictures to articulate your ideas.