 DC2 and everybody was half asleep. So I promise I'm not going to drone on for too long, and I'll try to be efficient about this. But if you do start to nod off, just let me know and I'll pick up the pace a little bit. We've had a lot of great tech talks today, so it's always nice to bring in a bit of a softer side of the service and talk about something like information architecture. I like to give a little bit of background on me for this, just so you have a clue about why you might want to listen to me for this. I'm wrapping up my graduate degree right now at Kent State actually in information architecture. We're just cool that we've gotten to this place in the digital landscape where we can actually get graduate degrees in this specialization. I'm also the partner and director of products at Firefly out of Vernon, Virginia, which is a six-year-old 10 percent agency. So we've been around for quite a while. What I do, my background is I'm actually a full-stack developer and a designer with a psychology background, which comes back into play now. I work across industries and markets, so I'm not specialized, I don't work in higher ed. We do see trends in the business though, asphalt right now is our big thing. So if you have questions about that, I can answer them. We work both at the corporate level, all the way up from Fortune 500 down to Mom and Pop Bain Street and with nonprofits. So we get a nice intersection there as well from a business perspective. We work in web and mobile and I love a good pun. So if you have a bad joke, please stay after and tell it to me. In today's session, we're going to talk about information architecture 101. What is it? It's a big word. What does it actually mean? We're going to talk about the best practices when you're going through an information architecture project. What to do when you get stuck, when I have a Q&A and most importantly, a giveaway at the end, so I make sure you stay. So information architecture 101, what does anybody think it is? What is IA? So structure, anybody else have any guesses? Skeleton, I like that. That's a good one. Very good. So information architecture, the definitions changed over the years. Somehow this field has been around for 30 years. It came around in the early 90s and just quietly existed for a couple of decades and they just boomed. When it first hit the scene, it was about understanding and looking at the big picture of a product or an experience or a website. Then it was also about the nitty-gritty and you'll see a repeated keyword in that second definition of systems that's really important. But over the years, I grew and modified into its contemporary version, which has a bit more of a diverse definitions that. We talk about things like organization, labeling, search, and navigation systems. We talk about the structural design of shared information, which is an exciting phrase for me, that it's an emerging discipline, which is interesting since it's been around for 30 years, but it's continuing to morph and evolve. So in some sense, it's still new. Then the one that I personally use is the art and science of shaping information products and experiences to support usability and findability. So looking at where we've been and where we're at now, there's a bit of a shared ground. We look at navigation and information organization, and information relationships. That's never really changed. But now in the modern space, we're hooking into the strategy of a project. We're looking at goals, both from the business side and the user side, and we're working in tandem with content strategy, which is a question that we get a lot as IA is, what's the overlap there, and there is. There's that great saying about how you can't lead a horse to water. I like to modify that, because one of my partners is a content strategist. I say my job as an IA is to get the horse to water. His job as a content strategist is to make that horse drink, and that's how the two work together. And then lastly, we're looking at architecting the entire structure of an experience. Before, it was very much large level or nitty gritty. Now it's both. Start at the top, and you work your way down. So the big bonus that comes out of actually putting information architecture in your skill set or your knowledge base, or as a part of your process, really is alignment. And there are three different keys of the alignment space where IA can really improve your products and your websites. The first one being users. IA at its core is a subset of user experience design. So our first concern is the user. What are the user's goals in using a product or a website? And it's important to keep in mind that the goal and the task that follows are very different things. The goal is something that you wanna achieve. I wanna buy a new shirt. But then the task might be something more specific. It's something that you have to achieve in order to complete your goal. I need to find a black shirt. So there are two very different things that we deal with as IAs. Then the information seeking behavior. This is probably one of my favorite things to deal with in the IA space is how people actually navigate and consume content. Are they searchers? What kind of searcher are there? We're gonna talk about that. Are they browsers? Are they somebody who comes into a website at its homepage? Do they come into a website from a referral and go directly to their content that they wanna get to? We take all sorts of those context clues into the factory experience. And then the overall experience, both from a business standpoint, what's the ROI? That's everybody's number one question from a client perspective. If I'm going to spend X, what am I gonna get for it in return? From a user perspective, if they want to buy that black shirt, for example, what are the steps that they think are realistic to take and complete that task and achieve that goal? But then lastly on that user side, kind of from a third party point of view is the user's actual experience level. Is this somebody who's technologically savvy? Do they use apps? Do they have a lot of experience on the web? How do we need to target based on what they're capable of doing? Secondly, we have content alignment or context alignment. This is a pretty fun one because at our core, these are realists. We don't like surprises. We like clear road maps. We don't like speed bumps. We like everything to go really smoothly. So like I mentioned earlier, we look at things from a business goal perspective. What's the ROI on something? How are we going to improve a brand even though that's kind of an intangible? Funding, that's a big one because as IAs we do user research. So we need to know upfront how much money is there because if there's not a lot of cash or a lot of funding behind a project, we're not gonna plan a whole lot of user research for the basis for our strategy and recommendations. Politics are always an exciting one. Going back to that Fortune 500 and working at the corporate level, you have to be able to navigate those and to know what's a hot button for somebody. As silly as it may seem, somebody may not like a specific word for a product or they may have an internal culture there that's referred to a process or a product the same way for a very, very long time and you might not be able to change that. And that's okay because you have to pick the hills that you're gonna die on. Technology is a big one because what I deal with a lot is structure. So somebody mentioned skeleton was a really good term. With how we implement our recommendations affects the systems that they're run within. So technology is a huge component of a successful IA strategy because if we can do the research and make the recommendations but if nobody can implement it, it's a waste of money. We go back to number one, business goals and funding. Resources, who's there to do the work? IA is really interesting because it's user focused and it's user centric. So if I started an IA project right now, most of the work is on y'all and I like that. But I have to interpret the data then. I have to coordinate all the interviews with you. I have to run tests with each and every one of you and that's a lot of idle time in my schedule. So we have to look at realistically who's gonna actually execute and who's gonna be the one responsible for making these recommendations. And then constraints, as I mentioned these can come from business goals, these can come from funding, these can come from politics but at our core we're realists so we like to know what we can't deal with. And then lastly in the alignment space is content. We look at audits quite a bit as IAs so we can establish a benchmark for how to move forward on a project. You know, one of the best things when you're trying to figure out how to architect and experience a website or a product, look what you've already got. The work's already gone into that. Hopefully you have Google Analytics or some other tracking metric on there to evaluate what's already in place. But we also look at the types of content WordPress is a great system that supports this when we look at custom post types. You know, when we build products at Firefly we very rarely use pages and posts by default. We are custom post types all the way because it allows us to create really intricate relationships between those different types of content. And then lastly the volume which we're gonna get to here in just a second when we talk about the structure of a website. We have to know how much there's gonna be. At the end of the day I don't care what's on somebody's bio page but I need to know that that bio page needs to exist if that's again from a cultural perspective or it's from a political perspective. Again, I don't care if the CEO has a page on the website or not. But if he wants one or she wants one by gosh it's gonna be there and I'm okay with that. So I really, it provides alignment in your products and your processes which can kind of get overlooked before we integrated it into our own process. There were a lot of moments of uncertainty as we would kind of go down the path of a project. One in particular I can remember was a software company and we got to the end of the project and all of a sudden we realized, there are 600 resources on this website that we missed. Crap. What do you do with that? How do you get to the end of a six month process? And you've got this great 200 page website and then all of a sudden, oh, that's only a quarter of it. We don't have designs. We don't have a structure in place for that stuff. We don't have fields in there to define relationships to get from point A to point B. What do you do? So for a long time without IA, this is how I felt going through projects. As you just sit there and just kind of wonder where are we gonna end up? I mean, we're planning as best we can and I hope it ends up all right, but who knows? So looking at what IA is and the alignment that it can bring to a project or process, let's look at some best practices that come out of IA. The two big things that I'm concerned with as an information architect is the structure of a website and the scheme of a website. First we're gonna talk about structures. Now this may seem elementary. A lot of things in IA are very like, John, duh, we can't help it when you know the context of them, you can really use them. So a structure is an organization to how you define the relationships between pieces of content. Couldn't be simpler, but that's a major component of how you build things. At Firefly, when we talk about products and websites, we have to talk in metaphors because nobody outside of the space understands what we do. So we always talk about building a house, building a website is like building a house. So when we talk about structures, we begin to talk about what are the dimensions of that house? How wide is it? When we go back to the realist part, we can talk about, well, you can't build a site that's wider than your piece of land or deeper. So we can talk about constraints and the reality of it. I'm not concerned at this point of you want six bedrooms or three bathrooms. I just need to know how big that house is. How wide can it be? How deep can it be? How many floors is it going to have? Is there going to be a basement? The structural elements are what I'm concerned with. So when we look at structures, there are two major types. The first is hierarchical. Now we deal with this in WordPress all the time. Pages and taxonomies by default have a hierarchy. These are great because they're top-down and they're search engine-friendly because it allows there to actually be a hierarchy for the URLs and for the content. There are drawbacks to these though. You can go too deep and too narrow when you're building a structure and all of a sudden your users find themselves in a rabbit hole that they can't get out of. We have a client that we work with. When we started with them, their website was 40-some thousand assets and 17 levels deep. 17! Okay. Exactly, so there's another talk about maintaining and editing a website on the regular. Let's tie that one into this. Talk about scope creep. How do you go from 17 to something that ideally should be one, two, or three levels deep? That's kind of a crapshoot. We didn't really know because again, organizationally that was going to be a really painful conversation. Taking this much content and putting it into a smaller space because we knew product owners were going to get mad. We knew sales was going to get mad. We knew marketing was going to be concerned that their products weren't going to be portrayed in the best light and then that's going to affect the brand. There were all of these hooks that were affected by this conversation. So we went to the data because that was really the only objective place that we had to go. And we looked at where are people landing on this website? If they're coming in from Google, are they getting straight to the page they want and then bouncing and going somewhere else? Are they hitting a category of product for example and then diving down into a product? Are they coming to the homepage and then bouncing from the homepage? Or are they actually following some sort of path from the homepage to get to where they wanted to go? Those are all the sorts of things that we looked for within the analytics. And at the end of the day we figured out five was a pretty good average for these folks. It was painful to go from 17 to five. It was a long, long painful process. In fact, our client abandoned their audit in the middle of it and just said, just finish it. We're still kind of feeling the ramifications of that one. But that's neither here nor there. So at the end of the day we had to figure out how do you reduce something again that was really narrow but also very deep and get it into something that was more balanced. And that's ultimately the challenge of a hierarchical relationship. They're kind of the default for everything which is great because everybody's really familiar with them but when you don't maintain them they get out of hand. Now, Etsy's a really good example of this. Their structure follows their navigation pretty closely in that you can find a home and living page. You can find a home decor page. You can find a wall decor page. Now it's really interesting once you get to the product level of what happens to the URL and we'll talk about that here in a little bit. But I always like Etsy as a stand out there. An example of what not to do. I wanna repaint my house right now. I like Benjamin Moore paint so I went to their website to try to find colors. I like historic colors and they have historic American color collections. Great. I also like gray. You know what I can't do? I can't find historic colors and gray paint. I get this. Now I have a design background so I somewhat know the source of these colors and can kind of figure things out between a warm gray and a cool gray and a neutral gray. I don't wanna do that. That's not my job as a consumer. They're a paint store. Show me the paint. Show me the paint that I want. So this is one of those instances where you can find yourself so deep in a rabbit hole and as an end user I get frustrated by that because they've gone narrow and they've gone deep and I don't have a way to get out now. So shame on you Benjamin Moore. So on the flip side from the hierarchy is we have the database model. So again in WordPress we're all used to this because we use posts and we use tags. So everything's flat, which is great because it kind of gives priority to everything. You know the bad side of that is there's that great old design phrase when everything is bold, nothing is. So it's a bottom up organization and it relies on metadata. Now I know there have been a lot of talks about search engine optimization. I'm not talking about SEO metadata. I'm talking about actual metadata. So data about data. When we look at this kind of a presentation we're typically talking about things like e-commerce sites and products, resource catalogs. Think of all the supporting documentation for like your dishwasher for example when you go to find a part number or instructional manual or whatnot with that. So we're thinking about things data wise like colors, sizes, brands, part numbers, series, not title, description, keyword, open graph, things like that. The cool part about a database model which is what Benjamin Moore would really benefit from is that you're able to repivot as a user. So if I'm on GE's website looking for a part number for my dishwasher, I can drill down to a certain point and I can go, that's not actually the part that I need and I can go back up one level. Database model lets us do that. We all, I presume, use Amazon. Amazon's a great example of this. Etsy does this too in their URLs. Once you get to that product, you don't have a hierarchy anymore. It's .com slash product slug. It's right up front. There are deeper talks about SEO that I won't get into today about authority within a website and where does your content rank relative to everything else, yada, yada, yada. But at the end of the day, the big advantage of this is this is top-level content on your website and that's really the shining star and the shining moment of the database model. And again, you're able to introduce things through metadata like prime, colors, sizes, ratings that allow you to filter and repivot your experience. One of the great things about the hierarchical model and the database model, even though they're totally different, is they complement each other really well. If you've ever shopped for a TV, you've probably gone to like a Best Buy website, for example, and you go down, you go electronics, home and entertainment, TVs, probably Sony or another brand at that point or possibly technology is at LCD, LED, whatever. They do a great job because once you get to that point, they switch it up. So your journey has been hierarchical but once you get to that final view, they go, oh, you think you know what you probably want but I wanna show you something else because I either have a better price or a better product or I'm gonna make more money if you buy something else. So instead of just showing you Sony TVs at the end of that click path, they're gonna show you Sony TVs but in that sidebar, they're also gonna say, would you like to look at Samsung? How about an LG? And they're gonna try to redirect you that way. So that's how you can use these things and pin them to make a really robust experience. Now, the other side of the coin other than a structure is a scheme. So you know, when we go back to the house analogy, at this point, we know roughly the size of the house. We know how many floors are gonna be there. We know if it has a basement. Now it's time to answer the fun questions of how many bedrooms does it have? What about the bathrooms? Is there an open concept kitchen? These are the things that we begin to think about and consider as we build out our schemes. Now, schemes for the technical definition, how you are going to categorize your content and the various ways you'll create relationships between each piece, pretty standard. There are a few different types. There's ambiguous, which is as generic as it gets. They're really subjective, which means they're really, really easy for folks who aren't in the space to design. They're hard for us as IAs to design because all we think about is, what if I call this thing? A random word that I know, but what if you don't know what that word means? And then what if it means something else to you and something else to you? That creates confusion. So for IAs, these are terrible for us, but they're often the primary scheme of a website. When we look at ambiguous schemes, Starbucks is one of my favorite examples. So let's look at their primary navigation. Okay, coffee. Safe to say that we know what's under coffee. Tea, self-explanatory. Menu, all right. What about coffee house? What do y'all think's in that? Locations, what else? Interesting. Okay, events, community. Anything else that you think may be under that coffee house menu? In-store services, okay. Products, music. Oh, y'all are a much more informed audience than normal. So my gut response to coffee house is a store locator. That's what I think would be there. But when you open it up, you get information about Wi-Fi, because naturally that's the first thing you think of. Starbucks mobile, you're already there, so why do you need the app? And then you get into community. Then you get into store design, which really is that the top of what we need to learn on the Starbucks website. And my favorite is how they just give up at this point. They just don't even know what else to talk about. So we get a great generic link. Learn more, more and more about what. About coffee house, because I still don't know what it is. My Starbucks idea, my Starbucks idea is a better menu. Not to be confused with the other menu. Coffee house facts, great is the first one. What is it? Store locator, finally. And then my favorite, looking for something else. Tivana shaken iced tea infusions. It is the junk drawer navigation. It's exactly it. Now I'm sure that there is an IA or a content strategist or a digital manager at Starbucks and this made a hundred percent sense to them. I'm gonna freak and clue what it means. Still don't get it. You can't have enough coffee. Exactly, not enough coffee. There you go. It was already there. I didn't have the political prowess to be able to change it. Yeah, so that's always a favorite example. But y'all knew that one more than most folks. So props to y'all. So that's topic. So topic is ambiguous. It can mean a number of things. It's like when you put about us or contact. You have to slap some kind of a label on there and for the most part, we all know what those mean. But the waters can get muddied. The second type of ambiguous scheme is task. Now we saw this a lot when apps kind of came into power because everything in an app is a task. Create an account, sign in, log out, share, et cetera, et cetera. As the web became more appish, this kind of bled over into the space. Again, Etsy has great IA, so I like to cite them a lot. And in their top right corner, they have a task scheme. They've got Selen, Etsy, Register, login and cart. Now the thing about tasks is you have to be really, really clear with them. There can be no ambiguity here. You can't be funny. You can't be humorous just for humorous sake. You can't get creative. You need to be really explicit with people with what they're about to do. Because the challenging part about a task scheme is you're not just asking somebody to look at a link and decide is that the content I want. There's a little bit of mental buy in there. There's a difference between me saying, I'd like to look at home and living products versus I want to sell on Etsy. There's a tiny bit of commitment there. So it's harder for us mentally to process. And as a result of that, when you're doing something like a task-based scheme, we like to limit it to fourth the most. If you go beyond that, it gets really overwhelming. Now if you've ever been in an app, you expand the menu, just vomit of links. It's overwhelming. For the most part, we can navigate those when those are soft terms like menu, coffee, house, coffee or tea. But when it's sign in, create and count, reset your password, lost your password, can't remember your username, yadda yadda. That's exhausting to us mentally. So limit it to four. And then lastly is audience. This is always a fun one that we see on higher ed websites. This is normally limited to three or four on higher ed, but Virginia Tech takes it a little bit further and I really like it. They've got the standard of prospective students, graduate students, alumni, parents and families, faculty and staff. Their interesting addition is business and industry. So that's, it's an interesting way because when you think about it, if you're looking for content on a website that's specific to a subgroup of people, if I'm, say when I was looking for my graduate degree, I was looking for clearly prospective student information. That's the keyword that I'm gonna look for. Now I know if I don't see prospective students, I can look for something like current students. I can look for something like alumni because it's safe to say that those are always bundled together. So again, try not to muddy an audience with a task, with a topic. Try to keep really clear lines because that helps folks learn how to find your content on your website better. Now on the opposite end of the spectrum, we had ambiguous schemes which are generic. They're hard to design from an IA perspective. Then we have exact schemes. I love these because they're objective. There's no room for error. Well, there's a lot of room for error depending on who's implementing it. But in theory, there's no room for error. Developers love these because they're logical. I love to code them because they make sense. It's not a manual selection. It's sortable. I like that. These are ideal for supporting navigation. So if we think back to the Starbucks example, if we went under the coffee menu, it's safe to assume that they're either going to display all of their coffee products or product categories related to coffee. In either scenario, I can bet that that list is gonna be alphabetized because we're all looking for something specific as we browse through. If I'm looking for the details on the new blonde roast, I'm gonna be looking for bees. That's just the way that we're trained to think because we like to get more narrow as we navigate a product. So some of the examples on how you can implement an exact scheme are alphanumeric, chronological, and geological. Now back to the coffee and tea example, there's this website, Steepster, that sells tea, I bought from it a few times. Their tea organization is interesting. You can sort it alphabetically by tea name, by company, you can sort it by popularity, what's trending, what's new, all these great different things. But when you look at popularity, sorry, when you look at the highest rated, it gets interesting. So how would y'all looking at just that top row presume that these teas are being sorted? What quantified popularity for me? Or highest rated? So out of 100. So we're going off of the numbers in the green boxes. Okay. I think that's a safe first dimension. Now let's look at the groups within each number that are in the green boxes. So let's look at the 91s and the 90s. How are they organized after that? There you go. So that would be my assumption, is it tasting notes are the way that it would go? So when we look at the 91s, the first one has 90 tasting notes and the next one has nine. Great, that supports our hypothesis. When you get to the 90s, the first one has 18 tasting notes and the second one has 20. So who knows how these are organized? As an IA, that's a small detail that I pay attention to though. And I immediately distrust how they're ranking these teas. So from a developer standpoint though, when I have to implement something like this, I have to be really careful not to be lazy. So things like this don't happen because it's easy to say, oh, here's a popularity scale. Great, spit it out, move on. But what does it mean? If it's not consistent, what does it mean? Chronological is the next exact scheme. We see these every day on news sites and on blogs. There's nothing fantastic or revolutionary to share with you about these. Just be consistent when you order things by date. If you're gonna group them by weeks, group them by weeks, you're gonna group them by years, do it by years. Just keep a consistent path. And the last one is geographical. This is really interesting with the rise of e-commerce. The reason I chose Wegmans as an example is the closest Wegmans to me is an hour and a half away. So I searched for one and I got the entire Eastern Seaboard. I like Wegmans, not going to Ohio for it, not going to Georgia for it, not happening. So you have to be really careful with geographical because while that's great and it shows me what's closest to me, you have to have some kind of a scope on it or some kind of guardrail because again, when it just spits out everything at you, it becomes meaningless. It's just white noise at that point. Yeah, exactly. We're on a road trip to Wegmans. We have in our area where we are, we have a local dairy that's kind of going east coast. They're from New York to lower Georgia right now. We're just kind of cool to see but they also have a locator on their website. So this was an issue that we ran into because how do you balance the spread of what stores show where their products are when you've got such a large area to cover? There are a couple of different ways that you can approach it when you're dealing with a geographical scheme. The easiest and my preference, ask the user what the distance is. It's an easy solution. How far do you wanna search? This can be distance. You can have a dropdown for states if they're interested. If you're at the state level, if it's not quite all over, you know, you can do regional. So that's number one. But then the other one, again going back to the reality of IA's is knowing the politics of business because they sell to many different competing grocery stores. So our big grocery store in our area is Kroger, for example. We couldn't have their product locator just show Kroger results because just outside of the Kroger area is Kroger's competition. So we had to actually expand and kind of go beyond the traditional like 10 results per page. So we could actually show a mix of retailers within their results because that was gonna be a business issue for them. So small things like that that you have to consider when you do something like a geographical scheme. Now search, I mentioned this earlier, you know, when folks search a site, now I don't specifically mean when they type something into the search bar, but rather when they're actually looking for something. So there are four main different types of search that you need to consider when you're talking about IA on a project. You've got known item searching, which is also known as focalized searching. So when I know I want a black shirt, this is how I'm gonna go find that. There's a really interesting concept in psychology called the scent of information. And they actually call us inform of oars, which I kind of enjoy now. But it talks about how cognitively we hunt for information online just like we would forage for food. We kind of like sniff out little nuggets of information to lead us to where we want to be. It's really interesting, way too deep for this talk, but definitely look it up. It really, really fun to read about. Then you have exploratory searching. You know, when you go back to the shirt example, that's at a higher level. It's no longer I want a black shirt. I want a shirt. I don't know. I don't know what shirt I want. You just know I need one. Then you have exhaustive searching. I want to see everything. I want to see every shirt that you sell. I have no quantifiers at this point, not color, not size, not brand, not anything. And then you have the refinders. They were the folks at Bookmark. One of the folks on our team refuses to buy a shirt unless it's on clearance. His Bookmark list for shirts that he wants to buy is impressive, at least. So he's that person that goes back every single day. Just like, you are skewing their Google analytics so much. You are hitting their website for like two seconds and bouncing, stop it. Or actually do it more and then we can sell them our services, but then stop it. And then you have labeling. Again, when we talked about like ambiguous schemes, this is where you can really get into muddy waters because what means something to one person may mean something else to someone different. You have to have empathy for your users. Again, because there may be a misunderstanding there. And you know, be descriptive and don't be clever for the sake of being clever. Still gonna hold on to Coffee House for quite a while as my example of like, hmm, not the best label. When you look at labels, you have things like contextual lengths, heading, navigation system choices, index terms, iconographic lengths. It's a bunch of jargon descriptors at the end of the day. Chase is a, now I hate it visually. I'll just say that upfront. I don't like it visually, but structurally from an IA standpoint, Chase does a really good job in their footer with their products index. They talk about very clearly with an introductory heading, what it is that they offer in this section. They offer you icons with a heading that goes with them so you can begin to learn the visual system. There was a talk earlier today about accessibility. Icons are one of the biggest pains in the butts that we run into when it comes to accessibility, because you have to make sure that there's alt text. You have to make sure that there's a certain naming convention behind it. If you're using something like an SVG, it's more code based in nature. But one of the ways that Chase gets around it is within their actual code structure, they're linking together that image with the descriptor that's right below it. So when something like a screen reader comes through and they see the icon for checking account, they know those are connected. So that's a really nice, again, not the best visual example, but a really nice example of how folks can use labels in a different combination of ways to really express something clearly. So we talked a lot about how we got here, what do we do? Most importantly, what do you do when you get stuck? There's a lot in IA, so how do you move forward? When you do have to deal with just not knowing what the next step is. There's really two big methods in IA. If you're stuck initially when you're trying to generate an architecture, or if you've got an architecture and you're not sure if it's very good, AKA when you go from 17 levels to five. So the first one that we're gonna look at is when you need to generate something to move forward. It's called a card sort. You can do this digitally, you can do this with index cards and go analog. Done it both ways, works fine. This is when you have no idea what your structure is. You have all your content, you have a list of your pages or assets or whatever they need to be. But you have no idea how to organize them and that's okay, because at the end of the day it's the users who need to tell you how to organize this information. There's a great article that goes into the deep, deep details of card sorting at usabilitygeek.com that y'all should definitely check out. But I wanna show you three different types of card sorting today. Open, closed, and a hybrid approach. This is screenshots in this section are from a platform called Optimal Workshop. It's what I use, there are a lot out there. Look around for ones that you may be interested in price-wise or functionality-wise. But by no means an exhaustive moment for the software. But this is what an open card sort looks like. You've got all of your content and resources over here in the left column. This was from actually a crawl of WordCamp DC's website. And what you do is you ask somebody to organize things into buckets, but not just organize them, but also label them, which is the really important part of the open sort. So not only do you get a structure out of it, but you start to work on labeling so you can avoid the ambiguity of, ooh, what's the song called? Now, if you're working with somebody, say that big corporation, who's a little bit more stringent on what things are called, you can do a closed sort instead, which is where you define the bucket yourself upfront and you go ahead and label them, and then you ask folks to put all the content into those buckets. And then lastly, you can do a hybrid approach to where you can define some buckets, but still leave it open to interpretation if somebody's not quite sure where something might fit. This is my favorite approach because it allows your end client or the person that you're working with to have some sense of control, but also allows the users to be expressive to say, ooh, what I think goes in that bucket doesn't match up with what the client thinks, which is the great part of IA because it's not about what I think, it's about what your customers think. So it's a lot harder to fight with me about that. So at the end of a card sort, if you're doing it digitally, you get something like this. If you're doing it analog, when you have card A and card B kind of in the same bucket, you give them a point in this matrix. And what you end up with is what we call an affinity scale. So this example was, it was for a generic, like for a sure website, but the one that's in the top left ended up with a rank of 92. And that was the combination of a contact phone number and an email address to get help. Again, it's not rocket science. I think we would all assume that those two types of information would get together, but it sure is nice to have that data when somebody wants to fight with you later on about it. And then the flip side of that is tree testing. So if you already have a structure in place and you need to figure out, can people actually use this? You can do a tree test. So this is the reverse of a card sort that's focused on findability within a structure. You use task-based scenarios for these. So remember when we go back to the context of a user, a user has a goal, I wanna buy a shirt, but then a user has a task, I wanna find a black shirt. So in this example, you've already bought your ticket, but aren't sure where to stay. What's your next step? It presents the entire structure that you've already created and it asks users to go through and find what page or what module they think they're gonna find the content they need. When you get through with a tree test, you can get really fancy graphics like this, which are cool to look at, not that useful and really hard to explain. Exactly. So the more simplistic view is something like this. So if somebody is looking for where to stay on that task, we can look and we can go, okay, 43% of people overall succeeded with that task. That's all right. But of those 43, an overwhelming majority of those, 29 as opposed to 17, found it on the first try. They didn't have to backtrack. So that's really interesting. And of the people who failed, well, they failed hard. The people who went directly to where they thought the content would be is almost four times the number of people who guessed around within that structure to figure out where they wanted to go. So this is a quick, easy way just to be able to say, yes, the structure that I've come up with works, or no, there's a big gap here that we need to fill. Now, I've thrown a lot at you today. So I've got it, it was a TLDR, but one of the folks that I worked with suggested since this is how to win an information architecture, I changed it to TLDW instead. So here to summarize is information architecture is the art and science of shaping information products and experiences to support usability and findability. Products are built on structures that can be hierarchical, polyhierarchical, flat, or a combination. Just don't use one inside of the other. Content inside of the structure can be organized via schemes that are ambiguous or exact. When you use one, try to use the other one to complement it. So go from generic to more specific. And when in doubt, test. Card sorting helps you define the structure itself while tree testing evaluates its navigability. Now, all that being said, and I know it's the end of the day, so I hesitate to ask this question, but are there any questions? Three in the front row already, one in the third. All right, start. So three slides back, I think it was? Uh-huh. There. Oh, it depends, I hate to say that, but it depends. I personally, I like to see a success rate of at least 75% on a task to really consider it successful. You can go the 66 route just to say, oh yeah, the majority of folks did it, but I like a strong commitment there. There's always room for improvement. And if you get something like a hundred, look at your task, because it's probably not right if it's that easy. To go with that, the fails. You sure? So what if you have a task that fails? So the thing that makes me think of, say you have a task overall that's really successful, but your failures maybe has a high rate of direct failure, but a low rate of indirect failure. That tells me that what you need is something more polyhierarchical to where content lives in one spot, but it's linked to from another spot. Whereas if you have still a high success rate, but a high indirect failure rate, people clearly cannot find what they're looking for. So that's something where you either need to reevaluate the task or the content itself. Where I'm going and then it's wrong. Correct. If it was a hundred percent success, but there's something wrong in the test. I think so. What do you normally see as far as, if it's higher than 95%, it's probably wrong? 90's normally that threshold for me. Anything that is grossly low, so 10 and below 90 and up, I try to throw out because they're just outliers within the overall kind of answer set. And I don't want those to skew how this goes. And I also never want to give the expectation that what we have done and what is perfect. Both selfishly from a business perspective because I want to resell them later, but also it's just not real. Interesting. This is a piece of software that you're using. And you're sharing it with potential users or you're selling it to them. So how do you get that from when you just have a group of people that you work with on a normal basis? Absolutely. So there are a couple of different ways you can go about it. If you're on low budget, Facebook should friend. Get the links and send it out to everybody you know and include some qualifiers in there like age, income, gender, other things that you might want to be able to filter on to get a more realistic sample within the larger population. If you've got a little bit more funding behind you and you're on a platform like Optimal Workshop, they have users that are pre-vetted that you can order for a couple of bucks per test. So that's pretty reasonable. Or if you've got a lot of money and you really, really, really need to match a customer demographic, you can go to a research house and actually buy a list that matches something specifically. So you always use custom post types? Oh gosh, well for the custom post types versus categorization, I look at post types as, say we're working on a legal website and we've got buckets like services, industries and people. At the end of the day, I know that each of those entities are gonna want their own respective pages on the website. And I find that really hard to manage through something like a taxonomy. So I actually will create post types and then use those, this is gonna get really advanced for a second so I apologize. And I actually use the post types as like kind of a faux taxonomy. So when I'm on an entry for a person for example, I have a list of all of my services from the post types and I have a list of all of my industries from the post types. So I can really quickly say, John Doe works in industrial and he also does audits just really quickly. The other thing that I like about that is I find optimizing custom post types for search much, much easier than optimizing taxonomy terms. Any other questions? Yes, about scheming and schemes. Yes. The most common thing that you see is like, how medical except what you've got featured stuff up there that we wanna provide at you first. And that seems to be the most common, more common thing in this story. I would consider that one, gosh, where you got something that's like a sticky or a featured. I'd say overall that's still gonna be an exact because it's 99% of the content on that page is gonna be ordered by something other than that one. So I wouldn't let that one dictate the rest. Oops. There we go. To me it makes more sense to everybody if the front end navigation matches that backend abstract, the abstract hierarchy when the page starts will be possible just so that when I'm editing the backend it doesn't look different usually from the front end. But I guess, can you talk about that a little? I mean, is it important to have the abstract, I mean it's such an abstract concept and in some ways you don't have to have any of it at all. You don't, it should look like given you can have it. Absolutely. So if you'd asked me this question a couple of years ago I would have said navigation and structure are one of the same and they should marry each other exactly. I've learned over time that that can be incredibly tedious to do and it's not something that we talk to our clients about anymore. We actually specifically say that the structure of your website is not the navigation because not always are those top level items something that you want folks to be able to go to. You know, if we go back to like the legal services website as an example I don't necessarily need a page that shows every industry that that firm works on. If I can do that with a menu instead. So structurally those pages are much higher in the overall hierarchy, which is great for search. But we're not cluttering anything up with a generic page that ultimately is just links to deeper content. So that's kind of how we approach that. So it's not always a one to one. Mm-hmm. The structure of your website. Exactly. Mm-hmm. Yep. Exactly. Mm-hmm. The university is in there. Mm-hmm. The parents might also want to do as well. So you've got a single piece of structure that's used in the website that you're going to do. Yeah, exactly. Yeah, then you don't have to worry about canonicalization, which is very nice. That's a great point. Mm-hmm. Anybody else? I know it's the end of the long day. All right, the last thing, I promised. So sorry to everybody who left. Give away. Who can be the first person to tell me what is something you're going to do as a result of what you've learned today? You, sir, get what is considered to be the good book of information architecture that has a lot of great insights in there and is a good read. Mm-hmm. It's the polar bear book. Well, y'all, if nobody else has any other questions, I've enjoyed y'all today. If you want to copy of the slides, I'm sure they'll be on the WordCamp site, but they're also at Firefly site, at firefly.agency.wc. Raleigh, so thanks. IA standpoint.