About this talk
This talk highlights the principles of information architecture applied in the redesign and development of websites for organizations such as the Milken Institute and the Marine Biological Laboratory. The speaker emphasizes the importance of user research in shaping content strategy, utilizing taxonomy to enhance search functionality and related content discovery. By discussing the navigational structures employed in both organizations, the speaker illustrates how a thoughtful approach to content hierarchy can facilitate user engagement and accessibility. Strategies such as designing flexible navigation menus and ensuring content editors have a user-friendly experience are explored to keep websites organized and efficient for users over time.
Full transcript
going to forget something. Um, uh, we are based here in Chicago. We've been around for about 25 years. Um, we are design and build digital experiences, websites, web apps, um, and have a large base of UX research and testing expertise, uh, specifically for associations, global nonprofits, higher education, and uh, health care in the health care space as well. And there's a little more about us up here.
Um, so what are we going to talk about today? Um, for our information architecture deep dive, uh, I have a couple of example projects that we want to go over and show how, uh, we've applied some of these principles. So, we'll talk a little bit about how the user research we did drove the content set strategy for these projects. Using information architecture is a really good foundation
for improving user experience, and then, obviously, how Dribbble helps make all that magic happen. Okay, so, uh, one of the examples we're sharing today is, uh, the Milken Institute website. Um, this is a project, uh, that we worked on with them for a user-centered, uh, design and development. Uh, Milken Institute's work is all centered research and large-scale events that, um, are trying to help solve some of
the world's most pressing problems. Um, and we also were working with them to on some, uh, very targeted digital campaigns. And again, um, designing and developing an enterprise website. Our second example is the Marine Biological Laboratory. The MBL, as we refer to them, um, they're a nonprofit institution, um, that offers research opportunities for scientists from all around the world, um, as well as educational courses for students
all the way from high school through post-grad, and they also have sort of this legacy of convening people and bringing people together to help talk about some of the most important scientific research that's going on right now, and really making it one of the best research and gathering experiences for scientists of all ages. So, for these projects where we were really diving into content strategy, design strategy,
and rebuilding sites or repurposing sites or reskinning sites in Drupal, we wanted to start with the research. And we like to say when we're starting with users and stakeholders, tell us how you really feel. Don't hold back, right? We want to know what some of the things are that you love about what you have right now, and what can we make better? So, we talked to everyone
from project sponsors, so the folks who we are connecting with on a weekly basis, who kind of had gathered all the knowledge of what needed to happen in the project, as well as stakeholders from across many different departments, content editors. I say this all the time, my team members are sick of me saying this, but content editors are users of the site. We have to treat them
as such, and you need to include them in your research because their experience is just as important. Otherwise, it makes it harder and harder for things to get done. And then obviously end users, the folks who are coming to learn, browse, gather more information so that they can engage with you as an organization. So, what have we heard? I'm sort of combining what we heard across these
two projects, but there were a lot of things that we heard that were the same. Everyone relies on search. People who worked on a paper are searching the site to go find where their paper is on the site, as well as obviously your end users. But if that experience is not reliable, then people are going to lose trust. And if people can't then rely on the navigation
to find things, they're going to go to Google to find things on your website, which is not great. and that means it is definitely time for a change. One of the other big things we heard is that we can't leave people stranded once they get to a really important piece of content. So, the users we interviewed generally fell into kind of two categories of behavior. There were
the kind of just wanted to browse, they wanted to see what you had published on a very on a specific topic, or they were in the camp of if it doesn't land in my inbox, it does not exist. I will not try and go search for something, it has to be delivered to me. But there was a an agreement between these two camps that if they were
being delivered content or they landed on a piece of content that was valuable to them, they wanted to be able to find more of that same thing, or find something that was also written by that trusted expert that they know that they want to keep following and that they know that that content of that that person has published is extremely juicy. Moving on. Um so, the good
news is we can rely on taxonomy to help with a lot of that. So, we knew as we were developing both of these sites, search was going to be a huge priority, and that we can use taxonomy to really feed the facets and filters for search and different kind of searching and filtering experiences on the website. And then, to handle that related content need, we We to
make sure that the terms we were using in those taxonomies were specific and descriptive and had very clearly defined views to serve up things in the right places. We knew that users wanted to find the newest research or reports or articles very easily, but we needed to honor the request of different departments or program leaders to make sure that their content was being surfaced in a way
that folks who knew and engaged with them could find it very easily. And then again, just making sure that we're closing the loop between those pieces of content. Making sure that we are serving up more of that same category of things or linking you to other research by that specific person. So, how do we do all that? We start by measuring twice and migrating once. Uh setting
ourselves up for success. So, we knew that as we were building out the proposed site maps for both of these sites and really, you know, as we're approaching that phase, obviously we need to reflect what the users want. That's the point of doing the research. It helps cut out sort of the ambiguity and subjectivity of what we are trying to do in this next redesign phase. And
also, we know that there are opinions of the people with whom we are working, the people who we whose content we are serving up and we want to make sure that they also felt heard because that's why we asked them their opinions in the research, too. And then always, you know, creating a hub for that published content. So, for those browsers, they know where to go, they
know where they can come back to, and they know that they are going to see new content published there on a regular um that's going to be trustworthy and the most up-to-date. So then we inventory everything basically. I equate this phase of the project as to kind of purging everything in your house before you move. First you're wondering how you amassed all this stuff in the first
place. Like why do I have seven lemon juicers? No idea. And then like you have to figure out what stays, what goes in the boxes, the nicely labeled boxes, then what can we get rid of, and then what actually gets packed onto the truck and moved. our next step is to make sure that we can give this all a really good home. So from that cleaned up
list, the know the stuff we know is making it onto the moving truck, we're able to neatly organized polished content into the right buckets to make sure again we're meeting the users needs and the needs of the folks whose content we are publishing. We wanted to make sure that we are highlighting experts in a way that people can find them, the folks who we know are looking
for them in those specific experts in the content they're Making sure that we can accurately represent the departments who are publishing this content on the site as well. And so that if people are are always going back to one particular program for their research that they can find it and they know where it's going to be every time on the site. And then also making sure that
as we're building out our navigations, we also have a nice little tidy focused utility nav for those things that we know belong there but not packing it full of like we don't know where this goes so we're just going to throw it in the utility nav. That's a no-no. And then we put a fresh coat of paint on it. So, the question frequently is to mega menu
or not to mega menu. Um so, we want to make sure that as we're making that decision, we're thinking about how many levels deep is our site map. {slash} How many columns are in the spreadsheet where you're doing all of this work? How many sibling pages are there at certain levels like level two and level three that we might want to surface in that menu? And then
is there a similar number of pages at that level one? Is this experience going to be really inconsistent inconsistent where you have like 17 things in one part of the mega menu and one lonely page out on island? Um we want to make sure that we can make that organized and be sort of a experience for users. So, the a good nav will keep users focused enough
to find what they're looking for. And within the hierarchy of the site, we wanted to make sure that we can keep folks streamlined enough so that they recognize also kind of where they are within the site no matter how deep we go. So, how did we do that? Drumroll, please, Chad. All right. So, our first example here. This is uh our navigation for the Milken Institute site.
So, I get to use I learned a new word. This is a bifurcated nav. You're welcome, new vocabulary word. Um which really helped us tackle the two main things that this nav needed to do. So, from the research we heard that users really wanted to be able to find content by a specific topic or they recognized that it was in a specific format like newsletters or reports
and that's where they kept going back to. So, that was sort of the left-hand side of the nav. And then it allowed us to focus everyone in that particular area with these different drop-downs, and they can continue to drill down. Whereas on the right side, we're highlighting the different pillars or focus areas of this organization. So, people who know what FasterCures is and know that they are
going to go back there time and time again can find it really easily in these very clearly labeled pillars. And then there's always a way to get to that page and children, and then always get back up to that top level, as well. So, now we had a different approach Is this going to be the next one, or did I just do this? Yep. For the MBL.
So, in this case, we went ahead and worked with a combination of a mega menu, which surfaces the top level, level one overview page, and a plethora of level two pages. But as we drill down deeper, we used a side navigation, which helped follow that which follows the user base run where they are on the site. But what that helped us do is we have really important
content, like research centers, which kind of need to be their own microsites down at a level three, but it allows us to keep drilling down and down and down. Um and there's always a way for you to get back to a level before either from the side nav or from the breadcrumb. So, wherever you land, because you're not always going to come in from the homepage, right?
You're going to know in the context of the larger site kind of where you are, and you can backtrack your way back up if need be. Oh, what did you just do? No, go back over there. Okay. we know that a site is not just a navigation. So, we need to figure out how we're going to build out the different content types that are going to fill
in that navigation. So, when we were talking about the content audit Oop. We want to think about these main guiding principles. So, let's keep what we can be what can be repurposed. We don't need to reinvent the wheel every single time. Uh we just need to figure out how to transform it in a way that is going to fit this new structure that we put together. Be
selective with new content types. And that doesn't always mean go to the smallest number of them. It's just making sure that it's fitting the content that you know needs to be on the site and thinking a little bit into the future for how that might grow over And my favorite one, be kind to your content admins and editors. Make it as easy as possible for punch out
20 articles in a day if they have to. Let's not make this be a barrier to getting content updated on the site as quickly as possible. So, first I want to talk a little bit about the taxonomy strategy. So, when we're doing these audits, you've all seen it. Uh things can get kind of overwhelming over time, especially if a site has been around for a while and
you've had many hands kind of getting in to do different content admin tasks. So, we start by making sure we're looking at all of the vocabularies that exist, figuring out where can we consolidate, what is duplicative duplicative about this, and making sure that the terms actually mean something. So, let's get rid of something that's going to be confusing or that we heard in the research was confusing,
and make those taxonomy terms really work based on the content that we know is on the site and what our users are looking for. again, making sure that we're updating terms for accuracy and nest them as much as we possibly can. And if you get stuck, this is the only AI reference in this whole thing, okay? Um, you can use AI to help. So, if you have
started with your you've already done the work to kind of clean up the list, feed that in, compare it with high-priority keywords that you know you're working with, and then use AI to refine it based on the content that's on the site. Are we actually tackling uh are getting to the different um terms that are going to be meaningful to the users and accurately represent the content
that we know that we are going to be publishing. So, in some cases, and this example is more specific to um one of our sites, we condensed 17 different vocabularies. 11 of them were totally unused and had no nodes assigned to a single term down to six. So, and that nesting also helps us really accommodate the volume and all of the different areas where we know we're
going to be associating content and specificity. Because if you start putting in terms that are sort of broad and vague, then people aren't going to engage with them because it's not going to mean anything to the users. They know what they're looking for. We have to help them get there and this is one of the ways to do that. And then this also helps sets helps set
us up for success in terms of the related content uh that we need to set up as well. All right. Now, in terms of our other architectures considerations. When we're thinking about content types, again, we when we're assessing kind of the architecture that we are building to accommodate the UI design, we want to strike a balance between flexibility and consistency. And this, as I mentioned before, this
doesn't always mean we have to get to as few content types as possible. Um that audit that I mentioned really early on is not just a list of like, "Okay, here are all the pages and here are our taxonomy terms." but also all of the fields, entity references, what paragraphs are they using, so that we can build the content types that are going to accommodate all of
the different pieces that go into making a single node or many nodes, as it were. Go on. Um we also uh want to use our structured content, the thing that Drupal is so great at, as our workhorse. So, we, when we're transforming or migrating hundreds or thousands of nodes, we lean on this in uh particular to help editors get timely content published quickly. Um we frequently can
use this and use one particular content type even if some we have a lot of content that may not be all one type or one specific format, um but it needs to be related to other formats in some kind of way. Um and then we can use a few extra bells and whistles on that and it gives our editors a guideline of here are the things that
you can add to and by those terms, those taxonomies that we're giving you, we're allowing you the flexibility to know I have this one content type and this will help me control publishing to many different places on the site and my related content is going to work without me having to think about it too hard. in practice, hopefully this is mostly legible. Um this is one of
the examples of a really high value piece of content um on the Milken Institute site. So, they publish a lot of reports and this report is based on one content type that is shared across about um 11 different kind of formats or ways that you can find content. So, we're newsletters, um again, like research reports, um different essays and things like which we may want to relate
together because they might all be about the same kind of topic. So, we start up at the very top in that little eyebrow that is you can't see at all. Um that's the format term. So, if I've um filling this out and I say, "Okay, this is a report." then the user knows this is a report and then we have of course fields for our title, the
date, and then a list of topic terms. What is this about and how can I get to more of it because of course all of those things are going to be clickable and they'll take me to a list of a view of all sorts of things about that same topic. We have a media reference, uh media entity reference for our report. Obviously a field for the description
and then that beautiful beautiful view at the bottom for all of the related content that is uh related by topic to this particular report. And then on the other end of things, we're using some of those same principles. So, for the MBL, we knew that people came to the site frequently looking to find specific scientists because these are folks whose research they had read a lot or
they want to work with them or uh during the summer because the the big research programs all convene during the summer. So, we want to make sure that if someone is looking up this specific scientist, we can show them, okay, which research center are they a part of? Do I Can I And then I can click to that and say like, "Ooh, they're in ecosystems. What else
does ecosystems do? What can I learn more about from there? Which research areas are they working in?" Um and then obviously sort of a bio and some other uh information about the scientist as well. And then we have a view of all the news and research highlights because one of the content hub areas on this site are the publish is their publishing news and articles about research
that people are doing at the lab or publications that have come out or awards that have been given to certain scientists, all who come to the MBL and work there. And then it also shows we can add related scientists or people who this scientist works with. And then that gives users an easy way to go, "Well, I want to know what they're publishing now." Um and then
at the very bottom we have publications that um this scientist has worked on that are published um in other entities. So, I'm going to backtrack to our taxonomy for a second. So, we were looking at that report earlier and it's beautiful and lovely. And where does it live and how do I find it? So, this is an area where we've used taxonomy to help drive our menu
position rules and our URL aliases. So, I want to be able to find this report and I want to be able to go back to that report section of the menu that we looked at earlier. So, what we've done is we obviously have the root domain. We know where it lives, the content hub notice the parent page where you can all of the published content on the
site. And then we have these nested terms. So, we have research and reports. Reports is a subset of that. And then you have the actual note itself of the title. So, our term level two, which is the reports, is that format term and it ladders up to where that home is so that users can again kind of backtrack if they wanted to see more of that or
give get more of an idea of all of the content that's been published on the And in a different way as well, um we were able to use taxonomy terms to help build out specific course catalogs. So, for the NBL, this was a site where before we started working on their redesign, um they had 12 course microsites across seven different platforms that we had to bring into
this site so that everybody could find all of that content, it was consistent, and easy to find, and so that people could more easily get there and register for it. So, we were able to obviously use sort of a standard menu this standard Drupal menu structure, but then we're also able to uh tag these different um tag these different courses based on their levels. So, is it
advanced? Is it for postgrads? Are we talking about courses for high schoolers? Um and then the different areas of focus, so cell physiology or microbiology. So, really utilizing taxonomy to help organize the content in a way that will help users come back and find it if they want to come back and apply again or come back to the MBL. when we're thinking of those content types and
how and engaging with making sure that that content can be flexible if we're going less of a structured route, default layout is the absolute best for consistency because it strikes that balance of giving content editors a way to move content around based on what's the priority at that particular time of year or as a specific event is coming up. But, then it also helps us maintain the
guardrails of good user experience that we established way before we even started developing the So, when those powers combine, we get a really flexible page where we can still make use of some of those great, uh, structured content pieces and serve up more of those related content pieces across the site even if one of these nodes is not particularly structured content. So, in this case, we have
an entity reference, uh, at the top for a featured report or a featured event or something that's really important for this particular program, and that's because that report has been tagged with a taxonomy term for this program. So, again, I don't necessarily need to think about, like, do I have to place this here? Is this going to show up in the right place? The taxonomy is doing
all that work for you. We also have very simple field for a little description, and then an entity reference for, okay, and now what children am I pulling up to feature under this specific program? And that's what drives that middle section with the kind of blue area is, show me all the children of this program so that people can dive deeper. Again, not giving them kind of
a dead end. Like, let them keep diving more specifically into the programs that we have. More related content, our favorite, that lovely view. And then an easy block because not every program has a newsletter sign up, but this one does. So, we want to let them add that when that's applicable, um but not make them uh have to think about whether they need to add that every
single time. And then a view of the people who are on this specific team. And then all of that lovely work that powers our search. So, all of those taxonomy terms that we've nested, that we've worked hard to make sure are accurate and usable, are all of the facets and filters that people can use within the search functionality itself. So, that as they want to dive deeper,
if they're looking for something specific, they can keep on drilling down, search for content by a particular expert if they want to, and just help lead them down the right path. And it can also help drive additional filtering. So, all of those fields that we saw on that scientist node earlier, um help drive the faculty directory, which is where a lot of people go to see, okay,
who is working at the MBL right now? Are they on campus? Can I go see them when when I visit over the summer? Summer is a very popular time in Hole, Massachusetts, just saying. Um but so they can but if they are studying a very specific area, they can search by research area or research system to understand who they can connect with to either help with their
research or what they're studying or kind of what their next steps are. So, our takeaways. Number one, start with research. And again, that all helps reduce subjectivity as we're making these really big and sometimes frankly scary decisions about how the information architecture or navigation is going to change. Also, invest the time in auditing and documentation. The measured twice, migrate once is so important so that nothing gets
let left behind, but also you're making sure that you're having the conversations not just about, "Okay, what content do we have right now?" which may or may not be optimal and thinking about, "How will this grow and scale in the future?" We think about every page as a side door to the website, making sure that if someone lands somewhere very specific and like a level five somewhere,
they can understand where they are and know how to navigate to other places. And then, making sure that the content strategy is very clear and that what we're building again can support that that growth. Um Drupal is super powerful and too many choices sometimes can be overwhelming for our content editors. So, we want to make sure that we're being intentional about choices like, "When is layout builder
appropriate? When is struct- structured content make more sense? How many views are needed on a particular node or across a particular section?" Um and all of that really sets the site maintainability, content editor quality of life. I will keep saying this until the day I die, um and then scalability for the future. that's it for now. Um I'm happy to open it up for questions if anybody
has any. Yes. Hi there. so there was a a slide where you showed a URL for a report and I forget what all was in it, but part of it was there was like a term and child term. >> Mhm. What my question is is it seems like there are possibly a number of different legitimate ways to construct what that URL is going to be and what
the resulting breadcrumbs and ways to track back. Can you talk a little bit like it just picturing that particular one like I could I could picture like having the department or the the area of study being sort of a parent level thing and drilling down to where you have reports that are just specific to that area. Mhm. How do you choose what's going to be your sort
of canonical approach there? Yep, that's a great question. So just to repeat it for the recording, how when we're thinking about uh the menu structure and the URL aliasing, how do we make a choice about what that structure looks like and what that parent-child relationship is? In in in a nutshell, I think that's what your question was. So I'll talk about that specific example. So what we
heard, more specifically in the research, is that a lot of the important reports and things were kind of buried on a specific program's page, but that was kind of the only place to find it and the the URL alias at the time wasn't very specific about where that lived or how I could track back to that was a very intentional decision. It's not the only you know,
the only option obviously, but was a very intentional decision because we wanted the content hub to be the source of truth uh for what those menu what the URL aliases were that we were nesting things in a way that would make sense to the user of what type of content that so let me say that in a more succinct way. The type or format of content was
higher priority for driving the menu position rules and the aliasing for this particular site. So, you one could also say that the if we had made a different decision that a report or a body of published content if we really wanted that to only live under a specific program, then we would change that aliasing because we would still have that taxonomy relationship between that report and the
program who published it. We could have changed that so that say a report like that would live under Faster Cures instead of in the content hub, but the content hub became the library because there was no one library to find everything. So, that became the the main source of truth for where you could find anything that was published. Again, we're talking about like newsletters, specific essays related
to events, even panels from or the sessions from their main event. Those aren't even tied They're tied to the event itself, but if you look at their the URL alias, those panels are also children of the content hub because we want people to be able to go back and find those individual panels cuz they they'll remember they would likely remember the topic, but they may not remember
what year of global conference they went to to go watch that again. So, that's why that specific choice was made for that type. But, to your point, there are plenty of options. It's just kind of what is the right choice for what the goals of that site are. That was a very long-winded answer. Sorry. Yes. Hey, Anna. It's along the same lines, but your um aliasing, is
the taxonomy itself generating the alias, or are you actually going into every like node of page and typing it out manually? Or is it So, if the change is like if a taxonomy term changes, are you then having to use something like path auto to re-path it? Cuz that's who's that original that's a great question. So, the question was if the taxonomy term do you have to
go in and regenerate the alias? I That's not a manual change on the content editor side. So, I do believe it's auto updating if they decide like, "Oh, this is not the right We need to add a word to this one term." Um the the rule will help kind of update that all. And we do have like the generate automatic alias on. And and then when when
that's not happening, we say, "No, please don't do that." >> [laughter] >> Yes, in the back there. >> I'd love to hear more about the Milken Institute drop-down strategy, both the explore button on all the drop-downs, uh navigating that entire section uh menu within that drop-down. What led to To what user research informed that? Tell me more. Yes. I think that everything was being navigated to in
a drop-down menu on a desktop >> [clears throat] >> I love that question. So, the question why did we do a drill-down menu for the Milken Institute website? Um I will do so. When we started exploring the mega menu option for that site in particular, the not just the number of terms that were being nested and nested sometimes uh within those drop-downs, but also once we got
to the to the right-hand side of the nav, which had more to do with the uh with the programs themselves, the departments themselves, um it was so huge that we just felt that it it you sort of stopped paying attention to what the words on the screen were. So, what the what the drill-down menu did and why we have that explore button is we wanted to get
away from the overview page being the thing that opens the next level, but then also is a link because no, don't do that. Um but it gave gave the option to kind of keep drilling and remaining focused, especially when we were introducing updated taxonomy terms. Um so, it was allowing users to have a subset and say, "This is what I'm looking for. I'm interested in seeing more
of what lives under here." And so, they actually can process all of the words on that screen. Um because again, once it started opening up into a much bigger format, you would get lost instantly, start to glaze over. I don't know what I'm even seeing here. I don't think I'm going to be able to find it. And then maybe you'd use the search bar instead. You're welcome.
Yes. Yeah, I have a question regarding taxonomy. Now, you could have a content [snorts] item which could be tagged with two more than two uh taxonomy uh headings. For example, it could be a a press release or a publication. It could be a news article as well, and it could also be a report. So, so in that situation, now when you said like you have to have
a backtracking system, so how how does it come out to be with respect to aliases and all that? Okay, so the the question was if you have multiple terms within a same taxonomy, how does that work, and how do you choose the correct URL structure based on that? So, the way that we built this is actually you can only choose one format for a particular node. And
that's part of what also fed into the content hub, which is based on that format being the main source of truth. Because a user can choose only one format, a thing can only be a report or a news article or an essay. But, as we saw in one of the examples, it could have eight topics. So, that piece of content would be surfaced in any related content
with any of those But, that's what gave us the rigidity to be able to say, "This is what the URL structure is going to be because this node will only have one format." And that's how we know kind of what the source of truth and what the logic is for generating that URL alias. Thank you. Yes. So, sorry, this is a little a bit off topic, but
um you got the stakeholders never want to do testing of the content editor experience. And I'm curious what your approach is to persuading them to to actually do testing with the red-headed stepchild. >> Oh, the red-headed stepchild. Uh so, the question was how we convince stakeholders to do user testing with I would Let me backtrack. So, we It was more user research, so not we weren't doing
a usability study on the content editor experience, but frequently we will suggest that we talk to those folks in the user research phase when we're doing interviews. And often they're also part of that project that core project team. So, we can speak to them as we are making those decisions about the content types, what fields this going to have, do we want this to be structured content
or layout builder. And they're one of our main sort of consultants as we're making those choices to say, is this going to give you what you need or is this going to be too rigid for what you try to do on a day-to-day basis because they're the ones who are in there fielding all of those requests and saying, "Right now we have one piece of featured content.
I need there to be seven, and how do we make that happen?" So, they because they hold so much of that so much of that knowledge and so much of that experience, we tend to we have the luxury of continuing to go back to them and asking those questions throughout the process. So, it's not we've built a thing, have at it. It's we're we're moving in this
direction. We want to train you on how to use this particular content type and we want to make sure that as you are starting to enter content, let's try to take a couple of use cases. What's your nice lovely one that is closer to the actual to the design that we've presented and what's Sorry to use this term, but what's your worst case scenario where you are
filling in as much content as possible that may stretch what the confined confines of that design will be. So, we're able to loop back with them cuz they are so frequently part of that particular process. So, not quite testing in that way, but definitely research in terms of continuing to get their input and what their pain points are and what they're being asked to do on a
day-to-day basis. Um I noticed as I was looking through both the Milken site and the MBL site that I wasn't seeing any of my favorite four-letter word, which is PDF. Was that a battle that you needed to fight? Was that the culture of the organizations? I ask this because in designing a landing page for one of my organizations departments, I got handed, I kid you not, a
35-page PDF newsletter. how did you get away with not having that many PDFs? >> Well, I will say that's that's not entirely true. So, a lot of So, for the Milken Institute, for instance, the reports that they are publishing, they they're they are in PDF form. They are many pages long, but we create that node to surface that and give some nice juicy SEO descriptions and takeaways
to help drive to that page. The I think the one of the biggest battles that we had on the MBL site was because the course information, but 12 of them, seven different platforms, wild west. Because so much of that was in documents, we said, "We need to make people know that the MBL is the place to be and where they can come find this information year after
year, and we need to be able to surface that in a way that is crawlable." armed our project team with the information to say, "We know you want people to keep coming. We know you want people to find this place. This is one of the ways that this can help happen." Um is that we need to not hide things in documents where they're not or it even
if it's not people who want to come, it's people who have already been and they want to be able to find something from a course they took seven years ago or whatever the case may We were lucky. Yes, we were lucky in this case. >> Yes. Um once you did the the great information architecture work for these two organizations and you delivered the sites and you trained
them, did was um a process for thinking about governance so that over time editors don't drift from the best practices and the site becomes a mess again? That's another great question. So, the question was about um establishing some kind of content governance system so that the great practices that we set up don't go astray over time. these two cases, we were fortunate a a few people who
are really entering the content on the site um who understand and who we've trained to feel that information and know where everything is supposed to go. We have conversations with them when they say "Oh, somebody asked for this particular thing that's a little bit out of the box." And we can step in also and say "The reason we didn't set something up like that is because XYZ,
but here is a happy medium because our favorite phrase is yes and." If you're from the area, if you know improv, you know this phrase. so we can say, "Yes, we understand why you want to do that and how about we try to add this page over here so that we can also make it work within sort of the related content structure and not put things out
on an island. Um so we do we have been so bold as to intervene when there have occasionally been choices sort of outside of that realm. Um but also having uh stakeholders I think the biggest thing is getting your project sponsors on board with the strategy so that they can articulate why things are done a certain way and why certain choices are made and the value that
that consistency brings for the end users. It It like it's more inclusive with being able to find what people need rather than you have some of those stakeholders that get so hyper focused on their little spot. You just got to keep them thinking that you're thinking of the whole picture, not just Yes, absolutely. So, making sure that we're not just thinking about sort of one specific department's
needs at a time. And doing the user research is what is so great because then we can always loop back to that and say, "I understand you want this." And remember when they said that it was really hard to find a thing when it was in that place, let's not put it back there because then we're going to we might be resurfacing an old problem that we
were trying to solve in the first We've got 1 minute left. Any others? Oh, yes. Just a question about the uh so, if you had an open one, let's say there's a a link in body copy to PDF and it's on that site or there's a button that goes to a PDF on that site. Generally, it seems it's if it's on that site, it should open up
in that window and it's supposed to see it. And how do you Is it acceptable if you click the back button as the way out of that situation or what are your thoughts on Yes, so the question was about opening a PDF either in a new window or potentially downloading it. Um so, yes, we frequently will open Well, we'll frequently keep it so that it opens in
the same window so that you can use that back button to get back to the original place for many reasons, mobile first being the top tied with accessibility and such. So, keeping it in that same window, this is I will say this is something that I struggle with because I am a quick exer-outer and then I'll be like, "Oh, shoot." Um but I'm just one person, so
I can keep that opinion to myself except I just shared it here with all of you. Um but it is yes, we we wanted to open in the same because especially for for users who are on mobile and a lot of the folks who are using these sites are we want to make sure that they have an easy path backwards. And yes, one more question. AI and
SharePoint voice and the search behavior changes come into play with your IM structure recommendations? Or did you still think about it in a very um understandably traditional site experience once you're here and you need to navigate through the site? So the question was if the current AI state kind of informed that information architecture that we built out originally and if we're Oh, okay. Hold on. My own
my own laptop just kicked me out. Thanks. if we stuck with sort of a more framework. Uh we started from a more traditional practice and we are continuing to iterate on it because one of the great things about that very specific strategy and making all those choices about building out a robust taxonomy and making sure that the structured content is in really good shape is that now
that schema is a thing, there's not a lot of legwork to do. We've done a lot of that already. And so as we're continuing to build some of that out, now we have a great foundation and there's not we're not doing rework. We are really building upon what is already there, which could be a whole other talk for >> another time. Um but it really does even
that sort of more traditional menu and site map build out and the way that we use that taxonomy, it feeds into that just beautifully. I think I'm at time, but come find me if you have questions. Uh come find Sam's from booth and uh we also have uh Sam's from has one more talk in this room at 3:00, which I can't read from search bar search bars
to chatbots decoding user expectations for AI chat. Thank you all so much and uh please um do share your feedback. I'd love to hear it. Thank
