 I'll save you from the long definition, but in short, I think this is what it's all about. The architecture of a website makes the information findable and understandable, which I think is important as well. So about finding and managing, findability is critical success factor overall for usability, because if users can't find what they need through combination of browsing, searching and asking, well, the system actually fails. But you also need to think of organizations and people that manage the information. That's an important aspect as well. I was going to treat you to a nice video of this library where the two Ronys, the famous old British couple, maybe the English people know it, they're in a library where the Americans are so into bicolor and well, it's going to show that that's not really working for everyone. I'll go back to that later. What I really liked about the book that I mentioned earlier, they give this example of iTunes and they share a story about two people working on a building and the story has this metaphor of this minister passing by and he looks at these two guys who are laying bricks and he asked them like, first person, what are you doing? And the guy said, well, I'm laying bricks, obviously. And he asked the second person and he said, well, what are you doing? And he says, well, I'm building a cathedral. And the minister is really impressed with the answer of the second guy and he keeps on thinking about it and he decides to go back to the building site the next day to ask more about this guy who was building this cathedral and he's gone. And there's only the one guy who was laying bricks, he was there. And he said, well, where's your colleague? I want to ask him some more questions about the cathedral building. He said, yeah, that fool, he got fired because he thought he was building a cathedral but we're building a garage, actually. And that's what you should think about before you start designing a website. Are you building a garage or are you building a cathedral? Or are you just laying bricks? iTunes, they mentioned in the book, is a good example of a garage that turned out as a cathedral in the end. First, it was a management system for just your local music. Then you could buy music. Then you could get podcasts, you get videos, whatever. But the original architecture of iTunes wasn't really made for all these functionalities. And as well, when you look at iTunes on your phone, well, no music in iTunes there, but you've got this app called Music. And you've got this app called iPod, our podcast. So it's all in different sections and there's not really an overall experience that gives you the same experience with iTunes on your computer or on your phone. So that's what's called system thinking. Think about your website as a part of a system and give people the same experience on all platforms that you use it in real life or online. So next section is why it's important. Small joke there. I first had information gap, but I was at the tube and I saw a reminder gap. And I thought, I can use that. Why is it important? Well, we suffer from information overload. That's not a new thing. It's been a problem of centuries. People were complaining about too many books, like ages ago. And actually the phrase information overload was popularized by this guy Alvin Toffler in 1970, before I was born, in a book called Future Shock. But it's really become a bigger problem. The growth of information is sped up by the introduction of computers and the internet as well. And you can imagine that the findability techniques from the end of the 20th century are not really effective today. So when you look at information architecture, it actually covers three sections that are in this diagram. That's context, content, and users. And when you make decisions on the information architecture, they will help you ask the right questions to your clients. The first thing to start with is the context. Without context, it doesn't really have a meaning to design a website. So whether explicit or implicit, each organization has mission, goals, strategy, staff, processes and procedures. They also have physical and technology infrastructure, budgets and culture. So this mix of capabilities is unique to each organization. So that's why you have to look into the context every time. And the key to success is alignment, like I said before. And websites really should reflect the organization because you don't want your website to look like a competitor, do you? The second part, there's no website or information architecture without content. And when you look at content from the information architecture perspective, think about these six things. The ownerships, who creates and owns the content. And don't forget the management of the content. The format, what types of documents will there be? The structure and think about some structural markup, like XML to exchange with other databases. The metadata is very important for structuring. And to what extent will it describe the content in your system and what's already there? The volume of the content as well, think about growth, is the information that there now will it still be there in a few years' time or will it be a lot more? And at last, how dynamic is the content? Will it grow old very quickly? Or you think about the age of the content as well when you think about dynamism. This is actually what I was thinking about when I was thinking about information architecture. And as well, what people who design websites, I find myself guilty of that as well. You think you know it better than your users do, or you don't. And does anyone know what these paths are called in English? The Dutch have a far better word for that. Anyone know the Dutch term? Elephant lanes. Maybe the Dutch think they're elephants. I don't know where it comes from. There's a great book with all these pictures of elephant lanes, but it really pictures that the designer thought a different thing than what the users would do. And maybe elephants are smarter, taking the shorter route or, I don't know, they're heavy to sort of make the hole in the grass. But remember when you design, you're not your user. And Crispin Reed was talking about that this morning as well. He was talking about hippos. And well, I've mentioned in my introduction of this talk the iter method. I think this is right. Well, don't think. Well, not in this stage. What you think looks nice is a better option. The user might think different. We're speeding through. Information systems. I wanted to look at a more systematic approach on user experience and design. From what systems there are, and you can use to organize your information or your content. I can't go into it really deep. The book does, but I'll try and talk into some main aspects of information architecture, when it concerns information systems. And first, I want to show you two forms of information architecture. And I've used the WordCamp London website, as an example, for top-down information architecture. And when you approach it from here, it usually answers questions people that visit the website have. Like, where am I? When you look at the website, it makes it clear. How do I get around the site? What's available? How can I contact a real person? How can I engage on other digital channels? Well, there's a clear Twitter feed on it. So, you know, WordCamp London is on Twitter. So these questions are answered by using top-down information architecture. Another form of information architecture is bottom-up. And recipe collections are quite a good example of that. It's nothing but information architecture. There are, you see the clear chunks of the recipe, the ingredient index, the method, that that's all information architecture. It structures a recipe. And the photo app on iPads are a good example of that as well. Because I took a screenshot of my own iPad and you can tell, like, that it's sort of by date or geolocation. You know, where I've been on a holiday last year. But from there, you can sort of, like, wander through and it actually sort of calls on questions, bottom-up information architecture. So that's a different approach. Information systems consist of four components and the organization systems is the first one. And there's a few challenges there. Alice Steele will do this workshop on tone of voice later on. And it's a great deal on information architecture as well. And let me pronounce this right. Ambiguity, difficult word for me. Classification systems are made of language and language is ambiguous. And you can have so many different meanings for one word. So to conquer this challenge, make sure the context is clear for people in which you use these words. Difference in perspective. I already told you about the two Ronny's library, sorted by color. There are people that sort their books by color. Anyone does it in here? Sorry. My boyfriend does. It looks nice, though, but whenever I want to read a book that's in his bookcase, I always have to ask him, what color is it? And he will go like red. And his red section is a bit bigger than this. It's not his bookcase, but it looks like it. It looks nice, though. What you think about when you organize content, think about difference in perspective because what might seem logic to you may not to another. And labeling and organization systems are intensely affected by the creator's perspective. Internal politics, that's a challenge as well. And there's always a tone of voice or the way people want to be seen by other organizations or users. I was talking to a client and they did telephone services. And she didn't call herself a call center because that was something different to her. But not to me. I think if you answer phone calls or call to people, you're a call center. But that's like within their own branch. That's something different. So think about these things, how it affects your users. Another part is organization schemes. I'll go through a few examples of this as well. A very simple one is exact organization schemes, also known as known item search. That really works for directories. Like if you know you're looking for someone's name, you just type it in and there's the result. That rarely happens. Not everyone knows what they're looking for. So here we go with my ambiguous organization schemes. And I've looked at two English websites of museums to show what types you have. And we can distinguish three types. Topical, task-oriented, and audience-specific. And here's Tate's website. Let's see if it works, yes. Art and art is definitely topic-based. Plan your visit is task. They want you to do something. Book now, task as well. And become a member, task as well. And this is quite a simple navigation. You can't get confused easily. Museum of National History. Also, tasks like visit, discover. They want you to do something. But here we have another one, schools. And that's audience-based. And still, this is a small navigation here. But I find this very confusing within this navigation there. So make it clear for people when you use hybrid schemes, like these are used. It's never single topic navigation or audience-based. Make sure if you mix it, do it right. Because people want to make a mental map of where they are. And they get confused when you mix it up too much. I have to rush a bit. Labeling is one part of information systems as well. And actually, without knowing it, everyone who makes websites makes labels. They convey meaning without taking up too much space. You have to know what's behind the door. And websites aren't always as transparent as these boxes of herbs. So to minimize disconnect, you must try and do your best to design labels that speak the same language as the environmental users are in, while reflecting its content. So when we talk about labels, there are different varieties. Crispin Reed mentioned contextual things this morning already. And they are actually, in your text, you navigate through contextual links that are in blog texts. Headings are a very important part of the information structure, where you are in different sections. Already talked on navigation labels earlier on with websites. Indexed terms can be a good way of structuring a website. And there's iconic labels very often used on small devices to save up space, like on phones. But on websites, the old one is the house for a home or the burger menu. There are iconic labels. But labels can be ambiguous, like I said before. General guidelines to make it more clear is narrow down your scope, make it understandable for people, reduce their perspective, and keep content user and context simple and focused. If you're designing a website for a large group or different groups, it's very hard to stay focused. And develop consistent labeling systems. Think about the labels that aren't necessary now, but maybe in the future. So you will have space for them to add. And think about style, presentation, the syntax. Don't use noun or verb based throughout each other, but choose. And think about comprehensiveness and what your audience would like to see. Navigation systems. Yeah, they're actually one of the most important parts on websites of bringing structure. Like the global menu is always there, so you need to pay attention to that. And navigation is really important because it prevents us from getting lost. The signage here at the conference is pretty good. You always look for where to go and think about it that way when you design your navigation on your website. There's three types, global, local, and contextual. The global menu is of course the global navigation on your website. Local are usually subnavigations and contextual is like contextual things in your website. When we go on to navigation, we actually end up in a gray area. And you see information architecture right here under one big umbrella with different aspects of user experience design because you can look at it from so many perspectives. Doing interaction design or visual design is a very different knowledge area than information architecture. If you want to test your navigation, look it up on the internet, there's the navigation stress test by Keith Inston. And what you actually do is go to a website, ignore the homepage, and just pick a random page, figure out where you are, and get rid of the URL and then think out where you should go next. And if you end up on the page, that's logic from the navigation, you've done the right job, most of the times you won't. Unfortunately. Other parts of navigation you can think of is supplemental like site maps or indexes, but guides as well. When you do a checkout process, for instance on a web shop like WooCommerce, you get all these steps that guide you through the process so you know where you are. It gives you context. At last, don't let navigation drown the content. Sometimes websites are so full of links and navigation that it really distracts from the actual content. Another important part of information systems are search systems. That's a talk on its own, so I'll leave that for now. But there's a big question you should ask yourself when you implement a search system on your website. Does it need search? Or maybe it's just a solution to poor navigation. I know on my computer I use this global search a lot. You can imagine what kind of mess it is. It's not very well organized. Basically when you need search, it's when you have lots of information or fragmented websites that consist of different subsites. The last part, how do you do good information architecture? I have no answer to that. I'm sorry if I disappoint you here. Like I said before, the context is really important and every time you work with a new client, there's a new business context. So there's no one way of dealing with it. There is a small process that you can follow to have a way of structuring your information architecture. Always start with research. Most clients find this a really boring moment in designing websites and they ask you questions like, when are we going to start the real work? They mean graphical design by that because that's more visual and appealing and this is all very abstract to people. But when you do research, it doesn't have to be really extensive even for smaller projects. It's interesting to look at research and look at existing materials that are there already. Think about a current website. Most of the time we don't have to build from scratch. So look at the content that's already there. Most clients tend to think that's rubbish and they want it all new, but there's probably stuff you can reuse. After that, you have to move on to a decent strategy and the research provides a contextual understanding that forms the foundation for development of the information architecture strategy. Let me see, just skip this for a time. Here's the three circles again. When you do research, you work with these three circles as well. The process I showed before looks really clean, but in the real world the process is far more messy, especially with smaller projects. When time and money are on a tight budget, you have to make choices about what to include. Good research means asking the right questions and these circles will help you do so. Starting with the context. Put some rugby in there for six nation lovers. This guy knows where he's going. He has a clear goal. I really believe in business context as a starting point and not knowing what the strategy of the organization is. This is just as dangerous as ignoring your users. So at least find out about a mission, vision and business goals. The content, actually the stuff inside your information environment, users need to be able to find content before they can use it. So findability precedes usability. So spend some time on studying objects and look at existing information architecture. You can do content analysis, look at structural metadata, descriptive metadata, administrative metadata and Crispin Reid was doing object-oriented UX. What is the object? How can you describe it? What distinguishes it from others? Think about these things. And how can you make the object findable for people and machines because SEO is really helped by good information architecture. So I told you information architecture isn't very sexy. This actually is information architecture. So there's no wireframes or prototyping involved. You just make lists of content and create the relationships and where it should be positioned in your website. So I can imagine clients can't really deal with this. How is it going to look? Not there yet. So eventually the users are the ultimate judges of your information environments. You don't want them to do this when they look at your website, do you? So when you do research, do uses analysis. Look at the content performance, visitor information or search log analysis. And I've recently been installing relevancy plugin for a few websites that gives you real good insights on the search people do on your website if you have a search function. So find out about information projects that are already there. Another good method is card sorting. You can do it by hand, but there's this website called optimalsort, optimalworkshop.com. They've got really good explanation on how it works. It's free up to 30 items you can put in there and invite people by email doing card sorting tests. And what you actually ask them is to group information, help you build the structure and see you can get all nice analysis from that and sort out if what you thought was right. The user thinks that as well. Resistance. There was a question this morning with the other user experience talk. If your client doesn't want to work with you on the project, how do you deal with that? And the good answer was fire the client. I think that's a good one. Common arguments for extensive research and really digging into information architecture can be that they don't have time or money to do so. They already know what they want. I mean, clients know what they want. And they've already done their own research. But you'll be likely to convince them that they can save time and money by doing research. And if you have this all sorted out, the process of design will be more easy and shorter because you don't get discussions on what should be where and what relations you should include. Another thing is that managers don't know what the users want. I think this is right. So, involve them in user testing, like card sorting. Let them do the card sorting method as well. I really like doing research. Like I said, I did my thesis last year and I couldn't stop doing desk research. But at some point you have to get it together and make your story and make a strategy. So, because the more you learn, the more questions you have. But usually as designers, web designers, we don't have the luxury to do extensive research. So, make sure you turn it into a strategy and bring that to your client as soon as possible. Another question arise there is, because how can you develop an information architecture strategy when your client doesn't have a business strategy? Or how can you develop information architecture strategy when there's no content in place? Business strategies, content collections and information architectures don't exist in a vacuum. They co-evolve in a highly interactive manner and one cannot do without the other. But developing an information architecture strategy, it can help expose gaps in business strategy and content collections. So, it will give feedback information to clients. And the process of making a strategy will force people to make difficult choices if they've managed to avoid up until doing it. I'm running over time a bit, aren't I? Am I still? Okay. When you develop a strategy, there's four parts you should consider thinking about. First thing after research is think. Create some time to think over what you've learned and digesting all that information you got on your strategy. Good thing about thinking is you can do it anywhere. So pick a nice spot to do your thinking like Sunny Terrace or Good Park. Next thing is articulate. Draw down, make mind maps to write down your findings. And after that, communicate it with your client in an early stage so they can give you feedback on what you've discovered thus far. And the last part is testing, testing one, two. Even running an informal test with one friend is better than not testing at all. So testing is within reach for small projects as well. After you've done your strategy, you need a plan to move your findings onto the people who are actually going to do the design. And so you write a project plan. It will force the team to ask the questions and it's actually the bridge between the strategy and the design. So after this, you'll be going to the designing part and that's not part of my talk so I won't cover that. But that's when you go to the actual site mapping, wireframes, navigation systems and prototyping. So wrapping up. I hope I've given you some understanding on what information architecture is. Why I think it's important and the components that you stumble upon too when you design information systems. Bit short but how to do some research and strategy. How you maybe can convince your client that this is a part you should cover. And that was the end of my talk so thank you. Maybe there are questions that I can hopefully answer. Do you have a question? I don't know. I can upload them. Okay, thank you. My own website is currently undergoing construction. It's very hard to do your own information architecture. I can tell you that. But I'll post the link to the slides on Twitter. Is that good? Or you can email me if you want some more information on the subject. But I'll put it on Twitter. I'll put a link there. At Boom Media. So leave this out and leave that out. Okay, question? Sorry. Hi, thank you for your talk. I found that really very interesting. I'd like to know how do you deal with clients who are so hooked on what they think is the latest method of presenting a website and navigation. But maybe you know that that's not going to work in a way that it should work. So you're talking about design fashion, trends, stuff like that. Okay. It depends. That's always a good answer to give. Now it depends. As I said before, I'm really hanging on to strategy, business strategy. So if that trend doesn't fit their users or clients, don't do it. I mean, always follow your goals for your business. So I convinced them not to do, like search. They say every website needs search. Well, maybe not all of them. And if they do want it, well, at least consider why they want it. Don't do it because it's a trend. I mean, do it because you think it's useful for your website. I think just make people ask the questions themselves. Is that a good answer to your question? Yeah, I was just wondering when you're looking deeper into taxonomies, identifying the culture, the language of your audience. It's quite tricky to dig into that. Have you got any tips for that? Digging into the language of the audience? Yeah, your target audience. They have their individual language. When you search for certain words, you put your taxonomies. Okay, where will you start for taxonomies? It depends on your clientele. If you do a medical website, there's a authority for that. So you could use those. Most of us are not designing websites of really, really new businesses that are unique to whatever. So looking at competitors' websites or do research on social media on subjects that are there, you can see what they use and what the users use. As an example, you would develop a site for Generation Z. They have their own language. Yes, I'm not very good with children. I'm sorry. I think it's a bit... I do marketing, but I don't really do marketing for younger people because I'm sorry, I don't speak the language. So maybe get someone involved who does. Use younger people, maybe? Testing as well. What you can do with card sorting as well is you can do open card sorting to present them with terms and titles, but let them fill it in and see if you can see a structure on the words they use. Maybe that's a good one. I just had a really quick question about other recommended reading. Is there anything else you'd recommend? I've got quite a few books, actually, but I was going to sort of... I thought I had more time before doing this talk, but actually, up until Wednesday, 1.30 in the morning to finish it, I wanted to do a sheet with resources, but if you email me or send me a message on Twitter, I'll give you some resources, yeah? Thank you.