Design Better Intranets through User-Centered Design | Kathryn Whitenton of Nielsen Norman Group

I am really excited to be here and learning a little bit about the AEC industry and I'm also really excited to be able to share with you some perspectives from outside the industry. What I want to talk about today is the work that we do at Nielsen Norman Group. So Chris mentioned a little bit about us just a second ago, but. But I know there's probably some people here who are wondering are these the Nielsen rating people and we're not the television people. What we do is we are a research oriented firm. But the type of research we do is not just about what TV shows people like, it's about more broadly how people interact with technology and how that interaction could be improved. And the main way that we approach this is by watching people actually interact with systems and be that intranets, websites, applications, devices, we actually sit next to people and see what happens as they try to use something. And in the 20 years that we've been doing this, we've observed more than 10,000 different people interacting with different types of systems. And that's just our in person research. We also do lots of remote studies where we're not even including people in that total. And from what we learn in those observations, we develop recommendations and guidelines for how interactions could be improved and do a lot of teaching and writing to try to share that knowledge as widely as we can. Our area of research also includes a strong focus on intranets. And so this is something that we try to share because a lot of times it can be a little bit difficult to know what's going on with other intranets besides your own. You can only see your own companies. So we do quite a bit of research to try to collect and compile information to give people a sense of what are other people doing. So we publish a report every year with top intranets for that year. And we have another report, one that I co authored which looks specifically at information architecture on intranets. How are they organized and how does it work when you use certain organization schemes. This particular report that I'm referring to included information from 74 different organizations. This was across 19 different industries. So everything from manufacturing to a whole lot of knowledge work. Intranets like yourself, biotech, financial, government systems, wide variety, and we notice common patterns among all of these different types of systems. The top two, the data that I'm showing you right here, the top two problems, the most common problems with Internet information architecture that the teams that we talked with report are people being confused about multiple different categories that seem similar to them and people not understanding the terminology or the special language or acronyms or lingo that's being used to describe things. So I see a couple people nodding their heads. If you have these problems on your intranet, first of all, you're in very good company because a lot of people have these challenges on their intranet. So it's not you. It's kind of the nature of the beast. But the second thing I want to mention is that there are actually specific things you can do to try to minimize these problems and try to help overcome them. And that's what I want to focus on today. So to get around this problem, I first want to start by thinking about what do we do? How do we start this process of creating an intranet? Or if you're not working specifically on an intranet, if you're doing like an application that is a training delivery application, the same principles apply. Whatever type of system we're creating to try to engage people or share knowledge, we can start out by thinking about what does this system need to do? Maybe we have a list of features or a set of content that we know we want to give access to. So we come up with our list, we sit down and we come up with a beautiful plan that organizes everything. So that's one approach could be our starting point, but another approach that we could take is to say we're going to start by looking at the people who we expect to to use this system. The first thing we're gonna do is go and try to understand them and get inside their head and try to understand what do they expect and what do they need and what would make sense to them in this system that we're creating. So these are two different starting points. And the place that you start from will have a big effect on where you end up at the end of this process. If we start by creating a system, oftentimes what happens is we end up with a system that may be really wonderful, but people have to adapt and learn how to use that system. They have to fit their mindset into what we've created. If we start by looking at what people think and then make a system that matches that, then our end users don't have to do as much work and learning to try to understand the system. It's already a better fit for what their expectations are. So this process might look something like this. If we start just by creating a design and then building that design, this is kind of the default the way that we normally would think of how to do something. And if you've ever been involved in creating a software project that followed this path, you may have found that at the end, after that path was built, and it turned out that didn't quite work the way that you had hoped that it would, and you may have had to actually go back, and after something is built back to the drawing board and trying to correct and improve things that you hadn't realized were going to be issues. There's a military saying that no battle plan survives first contact with the enemy. The end users are not our enemy in this case. But the same principle applies that when something actually encounters the real world, there's always unexpected things that we didn't think of. So we can avoid this. We can change this narrative by essentially moving that first contact to be something that happens much earlier in the process. So before we create an elaborate design for what we're gonna do, we can add a step where we make contact with our end users and start to try to get inside their heads and understand what would make sense to them, what do they expect? And then we may move on to come up with a design that we think will meet those needs. But before we go and build that design, we add another step where we have direct contact between our design and our end users and start to see if it will work the way that we hope it will. And if we find something that doesn't work, we can then go back and adjust it. And at that point before it's actually been implemented, and it's much easier for us to change it, especially if it's a structural change, like a major difference in how things are going to be organized or grouped. We may still find at the end of that, after we go through and build something, that we discover things that require us to go back and make adjustments, they'll be smaller adjustments, they'll be easier for us to make at that point. So the processes I'm going to describe today are kind of getting into the nitty gritty of exactly how we do this. How do we get inside people's heads, and how do we find out whether a system will work or not before we actually build it? And these techniques collectively are aimed at really putting the end user at the center and the foundation of all of your decision making. And this seems like, of course, the whole point of this is to make something that will help our fellow employees and our colleagues. But it actually is something that can very easily get lost in the shuffle when you start a big project for software or digital solution. Oftentimes we have maybe a list of features or a deadline or a budget. Right. And all of these constraints are very difficult to ignore. And it's actually kind of easy for us to forget about the end users in this process. So user centered design is aimed at avoiding that problem by specifically making an effort to do activities that will force us to always think about the users and have that be the motivation for everything we do, not just because it fits in the technology platform that we have access to. Right. We should have something that is going to meet somebody's need and then figure out what technology will make it work. If we don't follow these practices, we can often end up with systems that are organized not according to what people would understand, who we want to use those systems, but according to maybe what makes sense to the people who produce the systems. And in the case of an intranet, that might be your content authors, the people who own various departments. So this is an example of one intranet organization scheme which was organized according to department. So they had a section for businesses that were part of the organization, and a section for client groups and a section for corporate services. And all of these are different little fiefdoms within the organization, and they each had their own little section. But this organization scheme requires that anyone who wants to find a piece of information knows exactly who owns that information. So this intranet that I'm showing you here went through a user centered design process. And at the end of that process, they changed their structure to organize it according to questions and tasks that the members of that organization needed to accomplish. So they had a section that explained the role of the organization, the mission, and their vision and values, which they wanted to make sure everyone was aware of. And then they had sections that were about operational guidance, what are their policies, how do you do your job, how do you carry out your work? And they had a section about working at that organization. What did you need as an employee in terms of managing your employment relationship and your vacation and all those types of things? Right. So people don't need to know, do I go to HR or do I go to my boss, or do I go to this other department to answer a certain question? They just need to know what their question is. So this is the example of what we're trying to get at when we organize things with user centered design is according to the perspective perspective of the person who actually needs the information. And all of this relies on kind of embracing a basic principle before you even start. And this is something that we've found to be true across pretty much every technology system we encounter in every type of design process, which is the fundamental idea that you are not the user. In your case, this is not literally true because you do work at this company, you will use the Internet or the tool that you create. So in that sense, you are a user. But what I'm referring to by this is you're not the user that you should be thinking about when you're deciding what would make sense and how should this be set up because you don't want to have it just be something that only makes sense to you. It should make sense to all the people who need to use this, and especially to the people who needed to use it the most. And if you're sitting in this room, chances are you're not very representative of those people. We have a wide variety of knowledge and perspectives. And the people who work directly in knowledge management or who create content for the intranet oftentimes have a lot more knowledge about the intranet than your average person at your company. You've seen behind the curtain. You know too much about the guts of that system to be representative of what would actually make sense to an ordinary person who hasn't had that exposure. If you're in a leadership role, you may have a vast amount of knowledge about the business and understand at a very deep level what's important and how it works. But you probably don't engage in the same day to day tasks as the average individual contributor at your organization. So it's very difficult for you to know what do they need in order to do their job, what do they already know, what questions do they have? If I have a junior level person working with accounts and she's trying to find information about past projects, what terminology is she going to know and what is she going to search for? What categories would make sense to her? That person has a very different background and perspective about the entire body of knowledge. So if we want to make something that's going to work for that individual contributor, we have to get information directly from them to understand what's inside their head, what is their point of view. And we can do this through a variety of methods. And I'm going to outline five different methods that we can use today when we speak with intranet teams, most of them use more than one of these methods, which is a really important point because each of these methods has its strengths and weaknesses. They'll give you a certain perspective on what's going on. But if we can combine information from multiple sources, we can be a lot more confident in our outcomes. So I'M going to describe what these are, and we're going to actually take part and do a little bit of exercise and interactivity to see how they actually work. So the first two that I want to mention are analytics and surveys. Analytics refers to the practice of setting up a tracking system to basically record every action that users take as they're interacting with the system. So if you have a current intranet or a current version of the tool you're creating, we can record what are people clicking on, what pages are they going to view? And by looking at that, we can start to get a sense of what are the most popular categories, what are the most frequent activities, and start to understand what people are doing and what matters to them. Surveys, on the other hand, don't tell us what what people did, but they tell us what people's opinions and preferences are. And we can ask them what's important to you and what are you struggling with? This is an example of a survey question from a team that I worked with in a survey that they issued before they embarked on a redesign of their intranet to ask people, what do you think? What would be the most beneficial to you for us to improve about this intranet? Where should we be investing our time and energy? And when they asked these questions, the most common response that they got back was not that people wanted a mobile version or that people wanted even more social features. It was simply the ease of finding information. People couldn't find things. And this is really valuable information to know because it tells us what we should be focusing on, is not just a new skin or a mobile app. It's on this kind of fundamental structural challenge. So analytics and surveys are really important sources of information, and they are also excellent because once you have an analytics tool set up, that information is very easy to access. It takes almost no time. You go log in and you can immediately start looking at that data and a survey. Likewise, you have to design the survey and send it out. But once you have the data back, you can start looking through it pretty quickly. So these can give us starting points and a direction that we should focus on. Surveys and analytics have some really important limitations, though. So analytics is going to tell us what people did, but it doesn't tell us whether it worked or not. We know maybe a lot of people went and viewed a particular page, but we don't know if that page actually solved their problem. We just know that they were there. Survey is going to tell us what people believe, but sometimes people don't know the whole story or they may describe a problem and they're describing what they see as the problem, but that's not actually what's going on. So imagine we did a survey and people reported what I'm looking for never shows up in search results. If we were to actually see what happened when they executed a search, it might be that the exact page they were looking for did appear. It was the very first search result, but they just didn't recognize the title, they didn't understand what they were looking at. So it's not necessarily a problem with the actual results that are returned. It's maybe a problem with how we're describing the content. And that's the kind of thing that a survey is not going to tell you the root cause of a problem. It may give you a starting point of what to investigate further, but it doesn't tell you how to fix it. For that, we need to look at a different method. So the method that I want to suggest for doing this is a technique that's one of the most common methods we use. It's called usability testing. So usability refers to how easy it is to actually use something to accomplish a task. And we can assess this by actually watching people try to use a system and seeing what happens. So this will help us get to that root cause issue of when somebody encounters a problem, what exactly is going on that causes that problem problem. We do a usability test. We start by listing what are the tasks that people need to do with the system. And then we would get our representative users, not myself, not my executives, but the actual individual contributor, the normal person who's going to be trying to do this and watch and see what happens when they try to do it. And then I also want to have those people explain to me and try to think out loud as they're doing it so that I can get some explanation of why they might be clicking on a certain button if I'm doing the test right there with them. I can also ask follow up questions. And this first item number one up here, listing tasks is really important because if you do a usability test, what you don't want to do is go sit next to someone and say, show me how you use the intranet. Because if you do that, what's likely going to happen is they're going to basically do like a demo and you're going to get similar to information to what you would get if you just sent them a survey. Well, they'll tell you what they like and what they don't like and what their opinions are and all of that is important information, but it doesn't tell you what's actually going on, what's really happening, what is their behavior as they try to interact with the system. So the way that we can get to that is by forcing people to actually use it while we observe. Usually it's time prohibitive. You can't just follow people around all day and wait until they happen to need to use the intranet. So we want to schedule a time with them and during that time we want to get them to actually use it. And the way we can do that is by giving them a task and say, do this. Answer this question, use this tool to do it. So an example of what I mean by a task, this is a task that I might use if I was testing an E commerce website. So say this is a website that sells shoes. I'm doing a usability test. I would have my user come in and I would say, hey, find a pair of shoes on this site that you might like to buy. So I'm going to play a short video clip of an actual usability test session for you so you can see what I'm talking about. So you're going to see this user, he's referring to written instructions which it's going to be teeny, teeny tiny print on the screen. But this is exactly the task that it says. And he'll be thinking out loud and telling us what he's doing as he tries to accomplish this task. And there are three different problems that he encounters as he's trying to do this task. So listen to everything that he's saying and see if you can identify what some of these challenges are. Okay, so let's see what happens for our shopper.

Okay, so we're here to test this site, eqtamsterdam.com let's open it, let's have a look at it first. All right, so we get a video like an animation. Alright, so find a pair of shoes on the site that you might like to buy. After you choose a pair, please say two reasons why you like them and how much these new shoes will cost. Okay, so I'm going to look through these shoes and this looks like quite a simple website. There's no navigation menu, no navigation bar. Okay, so if you hover over them, you get some information. Alright, I like these shoes actually they're the style that I like. They're black, I like black. And they're surrounded by white, white rubber. I really like that. So I may choose them. These are the kind of shoes that I like. The low one here, you get the info about the shoes. Okay. There's some pictures and you go down, you get some, some suggested, oh, oh, I went backwards. I don't know why. I didn't want to go backwards. I didn't click anything. Okay, so you get the info over here.

Okay, so what did we notice? I think a lot of people heard that last part at the end there. What are our three challenges that happened? That last one, he said it took me a change and I didn't click anything. I don't know why it took me back. Did you notice any other problems that this user encountered? He thinks the shoes are black, but they were blue. Right? So they had a little like nice little subtle blueberry name. And then even when he went to the real page, it described, described them as blue, but he completely didn't notice it. So if this user orders these shoes, he's in for a surprise when he opens the box. Assuming he's not really unable to tell the difference. It's just the photo on the website. Maybe in real life he won't be able to tell either. But he doesn't know the right color of the shoes. He's surprised by how the page moves around. Somehow he changed to a different page and he didn't expect that to happen. Anything else that you noticed? No navigation. So early in he didn't find the price. But early when he first arrived at the site, one of the things he said was this is a very simple website. There's no navigation menu and there is actually in the top left corner an icon indicating that there is a navigation that he could use to move around this site. But he didn't see that at all, which we know because he was thinking out loud and telling us if we were to just look at analytics, we would say, ok, this user went to this page and we don't know what he was thinking. And that he assumed he had no option but to look at this page. He didn't think there was a navigation menu. So usability testing gives us both his behavior of what he actually did and his reasoning and motivations for why he did those things. And this gives us a much richer understanding. And this is just like a 90 second little clip. We've already found three things that are potentially problems that we should improve about this design. This is a very rich and flexible method for helping us learn about and understand our users. And when we talk with intranet teams who do this, they report exactly that, that usability testing Helps address the issue I mentioned at the beginning of wanting to get inside somebody's head and understand how people think who have a different perspective from me at the organization. This was an Internet team that referred to thinking, getting people's perspectives from how they think at different levels. A few more quotes from intranet teams which you'll. If you want to read them in detail, you'll get in the slides later. But just to point out, this spans across financial firms, technology firms, government agencies. It's very effective. It's a very effective way to learn about people's points of view by having them actually explain what they do as they try to interact with something. This method is something which you can also use at a lot of different points in your process. So after something has been created, doing a usability test to see if it works the way that you expect it to is a good idea. But also while you're in the design process, this is the technique I would recommend doing as that test step in between designing and actually implementing something so you can find out about these problems before you've actually gone through the full implementation process. And it's also something that I would recommend doing before you even embark on a redesign process, to do a test of what system you have right now, which gives you two really important starting points. One is to understand what could be improved, what could. If we're thinking about changing to a new platform or a new system, what is it that's not working that we should change? And also you really wanna know what is working so that we don't break it when we change to the new platform. Just as important to make sure that we don't introduce new problems. This method can be done at various stages. And it's also something which is easy to do at various stages because you don't need to do it with a whole lot of people, just with that one person. In 90 seconds, we already started to see a lot of issues. And by the time you've seen a few different people, you start very quickly to see the same issues recurring. So oftentimes what happens in a usability test is we have our first person come in and maybe this circle represents all the problems that that person encounters. And then we have our next person come in and the second user sees some new problems, but they see some of the same problems. And by the time our third person comes in, we're starting to see similar things. Still a few new items, but a lot more similar. Our fourth and our fifth person have even more overlap. And by the Time we get to the person, the fifth person, oftentimes we have a pretty good list of things that could be better about this design. And so now you have a choice to make. And a lot of times people's big question with usability testing is, but that's only five people can I really trust if it's just that small of a number of people, don't I need to do more? And the question that I would pose to you to think about this is thinking about these, not just based on the number of people, but thinking of them as problems. And when you see somebody encounter a problem, how sure do you need to be that it's a problem before you fix it? So imagine if your household is anything like mine. I have two dogs in my household, and they love to play with toys. I would say obsession is a mild word for how they interact with toys. Similar to the spirit animals we saw yesterday where we had the kitten and the puppy that have toys all over the place. If I have a friend come over to my house and they trip over one of the many toys that are scattered around my living room, should I wait for five more friends to come over and 20 more people to trip on that toy? Or should I just put the toys away because I know that they're in a way, and it would be better and it would be less likely to have a problem if I just clean up. Right. So I don't need to ad nauseum prove beyond a reasonable doubt. We're not in a court of law. Right. We're just trying to improve a design and make it better. So once we see several people having a problem, if that problem makes sense, usually you can understand immediately once you see it why that would be a challenge. Our guy who's looking at the blue shoe, then he thinks it's black. You can see. Yeah, that's pretty dark. I could understand why somebody might assume that that shoe was actually black. Let's see what we could do to make that more clear. Sometimes what comes out in a usability test, quite often on an intranet, may be some of these information architecture issues that we mentioned that people don't understand where they should go to look for something. And this is oftentimes related to confusion about categories. And it's a really important problem because everything that we want to accomplish with a tool that we're building depends on people being able to find the right thing. Right? So if the gorilla in the pool spirit animal wins popular vote representing engagement. That gorilla is not going to have fun. Splashing around the pool unless he can actually find the pool in the first place. People have to get there before they can use it. We talk about this in a sales context. We say they can't buy it if they can't find it. And the same principle applies for knowledge and engagement. So what we can do to make people find things more easily is to provide what's described as information sent. And this is in information theory, the idea that when people are looking for something, their behavior is actually very similar to an animal following a trail, searching for something they need food or water. And so we want to lay down a very clear trail for people to follow that will lead them in the right direction and help them get where they need to be. And there are specific things that we can do that will provide a strong information sent, where if we fail to do these things, there's usually a weak information sent, and it's much harder for people to find things. So there's three that I want to point out in particular which have a big effect on information sent. One is when we use category labels that are extremely broad, it's very difficult for people to detect exactly what direction they should go in. So the example at the bottom here, on the far left is common services. This was a label that was actually used on an intranet. And when you see that label, common services, you probably have no idea what could be in there, because anything could be in there, right? Probably not a rare service. But who determines what's common? A lot of things could be considered common services. The other problem that impairs information sent is when we have multiple categories that, that are similar to each other, and then people have trouble determining which of those two should I click on. So if those categories are overlapping, if I have one category for human resources and another category called administration and management, there could be a lot of confusion between which one of those I should click on. And then the final one is jargon. When we use terminology which has a special and unique meaning that is not in the general parlance, people have to learn the language before they understand what that means that impairs information sent. And with intranets, it's kind of a special beast because you do have a common culture and you may have terms that are unique to your company that people outside the company wouldn't know, but people inside the company do. But the tendency is to overestimate how much people inside your company know and to assume that everybody knows this, when in fact, there's a lot of people who maybe haven't been exposed to it, or maybe they heard it and they forgot, or they're new and they haven't really absorbed that yet. And it makes it much more difficult for all of those people when we use a whole lot of special terms. So I want to look at some examples, an example of an intranet, and try to identify some of these issues that may be present. So I'm going to show you a sample of five different categories on an intranet, and what I want you to do is read through these and then find a partner at your table. So pair up in two. Or if you're an odd number, you can do a group of three and read through the categories that I'm going to show you and try to identify if any of them exhibit these traits, if they're too broad, if they use jargon, if they have any overlapping categories. So here across the bottom are the categories that I want you to evaluate looking for these three potential issues. And let's take about five minutes for this go. Okay, I think I'm going to stop you there because I suspect that you've diverged into other conversations. So we will continue those later on today. But for this question that we were discussing here, did anyone have concerns about the fourth category, the one in the middle? News. So what is our concern about that category? Broad. So maybe different types of news. Maybe people wouldn't know exactly what kind of news are in that category. What about directory and contacts? Overlapping, Right. So what exactly is that directory of? I would think at a company it would probably be a directory of people, but I would also expect contacts to be a directory of people. And one thing that is very interesting is that when people aren't sure what to click on, oftentimes they don't want to click on anything. They're very reluctant to click on something if they don't know exactly what it is. What about our last three directorates, work zone and timeout? What the heck are they? Someone said so hopefully the people who work at this company have some idea of what directorates is. Right? But the person who is their very first day on that job is not going to know what exactly is meant by directorates. And even some people who work there a long time, if it doesn't really, if they haven't been forced to go look at it and they haven't heard a lot of people using that term, they may never click on that and they may never realize what that's actually for. And when we make up words like work zone and timeout, right. We can, in this instance, we can sort of tell just by process of elimination that that's probably the most likely place for me to go to find something about vacation time or time off. But process of elimination is not a good way to navigate. We would ideally like to have a word that people know what it means by looking at it and they're very confident in what they'll get if they click on that term. It's not just a Hail Mary because I couldn't find it anywhere else. So we want to say we've identified that we have some categories which have problems with information sent, maybe in a usability test or we know a lot of people have reported, we recognize jargon that's appearing. How can we come up with a better way of doing it, a better way of organizing things? There's another technique that we use often in usability research and user centered design, which addresses exactly this question. And this is a technique called card sorting. And it refers to a practice of actually, rather than me trying to come up with a system for organizing things, I identify what it is that I need to present and then I actually get my end users to go through an exercise of telling me how they would organize them. What makes the most sense to you? How would you group these things and what would you call those groupings? So card sorting lets me understand what those categories might be. And I do this by creating a card. The card represents each of those topics or a piece of content that I need to provide access to. I have my representative users come in, I give them a stack of cards, and I say, you put these in the order that makes sense to you, and then you explain that order to me. And now I start to look at patterns for what is the common ways that people organize and group these things. Not just me as the person who's making the intranet, but the people who I'm expecting to actually be able to find things on this intranet. How would they organize it? And this is a really great technique. If you find yourself having debates with you and your intranet team of well, I think it should be this way and I think it should be that way. Rather than you kind of hacking it out and one person winning, we do a card sort. We can have not just one person proving that they're right, but a preponderance of data from our end users. What would make the most sense to the most people and use that as our guideline for how to organize things. This illustration and process I've just explained to you here assumes that you're using physical cards. This is originally how the technique was developed. But you can also do this technique, you'll be glad to know, with an online tool, which is the same concept, but instead of a piece of paper, it's a digital card. It and people can group those cards into various groupings by moving them around on a screen. And there's a variety of different tools that are available you can use to do this. The wonderful thing about these tools is that in addition to letting people manipulate and create their groups, it also handles compiling all of the results for you. And you can just imagine if you had a bunch of people come in and group cards, and then you were trying to go write down every single card and every single group that everyone created. It's a pretty tedious process. So these tools will compile that data and then put it into a visualization, which makes it much easier for you to start to detect the patterns. And this is an example of a visualization of the result that you might see from a card sort study. Each row is a list of the various cards, the topics that were included in this study, and the data. This little triangle shape is showing in each cell the number of times that the card at the top of that row was grouped with the card that's on the side. So you don't need to see the numbers. And they're too small for you to see right now anyway. But what I want you to see right here is the color coding. So the intense dark colors are showing things that were often put in the same grouping. And then as it gets lighter, they were less likely to be grouped together. The things that have no color at all were very, almost never put in the same groups. And just doing sort of a squint test, looking back from this, you can start to see clusters of distinct areas of dark colors. And these are the natural patterns of what the people who participated in this study thought was the most reasonable way of grouping things. And this is a technique which gives us that data to base our decisions on. So I want to tell you a little example of using this on an actual intranet. This was a team I worked with which had a legacy intranet system. Their old system was organized according to different groups within the business. And they had a regions which listed their various regional offices. They had an area for tools and an area which was divisions of the company. And you can kind of start to see how this was very a department set centric way of organizing things. So they wanted to come up with something that was more intuitive and more understandable for their average user. We did a card sort study and addressed some of these problems. So one of the symptoms of the legacy system that you may have encountered on your own systems is when people don't know where to find things, when there's poor information sent, there's an instinct to try to just put a band aid on the problem. Let's come up with a fix. And oftentimes that fix is a workaround, which is let's just make a shortcut menu so that people don't have to go through these categories that nobody understands in order to find what they need. And this particular system, this had happened several times. So they made a quick links menu, and then at some point, they also came around and made a resources menu. And then somebody also made an I want to tasks menu. And when you looked at these three menus, one thing you noticed they were much longer, but some of the items were things that would appear on each of the menus. So in quick links, you had a link to where you could go and look up a term. And in resources, you could also from there access the glossary to look up a term. And if you went to I want you, I want to, you could also go and look up a term over there. So clearly there's very commonly used items that everybody needs to get, but nobody could find them within these very broad departmental categories. Nobody knew who actually owned the glossary and where should I go to find it. So when we did a card sort, we came up with a list of the main topics that they wanted to present to people. Had the participants and people who worked at that organization go through the study and create groupings. And when we got the data back, we saw clusters of colors, which were certain items that were grouped together. And this one, if you'll notice, compared to the previous one I showed you, this has very clear and distinct five areas and just a little bit of muddled light blue. This is much more diffused, but it still has some areas that are definitely more colored than others. We're not going to be able to come up in this system with one perfect solution. That is exactly what everyone would do. We have more mixed signals here, but basing our organization system on the strongest categories that emerge is still going to be better than me arbitrarily deciding what I think is good. Based on this categorization, we then came up with some task areas that a lot of people saw as important things they needed to do. More of the content ended up being grouped by the type of Work that that was being done. And the most valuable part of this card sort was in having a data driven reason for explaining why certain approaches weren't gonna work out very well. So prior to doing the card sort, one of the proposals on the table was to have a main category of the new intranet be documents. And documents as a category is not one that anybody created. Who was somebody who worked there. Nobody thought, I want to wake up in the morning and just go look through all the documents on the intranet. That doesn't sound like a fun thing to do. So by having that card sort data, we could change that conversation to not just say, well, I think having documents is a silly category to saying, hey, no one organized documents as a category of how they would expect things to be grouped. So that's why it's not going to be included in our plan. And it's not, you know, a personal or political decision. It's based on this data that we've collected. If we have groups that we've created, and particularly if you have that kind of not as clear categories that emerge from a card sort, you may want to follow up with the final method I want to mention today which allows us to determine whether categories are going to work the way that we expect them to. So this is that testing step that we would do in between coming up with a plan and implementing it. And this method of testing is called tree testing, and it refers to testing your plan for how I'm going to categorize information to see if people understand the categories the way that I expect them to. So a tree test involves creating the categories that you plan to use. And this is the tree part of the tree test because it refers to your main categories and then any subcategories that will be underneath it. And they may look like your tree might look something like this. I have my home and then each category and each subcategory. Once I have that tree, I can import it into a tool which will use that. And this is just a spreadsheet. It will take my spreadsheet and turn it into an interactive menu that people can click on. Then I can give people tasks which require them to navigate through that menu and see if they can reach the correct place that would actually have the information they're looking for. I send that survey out to my users. I recruit people to complete this for me, and I can start to get a sense of whether my menu system is going to work the way that I hope it will. And I can find that out before I actually build it. So I want to have you actually complete a tree test and interact with it. So there is one that I've set up here. This is using a tool called treejack. And there is a link that you can type in up here. Or I think we were going to try to also push the link out. It's in the activity stream. So if you open up the conference app in the activity stream, you can click on the link from there or you can also type out what's shown up here. So it's short.inngroup.com treetest and when you pull that up, you can do it on your phone or on a tablet. Follow the instructions. If you don't have a phone or tablet handy, you can also refer to this slide and just read through and answer the questions that are shown here. Okay, it looks like we have a good critical mass of data, so I want to show you the results of everyone, what everyone in here just did. So can we go to the results link for this? And then I think we'll want to scroll down a little bit to see the charts. So the first task that you had was finding a conference room. And we can see on this one, this green, green is good. This is color coded. So this is just like a quiz in school. We say, these are my categories. Did people find it successfully? And I see that the vast majority of people did successfully get there. If I go down to the next one, I'm going to see a picture that looks pretty different. So this category did not work as well as the one before it that I was hoping for. And this is super valuable information for you to know before you roll the intranet out. Right. That majority of people are not gonna know where to go for this task. So we wanna make the tree test focus on the really important things that people need to be able to find. I can put it in a spreadsheet, write it up in a tool, get people to do a five minute survey and get some confidence that the system I'm planning to use is actually gonna make sense. Sense to people. Right. First contact before I've actually invested in creating it. Let's go back. So these methods that we've talked about combine to give us more confidence in our systems. The tree test, let me just show you quickly. This is similar to the result that we looked at. This is another study. It also will show us in a tree test, if people didn't go to the right place, where did they go? So this is a really unfortunate task where people went all over the place. Ideally we would like to have everybody going boom, boom, boom. They went to the right place. If you see something like this, people had no idea what end was up. But we can start to get a sense of where else they might have expected. These methods that we've talked about today, each of them is going to tell us something a little bit different. Analytics will tell us what did people, what was their activity. Surveys will tell us how they perceive the Internet and what is important to them. Usability testing will tell us what's actually happening that is causing difficulties and what are the things I might need to change to solve those problems. Card sorting and tree testing are going to help us get a sense of how to organize things and confidence that the way we're organizing it actually is going to work. And taken together, each of these, we want to choose the method that is going to answer the question we're trying to solve right now. And together these can combine to give us a navigation and organization system that is based on data that we've gotten from our target users. Not just on my ideas or my opinions or the ideas of one important leadership person role, but someone who's not actually the person who actually needs to find things on that Internet. Right. And have a much firmer basis for how we can make these decisions. So I hope that you will find some of these relevant when you get the slides. If you see one, you're like, I want to do that. There are some links included in the bottom section that will give you a little bit more of a starting point to go on. And some of the tools mentioned in here are pretty accessible, very simple. And none of these are rocket science. You don't need a PhD in research to do any of these methods. And you're going to get a lot of valuable information from whatever you invest in this type of research. Gives you a big return and confidence and solving things and improving them and before they're already implemented and become really costly to go back and change. Thank you so much. I'm really excited I got to be here today.