You know how it feels like when you do not find something on a website? In the library? In your room? Well, it is all due to infirmation architecture!
We cover this topic in this episode. This episode is part of a 3-episode serie on information architecture, taken from my masterclass that I gave recently.
More specifically, we will cover:
You know how it feels like when you do not find something on a website? In the library? In your room? Well, it is all due to infirmation architecture!
We cover this topic in this episode. This episode is part of a 3-episode serie on information architecture, taken from my masterclass that I gave recently.
More specifically, we will cover:
Jeremy here and I'm happy to be back. It's been quite a while, actually, but I've been taking some time for myself and I've been thinking about next episodes that I can bring the community, my listeners, regarding UX, research, and actually it'll be more frequent from now on. I cannot commit yet to a schedule, but it'll be more frequent. And today we'll begin with a topic that I particularly like, which is information architecture. So I'm giving this topic in this episode, talking about this topic as part of kind of preparation for my masterclass upcoming masterclass on information architecture, and also because I want my listeners who cannot attend this masterclass to benefit from the content as well. So the masterclass itself will be available in the show notes. You will also be able to access it in my website, that I will also link in the show notes, and I will also embed the presentation as a summary of this whole masterclass. And so, regarding the episodes about information architecture, there will be several. I don't know yet if there will be three or four, but the idea is to divide the topic of information architecture into several subtopics that will help you to design an effective information architecture for your app or for your website. And so in this episode today we will see an introduction to information architecture and then, in following episodes, we will see research methods for information architecture, but also how to plan a research study for information architecture. So in this episode in particular, when I speak about introduction to information architecture, I mean a definition of IA, information architecture, why is this important, and some good and bad practices about information architecture. So let's jump right in. So let's begin with the definition.
Speaker 1:What is information architecture? It's the practice of organizing and labeling content to make sure it's logical and findable. So it's really about imagine you have a website and you have the content of your website. Let's say you have an e-commerce website and so you are selling t-shirts and trousers. Well, you will have several categories. You're selling for men, for women, for kids. You'll have several categories where people will be able to find your products. But then you can be confronted to the problem of how can I organize my content so that people will find it. Imagine you have a section sports. Should men look into the section men and then sport, or sport first and then men? So this is the idea of how can you tidy up, how can you organize the information that you have on a website, on an application Already.
Speaker 1:Not only we will see that information architecture is everywhere, so not only, but it's really the idea of how can you organize the content into something that makes sense for your users. And not only. It's not only about organizing, it's also about labeling giving labels to your categories and to your links, for instance, to your content. Because even if it's naturally organized, we could easily imagine that if your content is where it should be, but not named as it should be, your users or your customers will not find it. So it's really twofold it's about organizing it, placing it in the right place, but also giving it the right name, and so that is why I say oftentimes that information architecture is made of three main pieces of content, which are the content itself.
Speaker 1:So, for instance, you have any commerce websites. You're selling different types of products. Well, these are the products themselves. So the content. This is the first part. So you have to list it. You have to know what is the content first.
Speaker 1:So imagine you have a new learning platform. It can be all your topics, all your classes Sorry, all your classes, by the way, not the topics. The topics will be an encapsulating category maybe, so I'm getting a bit ahead the content. And then you have the nomenclature, so what is the name you are giving to this content and to the categories that encapsulate all the content? And finally we have the structure. So you have the content, you have the way the content is named, and then we have a structure, which is how is the content going to be displayed, going to be offered, proposed to the user? And how are pieces of content talking to each other? Basically, how are they relating one to another? So the content, the nomenclature and the structure. And so, just to remind you of the definition of information architecture, it's about organizing a labeling content to ensure it's logical and findable. So it's really the idea that you can organize something and you can label something, but in the end you can do it for yourself, but in the end, the overall goal of information architecture is to make it logical and findable for someone else, so it's really about serving the needs of other people. So we will see how we can do that in the next episode.
Speaker 1:But first of all, maybe, why is information architecture so important? Well, first of all, information architecture is present everywhere, absolutely everywhere, and so we are sometimes confronted with services, products, experiences, in which we know we can, we can know ourselves that there is no UX designer or product designer, researcher or product manager behind this, because we can feel that things are badly organized. But, for instance, imagine you go to the museum and you want to see a specific era of of Fossiles, so you will go into a specific aisle of this museum and you expect all the fossils to be to be there. So this is the first example. Or you can go to the supermarket and you want to buy some vegetables, so you will expect them to be, let's say, imagine, at the entrance of the supermarket, where usually vegetables and fruits are well, it depends on supermarket. But again, you will expect things to be organized. You will not expect to find a I don't know meat and and A fishes at the same place of fruits and vegetables, for instance. So, as an example, it might differ depending on your places, but it will greatly be Shaved by your Expectations, which in turn, are shaped by your experiences. So we are touching a bit on the idea of User research here and how information architecture should match users expectations.
Speaker 1:So here I began. I started a voluntarily by citing examples which are non digital, which are experiences, and and I did it voluntarily, because in general, in product design, new act design and UX research, we we tend to focus, naturally because this is More emerging, we tend to focus directly on digital experiences. But in the end, design is everywhere. So we can design experiences which are not digital by helping people Find the content they're looking for. But now if we, if we move to digital well, as as I already a Gave this example at the beginning, you can look for content on websites, of course, e-commerce website. Imagine you go to Wikipedia. You will also a look for some articles in some categories. Probably, if you go to your settings app into your smartphone, you will look for and Imagine you want to make the phone bigger for your whole phone. Maybe you will look into accessibility, because you assume that it should be there. So this is really everywhere, everywhere.
Speaker 1:Even you practice yourself information architecture every day, and so by knowing how it works, it can also help you improve your own life, because by, for instance, designing your home or your, your living spaces in a way that you will find things more easily, well, you are practicing information architecture. So Imagine you are organizing your clothes in a certain way. You are really making a differentiation Between summer clothes and winter clothes, as I don't know. I am giving this example because that's what I do. But imagine you're not and and everything is is all is all mixed up, you will naturally make more time, take more time To find your clothes. So this is exactly the same idea of organizing you put things in two boxes and and you can practice it every day by knowing how it works. Basically, and here the idea is that you can be your own user, you are your own user and you are your own designer, so you can practice it and have an idea. And so, as as you may have understood, a Information architecture is really at the basis of, of user experience.
Speaker 1:You don't need to have a design on top of Information architecture for it to exist, basically, but you need information architecture For the design and the experience to make sense for the user. Let me take an analogy here Information architecture could be like a skeleton. So if you look at a horse or if you look at a dog, you can assume they have different skeletons, but you're not seeing the skeletons right. So you can feel that the the skeletons are are impacting, in this case, the design, and by design I mean the overall shape and appearance of your the animal in question, but you're not seeing it. But this is at the basis. If the skeleton is not right or if the skeleton is not designed properly, you will feel it in the end in the overall experience. So it should really be Addressed at the very beginning, before even wire framing, when you're doing your designs, maybe even before Storyboarding. It's really about listing all the features of your, of your app, website content as service before going further into the design. But I'm getting again a bit ahead of myself and we will then talk about.
Speaker 1:Then talk about how you can design an information architecture that makes sense for your users, and so I encourage you really to get a grasp of how information architecture works and what it is, to make a list, basically, of what are examples of information architectures around you that you like on an everyday basis and other examples that you do not like, probably, and that you would like to improve Basically. That and so for you to. This exercise will help you to understand how, why, information architecture is so important. So let's take some examples.
Speaker 1:First of all, imagine you have an e-commerce website and your customers. Well, they are coming and they're not finding what they're looking for. So you're setting the products. It's not that the problem. You're not. You're setting a product that answers their needs, right, but the problem is they cannot find it. They cannot find the products because it's not sorted in a way that makes sense for them. Imagine you want to sell a swimsuit and you're putting them into men and women category and there is no I don't know, there is no a water sports category that would help them find it easily.
Speaker 1:And I'm giving really a quote, unquote, let's say dumb examples. It really should depend on the customer, on your product. We will see that, but it's really to make examples here. So if people cannot find, if customers cannot find your content, they will leave your website and they will go somewhere else where they can find the products they want to buy, to buy them. It's as simple as that. Also, if you're seeing that your customers are leaving your website, for instance, what you could be inclined to do would be increase on the marketing costs, because you might think, okay, they're leaving is maybe because we need a more aggressive marketing campaign to attract customers. Well, maybe it's not that.
Speaker 1:So by having an information architecture that is nicely designed for your customers, you can minimize customer dropout and also reduce marketing costs all at once. You can also, because this is linked to SEO ranking. You can also improve your SEO ranking by doing that. So I'm not a professional of that, but I know that it's possible, because the way you, where your website is, organized, will be linked, in the end, to how it is ranked SEO wise basically. So it would also improve that and your website's reputation, because, indirectly, your customers will maybe the word of mouth will include that aspect saying that, okay, I really like this website because when I want to look for something, it's really really easy to look for, and so my purchase lasts I don't know five minutes. So, of course, there are other aspects, but you can take that into account. Also and this is something that I really lived personally when I was a UX researcher in the past for other industries it can also help reduce costs of support.
Speaker 1:So, in general, nowadays, when you deliver a service through an app or a website, you have a help section, right, or support section, let's say so. You want to reach for support, you have a problem, you want to call them or you want to set a chat, and then your issue gets addressed, right. The thing is, nowadays, we are already directed a lot when we are doing this request. Why? Because, in the end, at support, you have employees who are given, in general, a scope of issues to answer, so they are more specialized, and so to help them achieve their job better and to be more efficient, as they will have a more narrow scope of action, the app or the website includes redirections in the form of a tree. So imagine you are calling your internet provider because you want to change your, your bill this happened to me recently and so it can be done in various ways in terms of design. I'm not speaking about design here, but you will have some redirections. You will have the first maybe option saying why are you contacting us? Is it because you want to buy a new cell phone? Or maybe you want to change your personal data, or maybe you want to change your bill, and so on and so on and so on. So you have several aspects and then, when you click on one, you have again other options and other options until you really get to reach an agent, or sometimes not. This is another topic for maybe another session, another episode, but really this is the idea that you are directed and redirected and redirected.
Speaker 1:What happens oftentimes is that these redirections are frustrating for the customer. They're frustrating for a lot of reasons which are not directly related to information architecture, but it can be because the waiting time is not transparent or I don't know what options will lead me to talk to an agent, for instance. So what I might want to do as a customer is know or think that by speaking to an agent my request will be handled more effectively. So, by trying several options, what I can do is a kind of a how can I say during the system, I can use the system in a way that is wrong, so that I know that I will talk to an agent, so I will choose the wrong options that I know through experience that will lead me to talk to an agent, and so this. My whole point with that is that this increases costs of support, because then you reach an agent okay, but it's for the wrong reason, and so the agent might not be able to handle your requests, and so the agent will take time, end up not solving your requests, so the customer is not happy. So increasing costs and so on, and time equals money as well. So all of that because maybe you will not transparent enough at the beginning on your capabilities of your support, but also because your information architecture is badly designed, because you're not labeling, for instance, that's here you will speak to an agent, or because the options are not nicely laid out, or because your customer has to click three, four times before, in the end, reaching an agent, and that is very frustrating. My whole point is by redesigning an information architecture, you can also decrease costs of support, and this is really not to be ignored. And also another example that really interests me it's about employee productivity. So imagine you're a UX researcher, you're a UX designer, our product manager.
Speaker 1:Nowadays, to do our job, we really need, we really rely every day on documentation. We really need that. So, for instance, as a UX researcher, before beginning any project, I will look into past documentation. I will run some desk research, external, of course, to see what is done by competitors, what we know about human behavior regarding a specific, specific topic. But we'll also look into internal documentation. And, for instance, okay, we are, we want to improve this section of the app, let's say the support section of our app. Okay, why do we want to improve the support section of our app? So I will look into past documentation. What is the history of this support section of the app, what has been done in the past, what worked, what didn't?
Speaker 1:All of that is documentation. All of that. I need to be able to access that and how can I know where to go, what to look for, what are the labels I should look for and where should I look for? And all of that is information architecture, all of that. Of course, there is also another discipline which is linked, which is documentation, and this is a whole process and this is a whole discipline. So knowledge management. But once the knowledge management procedure is in place, there is also the, the, let's say, the front end for the user in this case the user being you, the UX researcher or the designer which needs to be taken into account, which is how can I nicely lay out, let's say, my tree or my information architecture so that my user in this case the UX researcher or designer access the information they need weekly, so that it decreases the productivity? So I hope, with all these examples, I could give you a taste of why information architecture is super important to address.
Speaker 1:First of all, as we said, because it's present everywhere and because it's the foundation of user experience. So in my opinion, it should be treated at the very beginning. Be for, even speaking about wireframing, prototyping, ui elements and so on, it's really about the content and how the content should be displayed. Everything will be easier after that. Now, okay, we know how to, how to, why information architecture is so important. But now you can ask how to represent information architecture. Well, in general, information architecture is represented through either what we call sitemaps, which are kind of diagrams, or documented into spreadsheets. But now you may ask how can I do it? And even let me easy for me to tell you you orally, but you will have access again to the documentation through the website. So what are sitemaps? Sitemaps are diagrams which lay out the information architecture of your website, and so probably you already came across some in the past.
Speaker 1:In general, it's like you have a first box at the top which represents your homepage, okay, and then you have kind of a tree cascading tree, and from the homepage you have branches I'm not sure if that's the English word, I'm sorry if not. So you have ramifications from this first category, which is the homepage, and you have as many as actually, as the user or customer will see in your app or website, because the homepage you don't need to to have something saying it's the homepage is directly the homepage. The user already sees it. But then you have several categories. So imagine you design a box saying homepage and then you have, let's say, two ramifications. You have an e-commerce website, very simple e-commerce website, and you have two ramifications, one saying men, one saying women, for instance, or you can have kids, or you can have whatever, but but then you have these ramifications from the first one and then imagine, in each category men, women, kids and so on you can have subdivisions again and again, so you can have sale. In each one of them you can have men sale, women sale, and so on and so on. And so this in the end will look like a tree.
Speaker 1:Basically, visually, when you represent it, it's like an inverted tree. So in general, trees go a bottom up right. You have the trunk and then you have the branches at the top and so on. But visually when you represent that, let's say in middle or any diagramming tool, it will more look like a cascade, let's say a waterfall, basically. So you have your trunk at the top and then you have the ramifications going until the bottom.
Speaker 1:So this is one way to represent information architecture through sitemaps. You have another way to represent it. Actually, I'm not saying one way is better than another. It depends on the goals of your company and it depends on, well, how best you want to communicate it. To be honest, in my opinion, I think it's best to do both ways. So the first way, the sitemap, as I told you, and then you have a second way, which is through spreadsheets, and so the first way is good for visually representing and the second way is more for a working document, if you want to edit things, if you want to edit labels, if you want to edit the architecture, and then, once it's finished, probably to communicate. The first, the sitemap, is better. And so how does that work in spreadsheets? So in a spreadsheet it will be the same as the sitemap, but turned 90 degrees.
Speaker 1:Okay, imagine so you can imagine the spreadsheet with the rows and the columns. So the idea is that the branches, the ramifications, the levels will be each one displayed in one different column, and so you have your first node, your first trunk, in the first column and it spreads across all rows. Basically, so you have the homepage at this step and then you have layer one, or, depending on where you want to begin, where you want to start your numbering system, you can already call it layer two, but it's like the first layer is in the second column, basically. And so here you will have all your categories Men, women, kids, whatever. Or imagine you're giving, you're having a new learning platform, a history, philosophy, mathematics and so on, okay, and then you move on to year three, so in each one of them you will have subdivisions. So imagine philosophy. Well, you will have courses, you will have exercises, further readings and so on, and so this is layer three. It should be, for instance, column number three. What is important here? And it's again difficult to tell orally, but you will be able to see the content on the website For each category that is in one layer, and then it spreads out.
Speaker 1:When it spreads out in the layer number three, the cell that is linked to that in layer number two, the previous layer should be spanning across all the rows in the ramification layer number three. So I hope you understood. If not, I will link some examples into the presentation. Okay, so we covered how to represent an information architecture through site maps or through spreadsheets. Let's wrap up with this last part of the episode, which is about how you can define an information architecture, and this will link perfectly with the next episode, which will be about user research. So I'm already spoiling you a bit. You know that user research will be super important, but anyways.
Speaker 1:So maybe, first for you to understand what is a good practice to define information architecture, let's talk about bad practices. So we can all think about bad information architecture practices around us, but I like to speak about three that I have in mind. If you want to train your eye and your let's say, your senses to buy information architecture, I encourage you again to list all of them, with the bad, with the good ones, and maybe it would be good if you could share them to me on the websites. So, examples of bad you AI practices, no, or in clear structure. So basically, you go on a website and you don't know where to go. You go on a website with the goal in mind and you don't know how you can accomplish that goal. You don't know how you can find something Because there is no consistency, there is no coherence in the structure. Nothing is is, nothing makes sense. So this is quite an extreme. Of course, I would say it's the one extreme, and then we will talk about another extreme, which is like the willingness of wanting to structure too much. But of course, if there is no structure, people will not be able to find what they're looking for and so, again, they might leave your website.
Speaker 1:The second one as I was saying from the beginning, we got in definition of information architecture. You remember it was really about the content, the structure, but also the nomenclature, the, the, the namings, the labels. Okay, so you can have a great structure, a great information architecture, but if your labels don't make sense, it will be the same, because for you, label X or label Y means something and is correctly put at this place, okay, but for your users maybe not, maybe it doesn't mean that. So it's really also important to have the labels right. And finally, I was I was saying at the beginning of this step of the episode that there is the one extreme, which is no ordinary, clear structure, and then there is the other extreme of wanting to classify too much and to organize too much, which would be here, buried or hard to find content.
Speaker 1:So imagine you want to categorize too much things. You may have things that are ending to be so hard to find and users will not will end up not finding it because it's it's so so clusters that we cannot find, and that is why one good practice, of course, on a website or on an app, is, of course, to aim making the interaction working well between the structure and the taxonomy, the categories and the search functionality. So it's good that your website has a search functionality. Okay, how can you avoid all of that? So you have a. You haven't a clear structure. Okay, you have a lack of consistency in labels and and or you want to bury your content because you think, okay, by categorizing a lot, I will be sure that it will be great, but in the end, it turns out not to be good. So you have all these problems.
Speaker 1:What can you do? Imagine? Well, first of all, as I was saying, the first step into designing an information architecture is to list the product content. It's super important to list what are the features of your product, what will it help your users, your customers, to do? So you have to list everything First of all, then also run a competitive audit, look into what the competition is doing and look into what are some good practices of organizing the content that they provide. And so, even without and I'm not advocating for this, but even without conducting UX research, you can already have a feeling of what could be good practice of organizing your content by looking at the competition, what they are doing and what works well, what doesn't work well. So that's already two steps, and they don't involve running UX research.
Speaker 1:But really, this is really really not enough. I would say that this would give you the very, very bare minimum. It's like if you don't do this, you are sure to fail, but if you do it, it doesn't ensure you will succeed. What will ensure you will succeed to help your customers and users to find your content is knowing their needs. You have to know what people need. So, first of all okay, you provide a list of features. You have to make sure, first of all this is not the topic of information architecture but you have to make sure the features are answering people's needs. Of course, but when you know they answer people's needs, you have also to know them. How do they structure content, how do they label the content, where do they expect to find the content and how do they navigate? All of that is the goal and is answered through user research basically, and this is the topic of the next episode.
Speaker 1:So thank you to all of you for listening to me. It's really a pleasure to do this episode. I'm really passionate about information architecture. I'm not an information architect, but I have a growing interest for it and so I really hope it helps some of you. If so, I would really love to hear from you some comments on my website. It was currently under construction. It will appear again and I will link it into the show notes. So some comments on the website. Also, you will access my content and yeah, basically that I was super happy to do this episode and stay tuned. If you like this episode, please give it a review, subscribe and share it with a friend. And again, thank you for listening and see you in the next episode. Bye-bye.