Sarah Barrett is a principal IA Manager at Microsoft. She's been writing compellingly about information architecture in Medium, and in this conversation, we focus on her most recent posts, which deal with how architectural scale affects our perception of information environments.
- Sarah R. Barrett
- @documentalope (Sarah Barrett) on Twitter
- Known Item (Medium publication)
- Microsoft Learn
- World IA Day
- Breadcrumb navigation
- Rachel Price
- Websites are not living rooms and other lessons for information architecture by Sarah Barrett
- Understanding Architectural Scale: Tabletops and landscapes by Sarah Barrett
- Microsoft Bob
- The Informed Life episode 17: Rachel Price on Improvisation\
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:
This episode's transcript was produced by an AI. If you notice any errors, please get in touch.
Read the transcript
Jorge: Sarah, welcome to the show.
Sarah: Thank you for having me. This is so exciting.
Jorge: Well, I'm excited to have you here. For folks who might not know you, would you mind please introducing yourself?
Sarah: Sure. My name is Sarah Barrett and I lead the information architecture team for Microsoft's Developer Relations organization. So, in addition to the kind of stuff that you might think of as standard developer relations, like advocates going out and doing talks about Microsoft technologies and that kind of thing, we also have a huge web presence. So, we publish Microsoft Docs, developer.microsoft.com Learn, which is a training and kind of like micro-learning platform. All of the information about Microsoft certifications, a Q & A site, a whole bunch of other stuff. So, it's really everywhere where we're not trying to sell you stuff; we're just trying to teach you how to use all of Microsoft technical products. It's a really fun, huge problem. And we've got a good-sized information architecture team for information architecture teams, which tend to be small. So that's really exciting.
Before that, I was a consultant and I worked with a lot of different companies looking into how they solve their information architecture problems. But I wanted to go in-house somewhere, so I could actually sit with a problem and work with people in order to make it happen rather than just creating some shelfware, which everybody does, no matter how good your work is because organizations just aren't ready for it. So, I've been in house there for about three and a half years. It's been a really fun challenge.
Jorge: That's great. I think I'm going to be revealing my age here by saying that at one point, I had an MSDN subscription where I would get these big boxes full of CDs, basically. And I'm guessing that with the advent of the internet, those things are no longer distributed on CDs and your team looks after the organization of all that content. Is that right?
Sarah: Yeah. So, I mean, the funny thing about information is that it did not arise with the internet, as you know. This stuff has been around for a really long time. And even you know, a tech company like Microsoft is newer than many others, but like all of that information about MSDN did not go away. And MSDN TechNet, which was kind of IT pro side... originally, they would mail you physical CDs, and that was kind of the gold standard. Then all that stuff got put on websites. There was msdn.com. And we just finished migrating all of msdn.com over onto Docs - docs.microsoft.com. A lot of that information is still stuff that we're half-heartedly organizing and trying to find a place for because that history is so long.
Jorge: From my brief experience with it, I get the sense that it is a massive amount of content. And it's also content that is undergoing constant revisions, because it deals with the documentation that developers need in order to use Microsoft's products and platforms, correct?
Sarah: Yeah. So, it's a funny thing, because I sort of feel like if you were to go to docs.microsoft.com, which is the main thing we publish, you'd look at it and go, "somebody does the IA for this?" Like, it doesn't look like there's a lot of IA there — which, I promise you, we do! And we're even good at it. It's just a huge... it's a huge problem. It's a huge space. It's an enormous ecosystem of things. And a lot of the work we do is really around strategy and policy and winning hearts and minds and that kind of thing. It's been a long process. And yeah, because it is so big, so many different teams at the company publish to it, it's really more of a platform than a product.
The way you talk about websites as places and emergent places rather than products or services or something like that, is extremely true for us, because it is something that lots of people are creating in an ongoing way all together, in perpetuity. And it changes constantly. So, a lot of what we do is try to adjust rules, try to incentivize different behaviors, create standards and structures around what people do rather than just architecting a site and saying, "cool, it's architected. There's your IA! It's done." There's no room for that in our work.
Jorge: What I'm hearing there is that you are more the stewards of the place than the people who are structuring the nitty gritty content. Is that fair?
Sarah: Absolutely. You know, we create guidelines for how you structure a table of contents or the kinds of things you put in navigation. We don't actually do any of it for you if you're a publisher on our platform.
How websites are not living rooms
Jorge: Well, that sounds super interesting, exciting, and necessary, I would imagine, especially in such a large distributed system. I've been wanting to have you on the show for a while, but what prompted me to reach out to you was a post you published to Medium called, "Websites are Not Living Rooms and Other Lessons for Information Architecture." I was hoping that you would tell us a bit about this. What do you mean by "websites are not living rooms?"
Sarah: This article that you're talking about came out of a workshop I put together for World IA Day, when you and I last met in Switzerland. And the idea of the workshop really arose out of this work I was doing at Microsoft, which is so different from the consulting I was doing before. I often found, as a consultant, people are very ready to treat you as an expert. And oftentimes when you come in as part of a consultancy or an agency, some project sponsor or kind of some champion for there even being an information architecture problem that needs to be solved by a consultant, has done so much legwork for you in convincing everybody that this is a problem, in convincing everybody that information architecture is a thing. You know, somebody has done so much of that work. And so, everybody's very primed to treat you like an expert and accept the basics of what you're telling them when you come in in that context.
When I started at Microsoft, I was the only information architect. There are more of us now, but at the time it was only me. And in retrospect, like I still can't figure out why they hired me, because I spent the first, probably 18 months I was there going to meetings with extraordinarily nice and talented people who I adore... but going to meetings with them and then being like, "I don't see why you have to have breadcrumbs. I don't see why things in the navigation all have to go to the same website. Why?" And it was... it wasn't hostile, but it was a challenge to explain the first principles of everything that tend to be true about information architecture. Like, "yes, you ought to have breadcrumbs on every page." Like, "yes, the steps in the breadcrumbs should go to pages where you can get to the subsequent breadcrumbs!" Very nitty gritty details like that, where I had never had to explain how breadcrumbs worked before because usually we all just have such a shared mental model about them.
And one of the things that comes out of this so frequently, and the example I use in the article actually comes from my colleague Rachel Price, from her consulting days where people often come with a very simple idea of how they feel like it should just work. And those ways, like, "why can't we just..." so frequently comes from an experience in the real world, where I think the example that Rachel has is she was working on a product that was for college students. And the product manager was like, "why can't it just be a dorm room? And my backpack is on the floor and my wallet is in my backpack. And if I need to change something about my payment, I go in the backpack and I get my wallet. Why can't it just work that way?" And as an information architect, like I know in my bones that the answer is, "it can't. That will not work!" But it's really actually very hard to explain why, other than like, "that's weird and we tried it in the nineties! But it won't work." And so, a lot of this article is about like, okay, why does that idea of structuring something like physical space — why does it feel so appealing? Why does it seem so easy? And then why is won't it work? Why is it a red herring?
Jorge: And what you're talking about here, I want to unpack it for the folks who are listening, is the idea that you can structure a digital system in ways that mimic the ways that we structure our physical environments, where we do things because, hey, we're used to operating in a living room or an office or what have you, why can't we just have the same affordances and signifiers, but presented in a two dimensional screen somehow. Is that right?
Sarah: Yeah. And it seems like it ought to work, but it really doesn't. And it's because... and the point I'm making in the article is that there are implicit rules to how physical spaces work and I'm actually working on the next article in this series to unpack some of those more. I'm trying to get it published this week as we record it. But I have a two-year-old, so we'll see how that works. There are implicit rules to how these spaces work in the real world. And it's easy to mimic the look and feel of a physical space without actually following those implicit rules. So, we need to unpack what the implicit rules are.
Jorge: The example that you bring up in the article is one that... again, I'm going to reveal my age by saying this, I remember being on the market, which is Microsoft Bob. And there might be a lot of folks in the audience who are not familiar with Microsoft Bob. How will you describe It for someone who hasn't seen it?
Sarah: It wasn't the only one of these kinds of products. I think there were a lot of them in the early days of software and the internet. We didn't have this one, but I remember the very first computer I used that accessed the internet... it had other things that were like this. But it was basically that Microsoft was trying to sell the idea of an operating system and a personal computer to a home market. And in order to make it more accessible and appealing, they tried to structure the desktop, or like the operating system, as if it were a house. And so, the idea was that your accounting would be in a checkbook that was on a little drawing of a desk, which was in a study. And if you wanted to look at your contacts, that was in a Rolodex on the desk. If you wanted to do something that wasn't in a study or an office context, you would go to a different room, and that would be there instead. And it has some weird rooms. I've never actually used it, so I've only been able to kind of piece it together from stuff on the internet. But there's like a barn or something — it gets very strange! There are obviously parts of it that are just silly, where, you know... why do you need that room? But there are also parts of it that just, again, they don't follow the rules of how architectures are going to work, so it's not going to work. And it provides a kind of fun counterpoint to realistic requests and objections that you do get doing this kind of work.
Jorge: We use the desktop and file folder metaphor in interacting with our… let's call them personal computers as opposed to mobile devices. And that is a metaphor; it's not inherent to the underlying technology. Why would you say that the desktop and file folder metaphor works whereas the architectural metaphor doesn't work as well?
Sarah: Yeah. I think there are a couple of things going on. This is very much like the subject of the next article that I'm working on. Which is that I would argue that our brains understand space at different scales. And we understand what I call tabletops, but you could also call a desktop or something like that in a very different way than we understand larger scale physical space, like a room, a house, a city, and then you even get into a nation and understanding that scale of space, which is huge. We understand those things in very different ways, and a lot of the ways that the personal computer and like the notion of the desktop have evolved to work mirror the ways our brains expect tabletop-like spaces to function. Tabletop-like spaces, I think in general... you can see them all at once or at least see how you would get to all of their pieces at once. And they consist of small moving parts. In a very similar way to how, if you're working at an analog desk, you can just have your stuff around you and you see it in your peripheral vision and you can affect most of the things around you.
This is very different to how larger scale spaces work, where you can't see them all at one time and you have to construct a mental model of that space by moving around it and stitching those pieces together over time. There's a whole neuro-biological component to this where we have certain kinds of cells called place cells that fire in certain kinds of circumstances that tell you, “Ah, this is a new place." And that doesn't happen when a small object moves around you on a tabletop. It does happen when you move from room to room. And so when we're in more operating system-like experiences or more app-like experiences, you know?
You and I are talking to each other on Zoom right now. That really functions like a tabletop. Everything's right there. I could open stuff up, but it works more like drawers or something like that. It's not at all like something like Microsoft Docs or the BBC's website or any other kind of like large, content-based website, which is really much more like a landscape where you have to kind of move around from place to place and reconstruct a picture of it.
And so, the big argument there — and this is something that I work with my designers on a lot — the big argument there is you have to be really clear about what you're building so you know what kinds of rules to use, because those things are actually really different. And most of the time we just kind of go, "eh, it's sort of like an app, right?" Like, "what is this app like?" And it’s like, "Oh, its website-like." We know that Zoom and the Wall Street Journal don't and shouldn't work the same way, but we have a hard time articulating why. And for me, it's that difference in architectural scale and how our brains understand it.
Jorge: I find that idea super intriguing. I'm wondering if you could elaborate or give us examples of how something like the Wall Street Journal would differ from something that is more... I don't know, a communication tool like Zoom.
Sarah: Yeah. So gosh, I wish I'd opened the article up, because I haven't thought about this a couple of days, but they vary in some kind of predictable ways. One is the scale of the things around you. Something like Zoom tends to have a lot of little pieces or I use Keynote as an example too. The reference, in the real world that you're using as metaphors, tend to be smaller and the actual elements in the interface tend to consist of a lot of little things. Whereas in a more landscape-like environment, you're dealing with a few big things. In a real-world landscape, those are buildings. Those are landmarks. They are mountains that are far away, as opposed to like objects that you have on a table around you.
And we have a similar scale with the tabletop kind of apps versus landscape-y websites. You also get different degrees of agency. I have a lot of say over exactly what Zoom does. Perhaps not as much as one might like, but I can customize something about it, and I would expect that customization to persist. I can rearrange things. There's not a lot of expectation that I can do anything to gov.uk, other than maybe put my information in a form. I'm not going to do a lot of customization. It's not going to remember a lot of details from time to time.
We also talk about kind of how you interact with the thing. The best way to learn something like Zoom, even if they put an overlay on it, is just to kind of poke at stuff. You know, turn that on and off and see what it does. You move things around you, open up settings. It really rewards interaction. Whereas with a large content-based landscape-like website, you have to move around. You're walking around and looking at stuff. You're moving from page to page and forming that mental model rather than poking at stuff to see what it does.
There are a few different things like that. And then they come with different expectations too. There's a real expectation of intimacy with tabletops or with app-like experiences, even if they are a web apps. You kind of expect that it's yours in some way, and you don't expect that kind of of more websites that seem more like public goods. And we run into funny situations with that, like with things like Twitter, which I would argue functions like a tabletop, even though it's kind of a web app. You can experience it as an actual app too, but it's mine. I don't go anywhere. I just push buttons and do things on it and my stuff is there.
And there all kinds of stories about people getting wildly upset about a new line showing up or a design change happening. I remember how much everybody freaked out when they went from 140 to 280 characters. You tend not to get such a feeling of ownership and people being so concerned about changes in websites that feel like public accommodations. You know, people have lived their lives in docs. They spend tons of time there. They don't tend to care very much about the exact details of the design or something like that. Because it doesn't feel like theirs.
Jorge: If I might reflect that back to you, this principle of understanding the scale at which we're working seems to have something to do with the degree of agency that you have over the thing that you're interacting with. And the more granular the level of control that you have with the thing that you're interacting with, the more... I'll use the word intimate, maybe the more like personalized... it's something that you use as opposed to something you inhabit, in some ways. Is that right?
Sarah: Very much so, yeah. And I think it's really like, "does your brain think that this is a place or not?" We don't expect places for the most part to be only for us that no one else could ever get into. It's an easy jump to be like, "ah, yes. Other people are here too. This is not just only for me." Whereas something at a much smaller scale... like, I don't expect other people to be messing around with my nightstand. Or my desk at work. Even though theoretically they could, but it's my stuff and I left it there. And there's that greater expectation of control and of intimacy.
Jorge: Great. So, I don't know if to call these principles or just things to be mindful of when doing this kind of work. You've mentioned scale as one of them, and you've already said that there's another post coming out specifically on that. In the post that is currently published, you mentioned three other principles, if we might call them that. And I was wondering if you could, recap them for our listeners. So, scale is one. A second here you say, "leverage the principles of naive geography." What does that mean?
Sarah: I came across a really interesting article a few years ago that is by geographers for geographers, which is like not a field I'd thought about at all. And I was looking into the idea of cognitive maps and cognitive mapping with the idea of like, "oh, do people have like complex maps in their heads that they navigate and are those things the same in the real world and the digital world?" And the answer is, for the most part, no, we don't have maps that have any integrity to them. There are a couple of exceptions, but this was the theory for a while, and it's been pretty disproven. It's not a thing we have.
We do, however, have representations of ways to get places in our head. I distinguished between the kind of tabletop more small-scale and the landscape more large-scale because we don't need these representations and we don't form them for small scale experiences. If you can rely on everything you need being in your peripheral vision, your brain doesn't bother remembering where everything is. Because it can get that kind of continuous sensory input. But for these larger-scale experiences where you have to construct a representation over time, and you have to reason against that to figure out where you're going. We construct those representations. And the interesting thing about it is that we're very good at it. I talk about that a little bit in this article with all kinds of cultural traditions that rely on remembering things by relying on how good humans are at remembering places and how to get between places. We're very good at it. But like more interestingly to me, we also make a lot of mistakes while we do it and we make those mistakes in predictable ways.
So, one of the principles of naive geography that I think is just fascinating is that for the most part, when we remember things, we remember the earth as flat and square. We're very bad at remembering or estimating depths and heights in comparison to lengths and widths and distances and that kind of thing. Our brains really smoosh everything down. We also, for instance, think about distance in terms of time, not absolute distance. And so, they have eight of these or something like that. And the idea was that naive geography is how everybody understands geography and makes geographic calculations, even if they are not geographers. And they compare it to the idea of naive physics, which is that you can tell what's going to happen when you throw a ball without being a physicist. Like we can figure that out. The same way as we can give directions, we can make judgments and we can reason based on distances without being a geographer. And we're good at it, but we're also bad at it in these kinds of known ways. And I found that almost all of those ways are relevant for digital spaces as well as physical spaces. So, we go into exactly how those work and how you can apply them to your designer information architecture work.
Jorge: Another principle here says, "check your wayfinding." That sounds like it's related to this concept of naive geography. What's the distinction here between wayfinding and what we've been talking about so far?
Sarah: Yeah. I think of it as, naive geography is what humans do. And developing wayfinding principles or instantiating those way-finding principles in our designs, is what we as information architects do. Basically, it's great to know that people's brains mislead them in this standard way that we can predict, but you have to turn that into something that we can use because nobody I work with cares as much about neuroscience as I do, you know! Or geography, or cognitive mapping, or any of these things. We have to change it into guidelines and principles that I can give to product designers and developers and that kind of thing. And so, for wayfinding, it's really bringing it out of the more esoteric and theoretical space of like landscapes and tabletops and whatever is happening with cognitive geography and this kind of thing into like, "okay, what does that mean?" It's very simple stuff that I largely adapted from museum exhibit design, where it's like, "hey, you need to make sure people have landmarks. You need to pave paths so they know where to go." And we tie that back to the principles of naive geography to figure out why.
I tend to illustrate this with grocery stores because I find that they have great wayfinding and it is way more accessible than a lot of the other examples people use like airports, especially with none of us have been in an airport for a year. And grocery stores make a lot of complex things very findable. I often have conversations with stakeholders where they're like, "well, no wonder nobody can find anything. We have 200 products!" And like the average grocery store has something like 800,000 SKUs, and you never are surprised that you can find your brand of maple syrup or be sure it's not there. Which is like the gold standard of wayfinding as far as I'm concerned. So, you can use the structure well enough to be sure that something doesn't exist. "Oh, that's so findable, it's great!" So, we talk about the specific things that you need to check that you're doing in your experience to make sure people can use those naive geographic skills they have.
Jorge: And that's a learned skill, right? Knowing to expect something to be there and realizing that it isn't because of its absence is something that you have to pick up. This weekend, I took my kids to Barnes and Noble. They were wanting to buy some books and as convenient as it is to do it online, it's still quite pleasurable to browse through the shelves. And I was explaining to them how the books are organized alphabetically by the author's last name on the shelves. And that came up in the context of looking for a specific book and realizing that it wasn't there because the author's name wasn't on there. That's kind of what we're talking about here.
Sarah: Yeah, absolutely.
Jorge: This example of the grocery stores is also useful in that perhaps we understand these organization schemes at different levels of granularity. Once we understand how a grocery store is organized, we can find our way from the very highest level of the organization scheme all the way down to a specific product. And, at the highest level, the distinction that sticks in my mind is this phrase that I've heard used for people looking to eat healthier. They say, "shop the perimeter." Shop the edges of the grocery store, because that's where the fresh foods are kept. Whereas all of this stuff in the middle is processed foods. And that's a very high-level distinction that once you understand it, you can navigate that environment differently.
Sarah: Yeah, that's also a great example of being able to reason based on a structure, rather than on content. Which is another gold standard of doing information architecture, I think. If somebody can understand the structure and your wayfinding and experience well enough that they can go, "hmm, I'm going to go around the edges!" Rather than saying, "I'm going to go to the lettuce and then I will go to the chard!" You know, that's what we dream of creating for our users.
Jorge: I want to move on to the last of the principles that you present in the article. It says, "use standard elements intentionally." What do you mean by 'standard elements'?
Sarah: Occasionally, I get comments or people worrying that our information architecture isn't innovative enough that we're not doing anything surprising or introducing anything brand new. And I feel very strongly that your architecture is not the place to surprise people. Like, there are actual architects out there building very innovative homes that no one wants to live in. And I have no interest in doing that. I really want us to use the oldest, most standard, most expected way of doing things. I think the example of the grocery store is another great way here. There's a lot of benefit to not innovating in the layout of a grocery store. There probably is some benefit in innovating a little bit around the edges or in some details, but you gain a lot from making it legible and making it expected for people. And so, that one is really about... okay, given these things that we expect to have: we expect to have global navigation, we expect to have metadata on content, we expect to have titles and breadcrumbs... how do we unpack what each of those things is doing for us and make sure that between the suite of those elements we are using? Because you never use just one, you use lots of them together. Between all of those elements, we are presenting a coherent, complete view of the wayfinding people need.
And this comes up a lot for us in things like design reviews, where the group will decide that we really don't need a content-type label on that card. And I'll say, "okay, the thing that that is doing for us is this thing!" Like, it is fulfilling this wayfinding need. How else are we going to do that? Because if you want to take this label off, I have to pick up the slack somewhere else. Whereas if somebody says, "oh, hey, I think we don't actually need..." I don't know, "we don't use breadcrumbs on this page or something." I can say, "okay, cool." Because actually that same need for being able to zoom out or being able to orient yourself relative to a landmark is actually being taken care of in these three other ways on the page already.
So, if we lose that one, it's okay. It can help you make decisions about those trade-offs with design elements. It can also help you check the things that you absolutely need to be coherent with each other, that you need to be consistent because they're trying to do the same thing. And if they give people two different sets of information, that's worse than not having it at all.
Jorge: It's an exhortation to be mindful about not just the elements you're using, but why they're there, right?
Sarah: Yes, and all of this is really because, again, I had ideas about what I was doing as an information architect and I didn't have great answers for the little granular-wise. And so this is a result of my exploration of, okay, well, why? Why do we need them to work that way? And so, I'm sharing it with everybody else.
Jorge: I'm wondering how thinking this way has affected your own work?
Sarah: So much of information architecture is in the people and not the models. And so, my work has been about gaining allies and building relationships and getting people on board, and a good explanation that you can be confident about that doesn't rely on, "just trust me!" goes a really long way. Being able to break it down and decide where I make trade-offs and where I can accept more dissent, where I can encourage that and really learn from it versus where I really need to double down and say, " no, we need this." That's made a huge difference in my ability to get things done and to just build better experiences.
Jorge: Well, that's great. I'm very excited to see the upcoming posts in the series. It sounds like you're well ahead with the one about scale. Where can folks follow up with you to keep up to date with what you're writing and sharing.
Sarah: Yeah, you can find me on Twitter @documentalope, or you can find everything I and my colleague Rachel Price write at a Medium publication called "Known Item."
Jorge: Fantastic. And I have to call out that Rachel is a previous guest in the show as well. And I'll link to the conversation we had in the show notes. It's been so great having you on the show, Sarah.
Sarah: Thank you so much. It's been fun.
Jorge: Thank you.