 Well, I was told I was supposed to start at 2.15. So even though there's still some people filtering in, which I do see that there's some empty seats up here if you're looking and can't find a seat. But I think I'm going to go ahead and try to get started here so that we don't run out of time. I also tend to move when I talk, but I'm going to try to stay next to this microphone because I'm told it's the only way that you're going to hear me. So just holler at me if you're having trouble hearing me and I'll try to stay closer. Is it still not loud enough? Good. Everybody OK? Cool. I'll do my best. So my name is Jared Ponchott. I'm the design director at a company called Lullabot. We're one of the sponsors here at DrupalCon. Actually, we have a booth down there. We're actually throwing a party Wednesday night. So if you want to talk more, because this talk is going to kind of fly through some ideas about the content strategy and what it is, and then get into quickly into some specifics. But if you want to talk more, come to our party Wednesday night. It's at a place called the Handle Bar. And we're also hiring all the time. And right now, we happen to be hiring. So if you're interested in working with Lullabot, be sure to check out our website, lullabot.com slash jobs. But anyway, I've been a designer for probably since before I even know what that meant. I went to college for design. I'm not a content strategist. Just this is full disclosure upfront. So this talk is sort of going to talk about things that I've been learning and that have been really fascinating, helpful for me. But I'm a designer. And quite a lot of the time that I've spent designing over the last decade and a half has been actually focused on the web and what I like to call rich content models, like designing with really rich content models. And much of that time was spent not really knowing, I don't know, trying to think of how many years ago it was when I started hearing the term content strategy. There's a long time in my design career where I didn't even know there was something called content strategy. Once I started to hear about this thing, I assumed that it meant being strategic with content. But I didn't really know if I were to hire a content strategist, what would this person do in my projects? Like, what are the things that they would make? You know, I know what designers make. I knew what the developers did in our projects and I knew what the project managers do. But content strategy always felt a little nebulous to me when it first started becoming talked about a lot. So what I want to bring to you guys today is just some really practical knowledge about what content strategy is, sort of a way to think about it, especially if you're designers, hopefully this will be helpful and if content strategy maybe is a little new to you. And especially kind of why it can be really, really helpful in the design process, sort of how it dovetails with design. And then hopefully some also some just really simple practical ways you could as a designer, whether you're project manager or whatever, you could start actually doing some content strategy work in your projects, even if you don't have the flexibility of just hiring a content strategist to add to the project. So first, let's define a little bit about what content strategy is. And like I said, I'm not an expert on content strategy so I'm gonna kinda lean on some experts that are out there in the field for how they describe it. One of the things I've continued to learn over the course of my career is how important role clarity is. And this is whether you're working with a team or even when you're freelancing. Role clarity is really important. It can be easy to understand its importance on larger teams, with larger projects where it just makes sense. Like we need role clarity so that we have efficiency and that everybody knows what they're supposed to be doing and whatnot. But even when you're working in small teams, it can be really, really important. Let's say you have just a PM and a front-end developer and a designer working together on a project. That does not mean that those are the only roles or disciplines that need to be brought to bear in the project. So having an understanding sort of broadly of what different roles care about, what they're there to protect and what they're doing can be hugely helpful, especially in those situations where you're sort of the lone wolf. And so hopefully I can kind of arm you with a few things about what the role of a content strategist is, what they care about in ways that maybe you could try to care about those things in your design process. Okay, so what is content strategy? I saw this talk that Shelly Bowen gave about a year or so ago and I think it's on Vimeo or yeah. And in this talk she had a slide that described like what she thought content strategy was and the slide said it takes the business objectives and the audience objectives and aligns them across all platforms and channels. So it takes the business objectives and the audience objectives and then aligns them across all the platforms and channels. And I remember seeing this slide when I was seeing the talk and thinking, okay, yeah, I think I understand what that means. And then the more I started thinking about it, I was like, wait a minute, that's what I do. That's like what a designer does. How is that, I don't, okay, now I don't understand what a content strategist does. And the more I've looked into sort of the ways people define it, like a lot of the ways people define content strategy, it sounds a lot like design when you look at it in that way. I think Christina Halverson has what many consider to be sort of the classic definition of what content strategy is. And it's a little more helpful, I think. She says, it's planning for the creation, delivery, and governance of useful, usable content. And so that planning work for that creation, delivery, and governance of useful, usable content. That feels a little bit more discreet to me. I like that. I think that it's, you might think of design as planning for and implementing the interactive experience of usable content. And so they dovetail nicely, but that way of thinking about it felt more discreet to me anyways. Again, like over and over, when I look at the way people describe it though, it sounds like design. Kevin Nichols from Sapient Nitro says we, we being his team at Sapient Nitro, he says we define content strategy as getting the right content to the right user at the right time. And again, I think most great designers, like that's what they're all about. They want to get the right content, the right user at the right time, and do it efficiently and effectively. So one of the ways that I often try to understand roles and disciplines is like I said, to figure out like what does each role care about? What are they there to protect? And so I came up a list of what I think a content strategist cares about, kind of what they're there to protect in a project. And again, this one's one I made up. So if any of you are content strategists, I'm J-Punch on Twitter, tell me the things that I'm missing later or talk to me afterwards because I love learning about this stuff. And I'm very much in process learning this stuff. But here's, here's the stuff that I've kind of come up with that I think content strategists care about. They care about business goals, like what does an organization need? How does, how does the content itself keep the lights on? They care about audience needs. Who are they? What are the scenarios that describe what they're looking for in the content? And when they interact with it and what they're after, message and meaning, things like voice and tone very much in the purview of a content strategist. Relevance, like how relevant is this to those audiences that we've described? The delivery channels, what are the different ways this content is getting out there? Editorial process, how is it made? What's that process look like? And lastly, just sustainability and governance. So who will maintain the content over time and how will it be maintained? Will it be maintained? These are all things that a content strategist cares about. And I realize that many of these things, again, they sound like things a designer should care about too and they should. They're very important things. In the age of device proliferation, the age of responsive design and all the different things that we're trying to design for and take into account in our processes, I think design's being pulled out of being thought of in this like very focused aesthetic kind of a thing. And getting back to the fundamentals of what design is about and it's really about these kinds of things. I've been describing design for a while now as being about purpose and not preference, about priority and not placement, and about systems and not pages. And content strategy is actually a wonderful discipline, an actual discipline to bring into your design process to help keep things focused on those things. Again, like a world where not everything even can exist on the same place on every device through which they're gonna be consuming the content. It's so important to find ways for your process to get centered around what the priority of each thing is as opposed to getting really nitpicky detailed into the placement of everything and getting hyper visual right out of the gate. Now, I rarely do a talk on design where I don't end up using this. This is my way of defining design, my favorite definition of design, which is design is the conscious effort to impose a meaningful order. Victor Popinac said that. And inherent in that definition is this idea of design is about priority, it's about helping people see what's important. So, suffice it to say, that's sort of like the, we'll move on from the what is it thing, but I think design and content strategy can sound really similar when you hear people talking about the high level of like, what are they? They're not the same, they're not twins, but they make really good stepbrothers, they work really well together and they can be a lot of fun together. Okay, so one final way of looking at the distinction is that a content strategist in my mind at least isn't distracted with presentation. And bringing content strategy into your design process can be a way to provide that helpful focus to actually not get too quickly, too distracted with presentation, but actually understand the content that's underneath everything. So while the content strategist looking at business goals and audience needs and focusing on things like message and voice and governance related to the content itself, the designer is then focused on how to visually represent that same message and voice and how to create a sustainable design system for all of it to live in. Again, they just dovetail so nicely. Okay, so enough definitions. So let's talk a little bit about what makes it great, what makes it great for the design process. I think there are sort of three fundamental things, three fundamental ways that you can see content strategies being really hugely helpful within your design process and actually even within your development process if you're more in that camp. So the first is that it can act as a force multiplier. The second is that it can act as a silo buster. And thirdly, and maybe the most important for me lately, is that it can fill in really important details that you just would have missed if you hadn't done the disciplined work of content strategy within your process. So I'm gonna define those a little bit more. So the first, content strategy is a force multiplier. I'm guessing that many of you have worked on projects where your team either feels smaller than the task at hand or especially where the timeline feels way too tight. How many of you have worked on projects where you've sensed a great deal of pressure for design to get to a particular place of approval so that development could actually do all of its work? This is a really, really common pain point within the process. And content strategy actually produces some things that are, whether you call them deliverables or not, produces some tools that can create communication and actually help speed that along, help act as that force multiplier. When that's happening, whether you have a huge team, like with lots of resources to throw at something or small, like even with the huge teams, you run into Brooks law, right? Like nine women can't make a baby in one month. No, there's, you reach a point where you just cannot sort of do any more in parallel. And again, what I've been finding, what we've been finding at Lullabot is some of the basics of content strategy actually give the clarity that the design team and the development team needs to actually begin work in tandem way more easily. So content strategy as a silo buster, this is really noticeable, I think, when you work on larger projects with larger, sometimes multiple teams working in tandem, at Lullabot, we've had the privilege of working on a lot of really large projects. And one of the things that you'll see, the larger the organization, the larger the teams, is the siloing of disciplines. In fact, in many cases, maybe you've found this as well, like often you'll find that separate vendors are being looked to for each discipline. So they're not just different teams, they're different companies coming in with different goals and different requirements lists and everything. And that siloing of disciplines can actually cause a lot of pain in the design process and in the development process. Content strategy can actually provide you with some tools to actually at least bridge the gaps between the silos, if not break them down. It's not a panacea, but it's very helpful in those situations. And the last thing, content strategy can provide designers with details. Like, this is a big one. This is why I think that designers should be taking part in some of the content strategy work. Even if you have a content strategist on your team, I feel like designers actually can get a whole lot out of being a part of producing some of the tools that content strategists produce to help them understand what's underneath anything. In the end, it's the things you learn in the creation of the spreadsheets and the documents that are more valuable than those things themselves often. It's like Winston Churchill famously said, plans are of little importance, but planning is essential. And so much of the work of content strategy, I feel like is this way. Even if the larger team doesn't use the tool a whole lot later down the road, the people who are involved in creating it have an understanding that provides glue within a project. Or another way to think about this is the way Donald Rumsfeld famously put it so eloquently when he said, as we know, there are no knowns. There are things that we know we know. There are also unknown unknowns. That is to say, we know there are some things that we do not know. But there are also unknown unknowns. The ones we don't know, we don't know. And to me, that's actually one of the biggest thing that content strategy gives you within a design process is it gives you a disciplined approach and way to begin uncovering the things that you didn't know you didn't know. And it's hugely helpful. Because, I mean, let's face it, as designers, we're a group of people who likes to think that we can look at something and at first blush, actually pretty quickly figure out a way to make it better. We're problem solvers and the more you do it, the better you get it or at least feeling like you can kinda quickly assess what's going on. And this is a discipline where you have all these people that are doing these unsolicited redesigns. Like the whole idea of this the culture of design is like, I can make that better. I don't need to know very many details at all about this thing. I know how to make that interface better. So if you're a designer, especially if you spend any time in design school, you may be familiar with the Gestalt Principles of the Gestalt Laws. How many of you have at least heard of these? I've actually done other talks where I've spent a whole bunch of time going through these and explaining them. That's not what this talk is gonna do. But these are things like similarity, proximity, closure and so on. These are classic design fundamentals that get taught in design school but they come out of something known as Gestalt Psychology. And Gestalt Psychology is based on this idea, this observation that we often experience things that aren't part of our simple sensations. So like the brain makes stuff up and all of a sudden you're seeing something that's not actually there and your brain kind of put it together. So it came out of, there was this guy by the name of Max Wertheimer. He was on vacation back in 1910. He was on a train ride and it stopped in a little town and he got off to kill some time and went shopping. And he bought a little toy stroboscope in a toy store kind of a place. And a stroboscope was essentially a really primitive movie machine. It was like an advanced flip book. It had a drum that had pictures inside of it like linear pictures that would spin and you would look through and like basically the pictures would end up like creating something kind of like a video experience. And what Max Wertheimer noticed was that his brain was convinced that it was seeing complete movement. Like that it was seeing all the details in between even though they didn't actually exist in there. And he was fascinated with this and it led him into a whole school of psychology that he started and Gestalt Psychology came out of it. But the long and short of it again is that we experience things that aren't part of our simple sensations. The human brain has this innate ability and desire to sort of make things whole. The brain also has this propensity to do this based on our previous experiences. In design that's also known as isomorphism which is this fancy math word but in design it simply means that our brain has a knack and wants to like put things together based on what it's experienced in the past. Now these assumptions and expectations can really cause problems sometimes. You have expectations for what's where and as designers like I said like the more projects we work on the more things that we do the more sites we try to figure out what's going on here. The more users you know personas that we put together the more we can get this sense that we just like we can quickly do this. In fact the drive within business if you're doing this as a client service is to be able to do this faster and faster more efficiently and more efficiently and it can be very easy to begin following patterns and assumptions without the details. So ultimately a discipline like content strategy is just so valuable because it humbles us. The work of a content strategist and I frankly I think the work of a great designer assumes that we don't know everything. That there's a lot more going on than what we could pick up from cursory inspection and the diving into the details is actually really really valuable. So you want a great example of the power of patterns and assumptions and how much we as humans are have this propensity to perceive our reality based on it. Fast forward about 20 years from Max Wertheimer's trip on the vacation train ride to the late 1930s United States. Now this was nearly 10 years after the economic collapse of the Great Depression. There was the stock market crash and then massive layoffs and then there were bank failures by the hundreds. Like this was way more than what we experienced in the mid to late 2000. Like this was intense and Americans were largely very very afraid people. So much so that like you remember FDR's famous inaugural address which happened during this time in which he said the famous line the only thing we have to fear is fear itself. Like even the president of the United States coming in was like the main thing that he wanted to speak to was this palpable fear that was there that gripped people all the time. You have to remember that Americans at this time had been listening to a steady drumbeat of war in Europe. Like as Hitler's army was on the move for 18 days straight in September of 1938 Americans had listened to the radio and got regular updates on the Munich crisis. And again like there was just building a sense like we're not gonna get out of this thing. We're gonna get sucked into this war. And this was also a time when there was a radio in about 80% of American households. And for years now they'd listened to firsthand accounts of disaster after disaster. Everything from the Great Depression and all the bank failures and all those layoffs and stuff like that to like there was actually a huge series through the 1930s of natural disasters. There was everything going on with the war in Europe that they would get daily updates on when they would listen to the radio. There was the Hindenburg disaster which was a big like felt thing for most of the nation who sat in front of their radios every night. But the radio was also their primary daily entertainment. It was in people's houses and it was their escape at the same time as it was their news outlet. So on October 30th, 1938, Orson Welles and his radio theater group wanted to find a way to adapt H.G. Welles famous War of the World's book for radio theater. And so they wrote like a theatrical version of it that read like a play. And they went into like the day before for recording it and read it as a team and Orson Welles was like, this is crap. Like nobody is gonna be into this because nobody is gonna buy the premise that Martians are attacking. And if you can't feel that premise like this is just not going to be that engaging is radio. So he was like, we have to start over. This was a day before they went on the air. So he had this clever idea to make it feel more real and believable by following the patterns that people were used to in news bulletin updates. And so literally hours before the airing he and his team rewrote the entire play and they turned it instead into a choppy series of segments that sounded just like news bulletins complete with screaming people and all kinds of like live sounding stuff. And the actor who played the reporter in it actually spent those hours down in like an archive room listening over and over and over to live radio reports of the Hindenburg disaster to prepare himself for this. Well, many said the most terrifying moment was this point where there was lots of action happening. A reporter who was like freaking out and then suddenly Orson Welles gave the signal to cut and he just left deafening silence over the radio airwaves for what seemed like a long time. People freaked out. Like there's debate now years later about like whether the press way blew it out of proportion like how much because there was like these reports of millions displaced and stuff but people who had flipped stations and who had missed the intro especially because there was this other apparently the most popular thing on that night was this ventriloquist act, which blows it's like ventriloquism on the radio. This is bizarre, but apparently people love that stuff. And so a lot of people had been listening to that and like flipped over to this and they flip stations and they hear these news bulletins. And whoa, man, God, that was, mood. Okay, well, I'm gonna do my best to keep you awake now. So anyways, people like, there was things like people would be looking out their windows and if they saw cars on the road, they would assume everybody's getting out of town and they would get in their car and try to get out of town or they would look out their windows and if they saw no cars on the road, they assumed everybody got out of town and so they would get in their cars and they would get out of town. There was literally mass exodus from many U.S. cities going on. People, a lot of people thought that Orson Welles was gonna go to jail for it, but he's good and he somehow avoided that after a press conference. But anyways, suffice it to say, this is a long story for like patterns are really powerful in the way we think and the ideas that we bring to things. And so let's get practical now and we're gonna talk about how content strategy can help you avoid looking like fools who believe Martians were invading. So how's that for a segue? I'm gonna quickly walk you through some really basics for how you as a designer, or maybe you're not a designer, but how you and your project can begin doing things like content inventories, content audits, content modeling, and then something that we've, at Lullaby we've been calling intent mapping. And if I have time I may touch on two other things so we'll see. So first content inventories. And again, the stuff that I'm about to talk about, really simple stuff. There's none of this that would not be difficult for you to just say, I'm gonna go ahead and start trying that next time. But if you happen to know a content strategist or have interest or ability to like pull one in, do it and work with them and learn from it. But so a content inventory, so way back in 2002, Jeff Veen wrote this article on Adaptive Path. Jeff Veen's now Adobe Creative Suite guy or whatever, but back then he was at Adaptive Path and he wrote this article about the process they were using at the time to redesign websites when they were getting client projects at Adaptive Path. And this article has like a downloadable template spreadsheet in it and it describes the kinds of things that they would capture, that they would inventory when they would start a design process. And they would inventory all the content. Now this was a time when, in the article he talks about how like a back then, like a lot of the sites they were doing this for, like they were redesigning, didn't have a content management system. These were like directories full of HTML files and stuff and so it's an interesting read. It's still very relevant today. If you have not done a content inventory before and you're like, let's try it on our next project, let's start inventorying content, see what we learn and you want just a starting point, like look up this article, very helpful. But the long and short of it is that all that a content inventory is, is a spreadsheet or some other form of documentation that captures the details about each piece of content that makes up a site. And the basics of what a content inventory should capture included in this template spreadsheet, there's like all kinds of other things that you can include but the real basic stuff is in there and it's things like an item ID. This is because like there would be lots of duplicate content that they would end up finding and they would find that things look the same and so if they don't like make, like in many cases they were like making up an ID number for each thing. They would like, this looks like there's 3,000 pieces of content in this site so we better come up with a numerical structure that'll have enough IDs but they would come up with an ID for every piece of content so that later on when they're auditing the content they have a way to tell like these things all actually are duplicates. Item titles, again those can get duplicated but you get a capture at URLs, content type, attributes or metadata, the things that seem to be making up that kind of a content, like these kinds of content seems to have all this author information and this other associated stuff. Who owns it or maintains it? Something that he calls rot in this which I think is sort of getting a little bit more into the auditing side but it's marking content as either redundant, outdated or trivial. And then just other notes like they would do like back then they weren't doing this but now like something you might capture is this piece of content seems to have flash embedded thing in it or capturing things that could end up posing real challenges for a responsive redesign or a great thing to add to your content inventory document. Now in the article, excuse me, Jeff Bean mentions that the larger the site the more they would try to have programmers like automate some of the initial creation of these things but he says that the content inventory is a decidedly human task. Now audits especially are decidedly human but even the inventory it's back to that church hill like plans are of little importance but planning is essential and just the act of actually looking over reviewing, reading real pieces of content figuring out where the discrepancies are what seems to have a completely different voice than a different section of the content can be really helpful. And a lot of cases I realize like you might not be able to spend four days going through all of the pieces of content in a site that you're redesigning. If you can't there are tools now like there's a company called Content Insight that has a tool called cat C-A-T that you can look up that it will automate the initial creation of a spreadsheet like this it'll basically crawl sites and create a spreadsheet capturing these kinds of things. It can at least be a great starting point if you have a giant project where it's just too large you're just not gonna be able to do it or you need to try to divvy it up. Tools like that can give you can create a good like initial like document that captures everything and then what you can do is actually just pick random sample sets and say I'm gonna have a person just go through all these pieces and see what we learn. We can't do everything but we're gonna do some. You know, like at Lullabot we worked on marthasteward.com and I remember that was, there was like over a million recipe nodes and stuff. There's just no way you're gonna like have eight person go through and read every single one of them. But you can do sample sets. It's still a great, great exercise. One point that I wanna mention is to remember that if you're for example redesigning a website don't just inventory the content that's in the site currently that you're being asked to redesign. Ask about all the other channels through which they distribute content. You know, ask about their email newsletters. Ask about their microsites that they have that were set up for particular campaigns or tentpole events or these kinds of things. A lot of these things can actually be really helpful and sometimes you can find a lot of value actually in things that they weren't even thinking as part of their site but maybe actually way more relevant to the users that you're designing for. This sounds again like mind numbingly detailed and tedious as Jeff Veen's article title suggested but what does it get you? Let's talk about that. It gets you two things I think aside from the sense of satisfaction from knowing that you actually have a clear picture of all the content that an organization is currently producing. It gets you ready for a content audit and I'll talk in a minute about what those are and it gets you ready for content modeling and I'll also explain what that is. And just as an added bonus you may discover amazing content that's not currently really being leveraged by a site. Now this is a true story like there's a project I was working on where through asking questions about the other content that this organization produces we discovered a couple abandoned microsites that had HD videos of celebrities like Jamie Foxx and Woody Allen talking about the amazing impact of this organization. Now the site we were being asked to design completely existed to communicate the impact of the organization. It was like, how is this stuff not even a part of the current site? So I'm not gonna try to sell you like that every time you do a content inventory you're gonna discover those kinds of gems but it can happen like it's worth asking about where else are you producing content and what kind of content is it and where is it living now? You can find gems sometimes. Okay so a content inventory gets you ready for content audit. What is that? What's the difference between an inventory and an audit? I get asked that a lot. The simple way to look at it is that an inventory is quantitative and an audit is qualitative. So meaning an inventory will tell you things like how many of a particular type of content you have to work with. While an audit is there it's where you begin to evaluate all that content and assess the value or quality of it in various ways. So there are lots of ways that you can audit content. My co-worker Jeff Eaton who I pretty, he always seems to be speaking at DrupalCon and all kinds of things. Pretty sure he's speaking here I don't know if he's already spoken but he hosts a podcast and it's called Insert Content Here. If you go to lullabot.com slash blog click on podcast you'll find it. There is an episode of his podcast where he interviews Misty Weaver and it's all about content inventories and audits mostly about audits. And Misty Weaver has awesome insights into just really practical and useful ways that you can audit content in your process. I highly encourage you to go listen to that because I'm not gonna have time to go on into all the ideas that she has in that hour long podcast. But check that out. Again the podcast is called Insert Content Here. But some really basic things that you can always audit content for like once you have an inventory of content it is going through these pieces of content asking things like does it support a business goal? Does it aid a user need? Does it inspire action? Does it pose a technical challenge for a responsive redesign for example? Finding that content that does those first three really well highlights the content that you wanna really celebrate in your design process. Okay so lastly the content inventory gets you ready for content modeling. How many of you have ever like produced a content model document of some sort in your design process? Okay I find when I've given this talk at a couple design conferences and it feels like in Drupal we actually understand a content model in a different ways. One of the really wonderful things about Drupal historically is for years it's actually approached content as modeled content and understood the idea of related types of content. So in the content model we basically are capturing the following things. We're capturing the types of content your project needs. We're capturing the discrete attributes that make up each content type and then the relationships between them. There may be more things than that that you wanna capture but it's core like if you've captured those things you're producing a content model. And the content inventory again gives us the raw materials to do this. We can basically take a content inventory and begin looking for and identifying patterns. What are, to find out what are the truly unique types of content. When you have a whole array of content that seems to have the exact same attributes list all these pieces of content you may have stumbled onto a unique type of content and begin to use that information that's there in your content inventory. A lot of times when you do design projects on Drupal sites like the temptation is well it's a Drupal site. We can just go in and look at the content types that are set up and see what fields are on them and stuff and we know the content model. But in a lot of cases the way things get technically implemented isn't always the best way to model content. And a lot of times I've worked on projects you know, redesigned kinds of projects where if you purely begin thinking about your content only by the way the data model was set up in Drupal for example, you may miss actually some of the insights that you get if you kind of like divorce yourself from that for a little bit and start looking more at a content inventory and figuring out okay what are the actual natural ways that this content should get broken down into types and what are the relationships. One of the things that we found at Lullabot that can be really helpful as you model the content for a site is to not just identify the types of content but to identify the types of types. And there's sort of, there's a handful that we've used but there's sort of three that seem to always be there in terms of the types of types of content that we identify when we're modeling. And those are assets, structure and presentation types. Now assets are things like articles on a news site or recipes on marthastewart.com and they're the premium stuff that might get distributed through apps or other places outside the website. They're often like the core business product of the site that you're working on. And they're things like editorial or user content that should be usable across all platforms and devices when they have little or no presentational content or markup that's a part of them. They're usually pretty pure. Structural content types are used to basically group and organize assets to retrieve collections of assets for other platforms or for devices. Organize things like MSNBC.com, I remember that had this topics content type that was actually sort of actually a content type because it had some curation, had content that got written about the topic but it really broadly existed to serve the purpose of providing a collection for the content assets that were made up that topic. And so that's basically the idea of structural types. And then presentational content types, they exist purely to serve a current design or presentational need. So we've all worked on projects where people are like, we want a big homepage hero carousel and we wanna be able to promote all the things and promote all kinds of things. And it's like, well, is it gonna be pulling this kind of content in? It's like, well, it's not pulling in exactly what we capture in that kind of content. And it's not pulling in exactly, well, sometimes it will be but sometimes it's this and they want lots of control. And what can happen, especially on Drupal projects is like, well, we'll just add another field to these content types and we'll make it all work. And like, oh, we'll add this other field in case they wanna format it this way on some of the promos and this way on the other promos. And in the end, you can actually end up with these premium assets getting really crafty over time. And then you also have a situation where like you end up with a redesign and it's like, we don't even actually want to do that kind of a promotional thing anymore. And it's like, well, now we've got all these fields all over these assets that are like, should we just dump all this content? So just from a development side, that's sort of a picture of how helpful it can be to begin thinking about presentational content types from a design standpoint, even if you have no control over that side of things, it can be helpful to identify where that's happening because usually when you have presentational content, like purely presentational content types, you have opportunities for asking how well is this serving the need. It's sort of fair game for real radical rethinking and redesign processes and things like that. So again, the reason why it can be really helpful to understand the types of types is both for the development team and for the design team to both understand sort of, what's the core business units? What's the real content here? What exists purely because of the way they've been presenting their content? What exists purely to serve like the IA and the structure and those kinds of things and sort of have that clarity of mind going into a design process? Now, one of the neat things is with all of these content strategy deliverable, I don't know if you would call any of these, like the deliverable's the website. That's what we make for people, we make websites. Like any of these things are more like process updates or communication tools, but whatever you wanna call these things that a content strategist would make for you, they're really lightweight tools or things that are very easy to iterate on and work together on as a team. In many cases, like things like the content model at Lullaby, like they start out at least just as like I use IA writer a lot, just to mark down files, just bulleted lists and things like that. But even if it's a spreadsheet, like in Google Spreadsheets or something like that, it's just really easy things to start out on and you don't have to get it right right out of the gate. They're great things to produce something and say, what do you guys think about this? And they can create a conversation point between the development team and the design team together. And like I said, one of the neat things about the content model is if the developers and the designers work on it together and you can have a client and a developer and a designer who are all on the same page about this thing, there's a lot of development work that can actually start and work off of the content model and actually designers can work off the content model as well. The content model also provides an awesome opportunity to begin discovering and assigning priority. I found it really helpful to have clients help prioritize both the types of content and all the attributes that make up each and those can usually lead to really interesting conversations. You can do something as simple as taking your content model and putting all the types onto an index card and putting all the attributes onto an index card and just as a team, like start card sorting, start making people put them in order, top down. It can be really insightful, the things you learn about what's really important, what's not. In the end, if you're producing a responsive design, understanding that priority is gonna lead to understanding the priority within the components that make up the site, that make up every single screen that you're designing and it's extremely helpful. It provides you the designer with that freedom to then translate that hierarchy visually and not be just dictated to all the time about placement. You're there to actually see if you're actually achieving priority and you've all agreed on the priority that you're trying to achieve. Now, if you have multiple personas that you've created, that describe the audiences maybe that you're designing for, you can use those same index cards and sort them again for each persona. Like bring that as the metric for how you're measuring what's important and what's not. And this is something that we've been calling intent mapping where we basically take one of the scenarios that a persona would have and for that persona, sort of map the importance of each type of content or each attribute for the types of content that we're saying is for that persona. What are they really caring about? It can be a really helpful exercise. So quickly here, I'm gonna try to talk about two other things. These are a little bit less content strategy, classic kind of deliverables. Maybe a little bit more on the design, IA side, but sort of having a content inventory, having audited content, having produced a content model, you have the ability to produce a similar thing that we've been calling a presentation model that begins to break down your design process actually into the things that you're actually gonna be designing for. So a presentation model, what it captures is the unique page types that are gonna make up the site, and the content model can be really helpful for beginning to identify that, sort of look at all the discrete content type, the asset sets and figure out, are there any of these that like, a piece of that content would exist and it wouldn't have its own URL? Which are the, like what are the components that would make up that page type? And then do that across all the different things that you see within the content model. Look at the structural types, ask which ones are gonna have listings, which ones would have a structural landing pages, that kind of thing. And start just documenting, simple text documents like, what are the components we think would make up that kind of a page type? Look, and just like you can look at the inventory to produce the content type, or the content model by looking for the patterns, like start looking at the patterns you're seeing. You can begin to identify the really truly unique page types that you need to design for and avoid situations where you're doing like, designing for five different screens that are all essentially the same list of components, the same things. And again, the components that you, the list of components that you have for each page type within a presentation model, hugely, hugely helpful to have the client, have the whole team work together to prioritize the component list. Before you're actually doing like visually, wireframing, drawing pictures of what this stuff would look like, where the components would go on different screen sizes, have people have already agreed upon what the ordered list is of importance, most important to least important of every component that's gonna be on the screen. If you have that tool in your toolbox as a designer in a responsive design process, it can be enormously helpful because you can get to where it's really about purpose and not preference and about priority and not placement. Your discussions with your clients, with your stakeholders can be around, are we actually achieving the order we said? Or if you're asking me to move this up there and over there, like, is that because the order that we'd agreed on isn't actually the order? There are a lot of times where it's like you start producing visuals and you see things that maybe you didn't. It doesn't make the documents, the presentation model or that kind of stuff unvaluable. It actually makes it a great tool because you can have those discussions of, why did we think that was more important or why do we think it's better now that it's over here? Is it moving it up in the hierarchy? Those kinds of things. And lastly, one of my coworkers, Jared Bittner, recently wrote this article on littlebot.com called Building a Development Matrix. He's one of our project managers. And our project managers have started creating this thing that when they first told me about it, I was like, wait, that's a presentation model in the form of a spreadsheet. This is a presentation model for people who don't hate spreadsheets. It's basically takes that exact same approach and says, like, what are all the components that have to go into all the unique page types that are gonna be a part of this design system? And let's figure out where are the overlaps and just so we have a listing of all the actual components that have to be built in a project. And then they can basically track the progress of a project. Like how far are we from being done with development by what are the components that are already done? What are the components that aren't done? Like, we're so far away from this particular template or screen being done and that's because this whole set of components is not yet done and this is the problems that we're seeing and this is why that throws off our timeline. It's been a really helpful thing for our project managers. So the presentation model actually can serve as a great starting point for building that development matrix because at least like the quick capturing before you even have visual designs lets them start to break down what are these things? What are they made up of? What are the functionality that's gonna be required to produce these components? And again, development can begin work without even having an actual visual design artifact of any kind. So it can be really helpful stuff. Okay, so I've walked you through the basics of creating a content inventory of some audits. Again, listen to that podcast because there's some awesome ideas for ways to audit content in that. How to model content, how to do intent mapping with that and even how to do presentation models out of that to sort of start the actual design work. I just wanna say again, there are a lot of amazing content strategists out there. Hopefully if any of this stuff feels really new to you, like just start following some great content strategists and learning from them or hire one to get them to be part of your project. I hope this wets your appetite a little bit. If you already know a bunch of content strategy, I don't know why in the world you were in this room but hopefully I didn't just bore you entirely. So thanks a lot. I'll be here. I think I have time for a couple questions but I'll be here the rest of DrupalCon too. So find me or come to the Lullabot Party Wednesday night and ask questions too. Thanks. I'm not sure.