Page: [00:00:00] I think we are people whose jobs are to collect data and then tell stories about it that are compelling. I really think that's what a UX researchers real job is.
Erin: [00:00:38] Hello everybody and welcome back to awkward silences. Today, we're here with Page Laubheimer.
He's a senior user experience specialist at Nielsen Norman group. Today we're going to talk about information architecture. Thanks for joining us page.
Page: [00:00:48] hi. Thanks for having me.
Erin: [00:00:50] We've got JH here too.
JH: [00:00:52] Yeah, the IA topic makes me feel like we should have a, a perfectly laid out plan for this conversation. We should
Erin: [00:00:57] Oh, no, we should have card sorted
JH: [00:00:59] Yeah, we should have all our
Erin: [00:01:00] even uh, next time, next time.
Page: [00:01:03] Yeah.
Erin: [00:01:04] All right. So Page, what is information architecture? This is our first episode on the topic. green field let's dig in. What is information architecture?
Page: [00:01:15] Yeah. So I think information architects have been trying to put a pin on exactly what it is that we're doing for such a long time. And it, you know, honestly, I think if we had a snappy little definition, we probably would have a lot more influence and pull out there.
The way I tend to think of it is it's the organizational parts of UX work and really kind of digital work in general. So, I mean, there's the kind of, I think of it as kind of two different pieces, right? There's the part of it. Where we are dealing with the sort of visible parts of interfaces that are organized, right? So things like navigation and even just, the structure on the page and how we create a sense of hierarchy in which information is most important.
I think that is all the most obvious sort of information architecture work, but then there's the big part of it that I think is really the stuff that is. The most challenging and the stuff that keeps information architects busy is dealing with the kind of underlying metadata problems and figuring out how to make connections between things that are seamless, but they are a little less obvious.
So, that kind of breaks down pretty nicely to do sort of foundational concepts in IA. One is the idea of findability, right? The idea of someone has something in mind, whether it's a little blurry or it's very in-focus and then try and seek it out. And then you have the stuff where someone might stumble upon something discoverability, right.
That is useful to them, but they don't really have it in mind beforehand. And I think. You know, those two IA, there's kind of two parts of IA or are they somewhat linked up to those ideas, right? So we're trying to make things find-able for people who know what they're looking for. And then we're trying to make things discoverable for people who are a little less certain, or they might not be aware of something that's really useful to them.
You know, our job is to do all kinds of organizational fiddly work behind the scenes too. Facilitate both of those things. And in perfect information architect fashion, I gave a long answer to what seems like a straightforward question, but I think it's one of those parts of UX that tends to get a little neglected.
And I think it's really some of the most foundational stuff that happens in UX work.
Erin: [00:03:36] Oh, I love, I love that framing because okay, so information architecture, right? We're talking about how information is right. Is organized. That's pretty clear, but this framing of it's users who are trying to make sense of this information and two kinds of modalities for that are, I know what I want help me find it, or I don't.
So you've got a kind of blockbuster, like a video store. I just want to browse around and then you've got Google the sort of epitome of at least I think I know what I'm looking for. Right. Like give me that. But I imagine a lot of you know, sites and apps, libraries are combinations of both modalities, is that.
Page: [00:04:16] Oh yeah. Absolutely. Yeah. I mean, and you know, it's not like we can just say, Oh, we're going to focus on this one thing and leave the other right. I mean, we have to, because the human beings on the other side of things, you know, they're pretty varied in what they need and how well they have it sort of mentally modeled. So we have to do both parts of it. And I think this sort of the second sort of modality we're talking about there this sort of discoverable, I don't really know what I want, you know, maybe kind of making connections between things a little bit more clear that weren't otherwise, that's the part of, of information architecture work that I think is really.
Exciting and a place to really dig in and that, that's the kind of stuff that will keep UX people who are interested in this, busy for their whole career. I think redesigning navigation that often has a start and an end point to it, there's. There's often places where we can keep iterating on it over and over and over again, but that's a project, right?
Whereas I think the sort of continuous sense-making and connection making and metadata management and taxonomy work and all that kind of fun stuff is ongoing maintenance work, which I think is fun and exciting. And, you know, I at least would love to bring more of a spotlight to it and the people who are doing that kind of work.
Cause I think it's really critical for, you know, organizations scaling up their content or their product or whatever it is they're working on.
JH: [00:05:42] Do you find that discoverability and findability go hand in hand or are they kind of go, are in conflict with one another or is it situational, like is an experience that has good findability tend to also have good discoverability or is that just like super contextual and it depends on every case.
Page: [00:05:59] Oh, that's such an interesting question. Yeah I guess to some degree there, so I think of them as a little less binary than that, right. I think, and I think this is where we start getting into the real nuance of it too. Is that when we think about someone seeking out something they have in mind already.
Think about all the times where that process kind of goes tangential, you know, as you're going. So, I mean, think about like when you're searching on Google for something. I remember, you know, recently I was really trying to find some sort of device I could put near my front door that would tell me what the temperature is outside.
Right. And I didn't want to pull out my phone. For whatever reason, I decided like, Oh, I don't want to be bothered with taking my phone out of my pocket and checking the weather before I decide which coat I'm going to grab, in early spring. And so I was looking for some sort of device that I could just put near the front door that would tell me what the weather is outside and.
You know, beyond just the temperature. And I realized, I didn't know what the word was for this.
JH: [00:06:59] Yeah. Yeah. Yeah.
Page: [00:07:00] Right. And so I started by Google searching and it would give me suggestions. And I realized that I was taking a lot of different pathways and that there were a whole bunch of different things out there that could kind of solve this need for me and sort of, as I was going, I was learning the language of it.
And so that's, I think one of those examples of where they're kind of related in a way that's often. Hard to untangle, I guess, is the way that there are relatively few situations where findability is so cut and dried, you know, sometimes you might have like someone who is a professional really knows the lingo.
What they're looking for. So, you know, maybe you have someone who works in healthcare and they just want to look up, what's the appropriate dose for a medication that they know the name of. Right. And that's a pretty straightforward findability task. But then there are all these sort of sense-making kinds of searching processes, where I think findability and discoverability get really there's a push and pull between them and sort of figuring out ways to.
Making the interface itself help guide people like refinement of their searches and refinement of their strategy for looking for stuff is a really big part of it. And that's not just search too, right? I mean, You know, so far, I've been kind of talking about things in this sort of, you have an empty search field and you're typing things.
Maybe the interface is giving you some feedback about suggestions there, but this also comes up in things like navigation menus, or related content on a website where we were making those connections behind the scenes. So it's all kind of intertwined in a way.
JH: [00:08:38] that makes sense. The example you gave about Google hits home, I was literally just a couple of days ago, trying to find this little like clamp clip thing on Amazon for something I need to run my house. And I couldn't, I didn't know the name. And so I was trying to think of the right search to get there.
And I'm just thinking about it now, as you were sharing that example of there's something about the Amazon taxonomy that makes it intimidating to try to drill down into hardware and find the right category. So just searching and trying to get there. But then I'm thinking of like, if I was in a home Depot store, I think I would know what aisle to walk into and probably just be able to discover it that way.
And so it's, I don't know. There's a lot here that back the findability and the browsability thing is a very interesting interaction.
Erin: [00:09:16] Well, and this is all changing too all the time. Right? Cause we were talking about search and you're talking about clicking on navigation, menu items, but page you got into this maybe a little bit, but now we have voice. We have Alexa like, you know, that we're interacting with these new technologies, these new ways of interacting with technology.
And then of course there's all the predictive stuff happening in the background. And so I think. When I first thought of information architecture years ago, that kind of web 1.0, those, you know, nav menus and so on, you know, word, clouds, texts, whatever things you can click on a very kind of linear.
I'm going to input this thing. You're going to spit it back out. To me, it feels so much more fluid now and robust and multiple touch points across different input factors. And so it's a lot.
Page: [00:10:07] Totally. I mean, that's what I think is so exciting about information architecture work and why, I think it's the eternally relevant discipline in UX. Right. So, you know, in UX it feels like every few years we're kind of shifting our, like, focus on what specifically we're designing. Right? What, the way you mentioned voice and conversational UIs and how that was sort of a big, I don't know, maybe zoom out moment.
A few years back when that started to really become something that designers had to be thinking about. Right. And maybe someday we'll be designing for VR and AR in a much more sort of common way than we are now. And you know, all these sorts of ways of like, how are we? How are we manifesting our design ideas, right?
What does the interface look like? But I think the challenge of taking a bunch of stuff, a big messy pile of stuff and putting it into an orderly fashion so that people can find their way through it is sort of eternally relevant. Right.
Erin: [00:11:08] right, right. And it hits into all sorts of adjacent you know, areas of a company of like what is our strategy? And like, you know, what is all this stuff? Why do we have all this stuff? How does it all relate in our mind? So it gets into these pretty big questions. And how does that relate to what users think?
What are we going to say, Jake?
JH: [00:11:26] I was just gonna say the word architecture in this feels very like intentional. Right. And it kind of goes back to what you described Erin as, you know, early days web 1.0 in IA is kind of like maybe the navigation menus or something. And obviously it's much more than that. It's like, there's something about the word architecture that makes me think it comes early in the process.
Like we got to figure out the bones of this thing before we do everything else. Is that kind of like why that word is used or is it just, I'm just curious about that piece of it? Like where do you see it in the process? Is it, I mean, obviously, probably ideally it's continuous, but just curious how you think about that aspect of it.
Page: [00:11:58] Yeah. The first time, the first place I was ever aware of the term information architecture was a book by Richard Saul Wurman called the information architects, you know, and I think you're very right about the intentionality of that word is the ideas that we're building a structure. And that, that structure, the choices we make, allow for the element of growth to kind of happen in a comfortable way or in a sort of shoe horn way. Right. And that's where I really think of the term, the sort of built environment metaphor that gets used all the time and information architecture. I think there's a tendency to think of it as a process. Right. So, you know, when you're building.
A physical structure. Right? You have to make decisions on how the structure is going to be formed because you can't really change it easily. Right. Unless you're going to do something like a major addition to a building, which is intensely disruptive. In IA, yeah it certainly can, and often should be early stage, but it doesn't necessarily have to be.
I think that's one of the ways in which that metaphor of the built environment sometimes is less helpful to us were the things about that kind of physical architecture metaphor that I really like are that the sense of planning for future needs and kind of, growth, and then also paying some attention to the idea That our choices are consequential, I guess is a way of thinking about it is that, you know, if you build a building, it is.
It sets a lot of the tone for how that building is going to be used, what the neighborhood is gonna look like, all those kinds of things with information architecture the way we set up that kind of structure does suggest a lot of what's going to happen next, right. And how things will grow. But we are lucky enough to be in a position where we don't have to.
You know, star information architecture work at the very beginning of a project often fits in nicely there. And I think that is generally a good idea to be doing, but, you know, there's always room to do information architecture work. Even if it's not something like we're going to tear down the navigation structure and put up something completely different.
I see companies doing. IA tweaks and nudges all the time. Right. So I, you know, one thing that I always love to look at is around the holidays on e-commerce sites and how their information architecture, like the navigation structure actually changes to S to sort of surface up. Gift giving and things like that.
and that's an intentional change that's temporary. And I think that's, where we really step back from that kind of built environment metaphor. Like we can play around with things and we can tweak things, but that was a little, a bit of a tangent compared to what you actually asked me, which was, you know, where does this fit in the process?
And, yeah, I mean, I think it is really good to start projects off that way, but. Only if you really know what the content or features or whatever it is that you're organizing are going to be. Right. So if you're starting a brand new project, oftentimes the information architecture works site as sort of naturally fits in a little bit later, when you have a sense of what it is you're building, right.
And what the things are going to be, because, if you're, when you try and organize something before you actually have it in place That gets tricky. And you make a lot of different decisions than you would if you have the stuff you're organizing in front of you.

Erin: [00:16:11] So Page, we've talked about a couple of different, several different kinds of, sort of applied IA. Back to the navigation items, the search input field you know, interacting with a voice kind of interface. Are there some, I don't know, less obvious, well known examples of applied IA that it's like, Oh, that's IA at work.
And that, ongoing work. You talked about the less project based, but you know how information architects can. Be part of ongoing product development cycles and what that might look like.
Page: [00:16:48] Oh, yeah. I mean, there's a huge number of places where it crops up unexpectedly. So one that often surprises people is that information architects are absolutely critical to machine learning and AI projects. Right? So, you know, when you're training these machine learning models, you have to have a well structured.
Dataset, right? I mean, that's part of it is if you're, training and image recognition, AI, to be able to tell when some, when it's a picture of a dog versus a picture of, you know, a bicycle or whatnot you have to have some metadata in there. That's consistently doing that.
And a lot of the machine learning work out there is based on some pretty well-known taxonomies out there that were built by people who have that kind of information architecture bent.
But a lot of times, you know, those algorithms are. Pulling from just really well-structured metadata, right? It's not just, Oh, you were looking at, you know, a weather device for your front door and you were also I dunno, looking for a backyard umbrella for your patio, right? It's not just, Oh, we sense a correlation between these things, but there is typically some kind of information structure in the background, some kind of taxonomy that can kind of show some of those connections between things.
So, You know, good connections between individual pieces of content or features or whatever it is that you have is often done by information architects kind of manually applying metadata and cleaning up the metadata scheme that they're using in the background. That's another big thing that information architects are often doing, right.
Is figuring out like, Oh, this tag that we have in our content management system is actually really similar to this other one someone introduced a year later, let's kind of do some cleanup work and merge those, right. Or maybe we create two separate ones that have some nuance difference and apply them with some intentionality there.
And I find that's often the, you know, when I keep talking about this sort of work, that is not as visible to people. I think that's a lot of the stuff that people actually spend their days doing.
Erin: [00:18:57] And then that example, you mentioned, like I'm imagining like a Spotify or, you know, tons of examples of recommendation engines. Is it like the AI cruise? Like, you know, Hey fellows, it's time it's tag cleanup day, or is it more you know, like we're seeing less interaction with like. You know, next related songs after the playlist is over and, you know, one hypothesis is like some of the metadata needs a refresh.
Like how do you know it's time to go in and kind of do a spring clean on your metadata? Are you seeing performance issues or is it just like good practice to, for every 2 million pieces of metadata, you know, go in and clean it up every so often.
Page: [00:19:41] Yeah. Wow. What a great question. So yeah, I mean, I think of it like people who are really attuned to their product we'll know. It's almost like having a pet or a child where you can kind of tell that maybe it's not feeling so well. Rather than necessarily having a metric that says, Oh, you know, our backend metadata is suffering in this way.
Right. You often just sort of start to see some kind of subtle signals. Right. So yeah, things like in Spotify, you know, I would imagine that their team is pretty attuned to how people are engaging with. The sort of algorithmic suggestions and, Oh, maybe, you know, we noticed that there is kind of a drop in, you know, engagement with this sort of thing.
Or people are skipping this kind of song when it follows this kind of song. And maybe we can figure out what's going on there, but for other teams, it might be, you know, you're working on something and you said, you go through and you notice, Oh, Hey, these two things are there's overlap or there's discontinuity between them.
And maybe it's time to deal with that. And I think, when you have people who are spending a lot more of their time, really heads down on that work, that's often where it pops up, but you know, one of the places I always look for sources of problems with information architecture and especially the metadata is search, right?
So if you can get the engineers who own the search feature and they can give you a log of the, every search done in the last. 30 days or 90 days or whatever, you know, whatever volume is actually achievable for you to read through them. You're going to notice a lot of things where there's kind of a disconnect between what people think of something as, and, you know, the words they use and how to make those connections.
So, yeah, I mean, it's a little bit of a holistic approach when I guess.
JH: [00:21:29] Yeah. So do you see like the information science, ontology piece of this, like. The taxonomy side. Is that like just in the IA umbrella or is that like a different discipline that gets borrowed from, or I've actually never thought about that. I've always kind of viewed it as a little separate, but the way you just described it made a lot of sense.
So
Page: [00:21:44] Yeah, I mean, you ask five different people in this world. You'll get five different answers on that one. I think of them as related. And I think of them as sort of, you know, typically people who work on ontologies or who are professional taxonomists have, very often may have a graduate degree in that in information science.
And they're trained to do that. I, so, you know, I'm not necessarily suggesting that, you know, the average UX or wants to immediately jump into, linked data structures and all that. But I think there's a lot of connection there. And to be honest, if you are an information architect and you're working in a larger organization, you will probably spend a lot of time working with the folks who are kind of taxonomists or information scientists or knowledge managers, right? If you work for a really big org that is trying to manage institutional memory, that's locked up in human beings, heads knowledge management is another discipline. That's really related to information architecture that I think is. We're dealing with the same sorts of things, right.
We're dealing with how human beings conceptualize things, what their assumptions are, how to take the implicit and make it more explicit and then make it put it into structures where people can reliably access it. So yes and no. I mean, I think a good information architect can move into that space pretty easily.
And I think they will Probably need to have a working familiarity with that stuff at some point.
Erin: [00:23:12] Page, how did you get into this line of work?
Page: [00:23:15] Uh, So I started off as a kind of librarian. So, I went to, you know, libraries, library, school and the whole kind of library and information science training. So I, you know, I do have that background. That's where I kind of. Learned about complex metadata structures and link data and you know, all of that kind of stuff.
And I worked in science libraries for a bit, and that was an area where, you know, that is sorely needed, sense making of Huge volumes of resources. Right. I would get scientists who would come to me and basically say like, I need a bibliography of every journal article ever published on the connection between diabetes and arsenic exposure.
And finding every single published paper on this right. That's a huge challenge. Right. And so figuring out how to query the appropriate databases to grab stuff. Is a big part of that job. And then the other half is taking all of those resources and putting them into some sort of order that the scientist can make sense of.
Because they have pretty limited time to sit around reading papers. So the bibliography you put together for them Has to be something that is really focused on what's going to be most relevant to them. You're doing some sense-making work on just the output of like a database. So that kind of turns out there's a little bit of a connection there with UX.
And so I, you know, I'd been exposed to UX work in graduate school, and so. Kind of all connected and, you know, I found myself working in the agency world for a while. And there's a lot of information architecture work that happens in agencies, right. When you're building a sale, a website for someone else A client, oftentimes that's one of the hardest fought areas of building consensus and buy-in is the words we choose for things and how we sort of organize them.
I think most people who've done some IA work are probably familiar with the politics that go into just choosing the order of the items in your top level navigation menu. Right. And that, every kind of business unit owner wants to have one there. Their business unit, right. First in the navigation menu.
And so sort of, that's sorta how I found my way into this space and, you know, it's endlessly exciting. I, at least for me, but I'm a very particular flavor of nerd, I suppose. So,
Erin: [00:25:37] Yeah, we like our nerds here. You're in a safe space.
JH: [00:25:40] The term library school that I
Erin: [00:25:41] yeah. Yeah. Is that real? Yeah. No, that's yeah, no, I know.
JH: [00:25:45] No, it makes sense. Yeah.
Erin: [00:25:47] Oh, settle a bet for me while you're talking about the fierce debates that can happen over NAB strictures and what things get called? Is it ever just semantics, page?
Page: [00:25:56] Sure. I mean, absolutely. But that to me is not something that's dismissive. That to me is all the more fuel on the fire. Right? I, so I am one of the people that strongly believes that the way we use language really matters for how we understand the world.
What we choose to call things is incredibly powerful. And so yeah, sometimes those fights over semantics do really matter. And frankly speaking, the people who end up using our products, most of the time, they're not familiar with what we call things anyway. Right. And so those fights over semantics are awesome.
I think that's great stuff, you know, it, you know, and it can be more than just sort of like philosophy 101, you know, is pizza really a sandwich kind of debate.
Um, but yeah I do think it's just semantics and I think that makes it all the more important.
Erin: [00:26:51] right, right, right.
JH: [00:26:53] Gotcha. So if you want to do IA, well, I assume from a research perspective and a discovery perspective, you need to have a good toolkit. The one that comes to mind, I think we said it earlier is just card sorting, but there's gotta be more to it. Right? So like, what are some of the things or techniques you go out to deploy to figure out how we actually improve this information architecture?
Page: [00:27:10] Yeah, totally. I mean the two big research methods we have in IA that are specific to IA, really our card sorting is the most famous one. And I think often the most over-utilized one, because I think card sorting is a great technique. Do not get me wrong. But what I find is that most people do a card sort and then they get the kind of data back from it.
And they're like, what do I do with this? Cause it's not, you know, it's not black and white. It doesn't tell you like, do this, do that. Right. The output of that kind of research isn't a clear answer. You still have to make decisions. You still have to. Provide sense-making. So that's, you know, one of our tools, but I think of it as a pretty nuanced one.
And I, I often think it's the hardest one to really use effectively. And it can be a huge rabbit hole if you don't really go in with some, with some specific ideas about what to do with the results of it. The other big research method that we have that is called tree testing and tree testing is it's a little bit more diagnostic.
It's a, it's basically where we test out a hierarchical structure for findability, right? So we've stripped it's, you know, almost like a usability test without the interface, right. Where we're just focused on findability. And so basically we have our menus and that's it. And we ask people, where would you find.
A, you know, digital weather meter, right. Or whatever thing you're trying to have people find. And all they have are the menus to look through and. Tree testing is another, it's a great tool. It tends to be a much more quantitatively focused tool, I think is, you know, though it can be used qualitatively, but it's a tool that tends to give you very clear metrics about, what, how successful were people at finding things?
How directly were they able to find things, right? Did they have to take a really winding path or did they go right to the thing? How long did it take them? So those are kind of the two pieces, but, work, you can learn so much from just a simple usability test. Like, I mean that there, there's a reason why that is just the most.
That's kind of like the lingua franca of UX research, right? Is that a usability test that can tell you so much about, just about anything. And that's often where I would start on a project with information architecture stuff, because you're going to get a lot of good. Data about a bunch of other stuff too.
So you're not just kind of spending all your time and energy, just on the IA. You're getting a bunch of stuff that is useful throughout the project, but you can run findability tasks. And that also gives you a lot of good information on sort of, when do people lean towards using search? When do people lean towards using the menus?
When do people just click onto it? A topic page and kind of followed links from there. And all of those are going to give you a ton of great information architecture, insets, right? They're going to tell you about, do these words we've chosen make sense to people or is that totally confusing and some sort of, you know, internal speech that no one else can understand.
Right. Do we organize our menus in such a way that. Basically reflects the internal corporate structure or does that actually reflect how other human beings think about this stuff? So I think all three of those are being told totally totally, yeah. Useful tools for IA work, but yeah, card sorting is the most, well, it's got the best publicist of all of the sort of information architecture work, but you know, when you do those studies, I have found that I.
Have had to spend a lot of time being really disciplined about looking at that data because it's so easy to start looking at, you know, the number of times that two, any two cards got paired together and trying to figure out what does this all mean? Right. And it can get very existential in a way that's often not super helpful to keep things on track.
Erin: [00:31:04] Yeah, my first few months here at user interviews, like I had done some content UX, my background in content. You know, but really just. Digging deep into this world of UX research. And we were planning our field guide, which is like our robust evergreen resource on UX research stuff. And, you know, we had a good sense of the kinds of things we wanted to cover, but you know, how are we going to organize.
This in a way that makes sense to researchers. So I'm like, what the hell? I'll do my first card sort. I don't totally know what I'm doing, but it's going to be alright. And I'll write about it, you know? So it'll be like meta content on UX research content, and yeah, you get the data back and you're like, Oh no.
And of course I did an open card sort, which is all the more confounding. But I do think you learn so much Page in that like triangulation process with qualitative data, whether it be a card sort or something else, it's not gonna make it easy for you to get from raw data to insight. Right. And I think that's where so much of the work of a trained UX research professional is that sense-making of all of this data, right?
Page: [00:32:13] Oh, yeah, that's such a great way of putting it, right. I mean, I think we are people whose jobs are to collect data and then tell stories about it that are compelling. I really think that's what a UX researcher's real job is, you know, we are often. Asked to give numbers when the thing that would benefit the people around us most are stories and, you know, taking all of this like hairy data that is just, it's not straightforward and that's part of the fun, right?
That's what makes this a job that resists, easily automating it is that we have to apply human sense-making and we're our job is to take it. Things that are inherently pretty complicated and bring clarity to it, right. Not necessarily always simplicity, but certainly always clarity. And to me, that's an endlessly exciting and you know, energizing thing to have in front of
you.
Erin: [00:33:17] Do most of the people that you work with on a, you know, you, you train folks and do workshops and engage with lots of different people, but in your experience, I'm sure it depends. But do you tend to work with, you know, UX folks who kind of like to do IA projects here and there are more like dedicated, you know, information architecture.
People and yeah, what's w who's doing information architecture these days and how good of a job are they doing? Good work.
Page: [00:33:47] I mean, so I think the days where your job title is information architecture and you were really specialized on it full time there they're not over, but they're, those kinds of roles are a little bit less common. They tend to also be kind of a little bit challenging, cause there's often not a lot of institutional support and there's kind of a little bit of a, what do we do with you?
You know, who do you report to, who do you talk to kinds of jobs that saying that they are out there, but I think sometimes they do exist a little bit more as the kind of as JH was talking about like the kind of, ontologist taxonomist kind of work, right. I think a lot of the times IA work is done by The, you know, if you have like a UX team of one, they're often really the person who ends up pushing that effort, or if you have someone who's a UX designer, they're probably putting a lot of their time into it.
And I think that's okay. You know, I don't think that I mean, I love information architecture and I would love to do nothing but that for the rest of my life. But I also think there is some real value in mixing that in with the sort of tactical. Work of designing interfaces, right. Or researching how human beings think about things.
I think both of those pieces fit together swimmingly well. Right. And it doesn't mean that you're sort of a Jack of all trades. Like you can absolutely develop really thoughtful information, architecture, practice, even if it's something you're only doing part of your time.
Erin: [00:35:15] And so given that it's, it seems like the trend is largely for it to be, you know, a part of versus a totality of folks' job. Do you have any? Pointers for folks given how, you know, how sweeping this sort of field can be to get on the right foot. You know, card certs you mentioned can be, you know, really powerful, but also really tricky.
And obviously with a mixed method field, you know, you don't want to apply that everything's a hammer, right. Sort of. Philosophy. So yeah. What are some good principles or rules to live by when you're doing IA, if you're maybe not an expert or doing it all the time?
Page: [00:36:00] Yeah. The most important thing I would say is words really matter. Basically words are our interface for information architecture, right? That's really the only user interface we've got for the most part. I mean, you know, we can talk about, hamburger menus and side navigation and all that kind of stuff, but the words are really fundamentally what we're allowing users to interact with.
So pay attention to words, right. Get really comfortable with Taking the same concept and expressing it a bunch of different ways verbally, right. And pay attention to the economy of your word choice, which is apparently something I'm completely unable to do when I'm talking. But You know, focus on putting yourself in a position where you choose the fewest number of words, focus on clarity.
Learn about the big differences between what you and your coworkers call things and what your users call things, because that is sort of endless. Source of improvements that you can make. And it's often not that hard to learn about. Right? I mean, pretty much any user research method you're going to engage in will have the opportunity to teach you about what words your users choose for things.
And when words that you've chosen, don't. Really makes sense to them, right? Your whole job is to be as clear as possible. And I think that's the biggest starting point is really focusing on, we have this kind of funny concept in IA called information scent, right. Is, you know, and it's another kind of goofy metaphor that we use, but it's all about this idea of like good word choices for things.
Good labels for. Content they, you know, if you were sort of a, like a dog in the forest, you know, following an animal you're going to be kind of following the center of that animal and their users are kind of doing something similar, right. They're sort of paying attention to the words and sort of how much they suggest what's going to be in that.
Category and how much, you know, to what degree does it smell like I'm going in the right direction, right? It's very much a sort of intuitive process. So, you know, the more you can understand how people conceptualize the underlying content that you're organizing and then the words they choose to describe it. The better off you're going to be as an information architect and that's luckily something you don't have to do just IA work to get really good at.
Right. And find other people on your team who care about this stuff, right? There's probably someone on your team who, you know, when you post a Slack message, like correct your grammar, right. That person is an invaluble resource for you to, you know, to bounce ideas off of, right. That person is going to be great.
Go talk to the marketing department. They've got very specific. Ways of using language now, you know, you have to be careful there because oftentimes they're seeking to use, you know, kind of branded language and that kind of thing, but
JH: [00:38:57] Do you have an example of where the words really did matter like a project or, you know, a story you worked on were changing. Some of that stuff had a huge impact.
Page: [00:39:06] gosh, I do. I'm trying to think of one where I can kind of give a little bit more Background into it. So, you know, I work on a lot of healthcare client projects. And so one area where I remember I was working with a client on an essentially an electronic health records system. Right. And you have these people who are kind of trained.
The people using the system know what they're doing, right. They're not, you know, you're not pulling people off the street to start entering in information into someone's medical. Right. But there was a hole. Conversation we had about whether or not to refer to an like a connected test result, right.
From a lab test as pending or as there were a couple of other word choices we were looking at and we tested them all and it turned out that there were some very specific implications with the word pending about whether or not that test was the results themselves were actually final.
Or whether it was sort of an API pending, right. Have we fully downloaded all the data into our system or is this a thing where, you know the lab technician hasn't finalized the test results yet? And this was something we only really learned through doing some testing with users and that, you know, choosing the word pending there turned out to be completely inappropriate, right.
Because we were talking about a sort of data. Transfer issue rather than one where it was what the users conceptualized as pending. And I know that's a kind of very specific thing, but this is often the case where, you know, a word we choose that seems innocent sitting like what else could be pending means, right.
It is not done. It turns out in this case it had a very specific technical meaning. So,
JH: [00:40:47] Nice. Yeah, I like that.
Erin: [00:40:49] I've got one for your page. We were looking at, if you've worked with, used or worked with clients who use CRMs, right. There's usually a notion of like a contact. Right. Which is like, you know, like an email address or something like that. And often you pay for how many of them you have. And there's a lot happening, like in the UX world, right.
Where it's like, Oh, like, should we call users? Or is that dehumanizing or right. Should we call them customers or just call it people or humans or. Whatever. And so we saw an example of someone who seems to have like, sort of done this. And so instead of calling them contacts, they're calling them people, which is great.
Right. But then the trouble is when you talk about the paying mechanism, you say, you know, you can buy a hundred people for whatever. And it's like, well, that's problematic. Right? So it's, the sniff gets tricky, right? Because it's in one context, the word might be great. And then another, it can be really problematic.
Page: [00:41:45] Yeah, totally. I think that's like such a great way of Thinking about it. And, you know, sometimes it's something as simple as like you're putting together a B2B website. Right. And you do choose solutions or services. Right. You know, that's the famous one where solutions sound like, Oh, we are being solution oriented.
Right. We deliver goals, not, not a bucket of consulting hours. But it turns out that a lot of times the end users of this Are a little less likely to click on a menu item like that, because it has less of that. What we call information scent, right. Where it's, you know, I'm not saying they're never going to touch it.
Right. And they're going to close their web browser and run away screaming and, you know, put a hex on your company and never come back. Right. But it is, you know, a lot of times we'll we're adjusting for and optimizing for here is just making things a little bit more likely to be used.
Erin: [00:42:39] Yeah, absolutely. Page, thanks for joining us. Great to have you here
Page: [00:42:45] Oh, this is a lot of fun. It was great to meet you.