Lessons

Lesson Info

Content Basics

So, you know, you can't talk about creating a website without talking a bit about content. You know, everyone says, "Content is king." There's certainly a lot of truth to that thinking because, so many sites, are you really gonna go to New York Times because of their navigation style? You know, you're going there because of their stories, their content. I really like this quote by Jeffrey Zeldman. "Content precedes design. "Design in the absence of content is not design, "it's decoration." You know, and I think we really have to just kind of consider this. And so although this isn't gonna be about content strategy, I just wanted to quickly review some basic content types, and then, kind of, hand it over to Jesse, where he's gonna talk even a little bit more about that. So, some content types. Let's talk about them. Original content, right? These are gonna be the articles, blog posts, videos, contests, promotions, all the original content. Gonna be a little more expensive to create, but...

probably, and hopefully, the most relevant to your user. So, something to consider, and again, as a designer, the reason why you wanna be aware of this stuff is because you need to understand, is there a home for it, right? Like, what is it that we're designing for? I remember, I was working on a project and they had spent all this money to kind of figure out the name of the product. And it was supposed to be kind of like a content aggregation site for kids. And they had spent all this time kind of, going, doing design comps, we had all these kind of clever little gadgets and gizmos, and we realized the problem we were having is that we had no idea what any of the content was supposed to be in these modules. So that kind of became an afterthought, and as a result, it made it really impossible to finish, because there was not that conversation. There was no content strategy, there was no kind of idea of who's gonna own what, and where this content is gonna come from. Another type of content is gonna be aggregated or partner content. So this is gonna be something that might be editorially-curated, or it could be pulled in automatically. Ideally, it's pretty relevant. If they're gonna be kind of a partner, then, hopefully it's gonna be very relevant to your users. But, there is a risk that it's not always. It's not your content, so that's something that you have to kind of be aware of. You have co-created content. I think of this as like a guest blogger or guest photographer. So they're very much kind of trying to be within the voice but adding something else. A lot of times you're gonna wanna have co-created content because it lightens the load of the kind of internal team, and it also just makes it... You know, you're able to kind of leverage some of the brand equity of that co-creator, right, because they're kind of having followers and stuff like that. So this one is kind of the most interesting to me is this idea of living data, you know. The objects in our world become smarter, so do the interfaces that support them. We have these visualizations of real-time data that you can make a complete dashboard out of. Or you could have these, like, smaller, little features that are constantly responding to experiences. This is from Mashable, and this is kind of a velocity graph that you've probably seen, where, as it's getting shared, it's showing how popular it's getting. Just a nice little touch that really kind of adds this extra level of information. You have user-generated content. And so this is content that the users will create themselves, right? And this can be kind of an effective way for sites to generate content. I remember there was a phase, this was really during the Web 2.0 phase, where that was like the silver bullet answer to everything, like, we're just gonna have UGC as part of it, right? We had t-shirts that said UGC. It's true. I'm sure. And so, you have to really make sure that moderation is part of this. I remember once, another creative director and I, Fred, we were going in, and checking out this new tool that a kids, kind of, a kids site was working on, and they were very proud of the tool. And so, they were basically like, look, we don't need to moderate because there's nothing custom that they can create. There's no way that they can make something that's inappropriate. You can't type anything, it's all like, kind of, pre-selected, almost like color-form pieces that they're just gonna be able to put, and, like, publish. And so within 10 seconds, Fred and I, we took that carrot, we enlarged the carrot, and we just moved it to a different spot. And very quickly, we made something that was completely inappropriate, and something that couldn't be moderated within their system. So, you always have to kind of balance that. It's not always the silver bullet. Then you're gonna have licensed content, right. Content that you're gonna get from a third-party publisher. A lot of time you might see, like, medical sites, or something like that, where they basically are pulling in this content from some other source. So it's vetted, it might not have the tone, but it's gonna be a quick way to populate content within your site. Social media content. I think that's always one of those crazy things where it sounds easy, and you look at people that do that all the time, and you're like, "Man, that seems easy." And then when you start to do it yourself, you're like, "Wow, this takes a really long time." So, something that's just really worth understanding. What is kind of the social media expectation? Do they have a team to kind of create this content? Because it's all the time, right. And ideally, it's reactive, it's responding to people, so they have to make sure that there's someone that's capable of doing that. Legal content. Oh, man, legal content is one of those things that you always kind of forget, right. And you're like, oh, we have our final thing here. Oh, we have this privacy policy, and all that kind of stuff, and all of a sudden, you're realizing that you can't launch with it because you don't have the legal content that's ready to go. You have to get like this lawyer content that's in place. So that's something that is really worth explaining, and, kind of, getting your clients to think up-front. Don't fool yourself, this is actually the same content from social media. It's on the wrong slide, so... Just don't get confused. Legally he has to say that. Legally I have to say that. Metadata content. This is gonna be kind of the content that describes the content, right. So you have a content management system, here it is, you have all this information that's gonna help describe the content. Not only is this good for just search engines, but it's also going to be good for accessibility. There's all kinds of reasons to put really valuable metadata into your content management system. And something that often gets overlooked, or doesn't have a proper strategy. We're gonna look at it in the following, sorry, within this segment. This is critical. Like, it's how you fracture your content. Those hooks you put in the content. That's how your content's gonna be responsive. So this stuff is critical. Exactly. Yeah. And the last one is legacy content, right. So legacy content is the stuff that already exists but needs to be accounted for. And if you're, kind of, taking something that exists, and you're moving it over, oh man, this is where you really need a content strategist. Because there's gonna be so much that you're gonna wanna walk through with your client. Understand what should you keep, what should you edit, what should you, just, totally remove. It's quite a process and needs to be done with kind of level of thoroughness to make sure that all the content is either in place, or, let's just kind of clean it up, and keep it simple. But sometimes, as you guys are pushing the limits, some of that legacy content is not going to go into your big, beautiful designs. For example, you might have an old article that has image sizes that are really small. And now your new article template is using these big giant images, but the articles, they're so old, that you're not gonna be able to get those images again. So you might have to create another template that's just kind of supporting all this legacy stuff. So you gotta make sure that you're kind of talking through what the expectations are for that. So, content strategy, just really quick, as we move beyond just content types, is really, "The practice of planning for the creation, "delivery, and governance of content." This is the quote by Kristina Halvorson, who's the CEO and Founder of Brain Traffic. And it's really kind of a specialty of theirs. So I just wanna kinda go through what are some of the questions that you should ask when it comes to content creation? What content needs to be created and why? What content do your users actually want, right? That's a really big one. Do you have existing content that you may want to reuse or reform? How is that content gonna be structured, which is something that Jesse's gonna dive into. Is the content right for the audience? Will the users actually create their own content or UGC? Again, that's another thing. There's nothing worse than a big, giant platform where users are trying to create content, and it's empty. It's, like, really awful. What are the required formats and specifications? You know, just, file types, sizes, things like that. And, has a voice and tone been established for this content? Is there an editorial voice on that? Again, something that needs to be worked out. Maybe that's an opportunity for you to kinda help establish that. Likely that's gonna fall onto someone else that can really help do that, and establish that voice and tone. But something that's really worth talking through. One of the things that we'll do is, we'll kind of consider adding a client content sprint right in between. So we'll actually stop doing our sprints, and we'll just kind of pause for a moment, and allow our clients to catch up. Now that they've had a couple sprints, they have an idea of what's happening, we don't quite have final content, we allow them, we take a break, so we're not burning through hours, and we allow them to kind of catch up for a moment, so that way, they can generate more stuff, and then we can kind of keep moving forward with the sprints. As opposed to just, like, keep burning through sprints, knowing that a lot of stuff is going to change because we still don't have that content. Becomes like an honesty check for everyone. Content delivery. Who will review the content, approve, and upload the content, right? What is that workflow? Talk about that with them. That's a really important thing. There's gonna be some expectations about that, and you just wanna make sure there's someone on the team that can handle that. Do you need a different workflow for different content types? Images versus text, et cetera, et cetera. Is there a staging environment to view the content on the site before it goes live? There should be. (laughs) And, does the content, again, need to be moderated? And the big question... The big question, it's really big, there it is. See, it is the big question, right? Big type, big question. Who's responsibility is it to populate the website with content? You might be thinking it's theirs. It's their stuff, it's their site, they have to do it. They are probably thinking it's you. I paid a lot of money for this. Why aren't they doing it? I'm just gonna send all this stuff in an email, and they're gonna figure it out. Have those conversations about that. And the last one, just talk about content governance, right. So who is responsible for maintaining that voice? Is there an editorial calendar to identify when content should be updated? Who is responsible for the various types of content? You might have different from different groups, right? Do you have... Does the client have the right people in place to maintain it? This is a living organism, so you have to make sure that they have the right people in place to continue that, and there's a lot of stories that end up happening, where it's not the case. Can the client realistic keep up with the schedule, right? That's always a big question mark. It's just like, you've come up with this best idea, we're gonna do, like, three blogs a week, and they're gonna do a new article, and all this stuff. And they're like, "Ooof!" After the first month, all of a sudden, you're like, "Whoa, nothing's being updated." And it's because it was too aggressive, they couldn't actually maintain it. And then, what data should you be collecting and analyzing to make that content and recommendations moving forward? I think that's the exciting thing about content is it's... Everything is getting smarter, so we can kind of, potentially, create these more adaptive experiences that are responding to people's preferences, to locations, to context. So, we you have the opportunity to shift content and the experience based on a number of different factors. Be moving on. Yeah, it's a seamless change. So, those last few slides, again, Andy introduced them as the territory of the content strategist. Some projects may not have dedicated strategists on the team. So, that's why I think it's really helpful to expose you, as younger designers, entering into this realm, into again, into some of the vocabulary. Same way we're introducing you to PM vocabulary, same way we're introducing you to developer vocabulary. We want you to make sure that content is to be respected, and there are rules, but a lot of those questions, again, are gonna fall outside your own wheelhouse as the designer. But they are conversations that are happening, so it's important that you're aware of them. So where does all of this stuff go? All those content types, all that governance, all that ownership, all those URLs, where do we put it all? It's fairly complicated. Luckily, there are some tried and true deliverables that are in place, and one of those is a traditional content inventory. So a traditional content inventory is a document that catalogs all the major sections of the project, all the content types that Andy discussed, defines the structure, the metadata, and assigns authorship, governance, as well as tells me sort of, how large or small media types are. And so, it looks like this. It is like the prettiest deliverable in the world. This is traditional content inventory. I have learned to love spreadsheets as a designer, because it takes all the guesswork out of it, and allows me to do that sort of, that really passionate design stuff. Once I understand that there's a structure in place, once I understand that there are limitations and boundaries, I get to do my job. So, we don't have to... We're not responsible for all these buckets. But, some of these buckets are going to include image dimensions. We need to know that. Or we may be asked to contribute those. Either way, parts of this inventory are very much our business, while other parts of it are not. So, "The first step in our responsive design workflow "is to list only the things that need to be on the page "whether or not they exist." So this quote is from Stephen Hay, again, a big inspiration towards the original format of this workshop, which was focused solely on workflow. Like, how do we go from nothing, to conversation, to website? Like, how does that happen predictably? And Stephen Hay wrote, literally, another person that wrote the book on it. So there's something simpler than that spreadsheet format. But it's still the process of inventory. It's still the process of respecting and looking at the structure of content. But it's actually... It's kind of abstract to talk about. Or, honestly, kind of boring to look at. But, if we add a picture, it gets a lot cooler a lot faster. So, we're gonna take an existing product. This is a website that we'll look at in a following session. This is BoxesAndArrows.com, a well-respected UX magazine online. We were brought in to redesign this website. On the left, I just want to show you the content inventory for this view. So, here's the screen, but here's what's really going on here. There's a header. That's my organism. Branding, search, and menu, these are molecules and my atoms. Article, that's that big piece of real estate in the center. I'm dismantling this website, and giving it labels, and form, and structure. Again, some of this may be intuitive to you, we may take this granted, but we need to get it into a format where everybody looks at it, and goes, "Yes, I see that, too." "Yes, I see that, too." It's about this collective understanding. And it's really important, like Andy said, I promise we're gonna get to visual stuff tomorrow. I promise. But today, we live in the world of text and words. So again, we looked at this earlier. As a teacher, I want a list of current exhibitions so that I can plan a field trip. Again, the idea of epics and user stories. We're gonna start here, because we don't have a picture. But we're gonna start from this story, and create a content inventory based on this. So, here's the content inventory that I came up with as I visualized the page this user would need in my mind's eye around this story. I knew I would need a header. Some of these things are gonna be globals, things you kind of need in any website. But it's important to get that stuff down on the list, just so, again, we get consensus, and sign-off, and check marks from everybody involved. I have certain notes about some of things that I wanna do off Canvas, Elements. And I have a description around each organism in my page. Just, again, to gain clarity across the team. What I'm really interested in is this new piece of content. This exhibition. What is an exhibition? And this is gonna be informed by my understanding of an exhibition, as well as the current, like, market offerings. What are other museums doing? What are other people doing? And how would I organize and describe an exhibition? But also, taking from the user story, you can see we've included buying tickets, and a sub note, I need to provide special pricing for groups. So I'm giving myself instruction based on the user story, and illustrating a view that solves that user problem. And again, this isn't a Google Doc. This is collaborative. All the team members are invited to these. This is a set of experiments, and this is an organic process. You're there, the client comes in, adds notes, the developer comes in and adds notes, you, as the designer, contributing to it. And again, it's an evolving process. And eventually, what you come up with, is the structure and the shape of your content. Again... Go ahead, sure. I've got a question. What it be more, like, clear, if it's presented as a wire frame? We'll be getting into that... We'll be... Yes. It depends on your team, and how they can contribute. A lot of clients can't contribute to wire frames. So, in the whole product documentation, this thing would exist with a wire frame just for different part of the team? Yeah, it depends on your team strengths. Some clients do like to work in wire frame. And so, we want to show you all the pieces of this process. And it depends on your team, and your client, what comes before what. We, naturally, start in text, just because that's where the stories are coming from. And we know all of our clients can contribute to it. But you could easily... It serves the same purpose as a wire frame, and resolution, and in functionality, yeah. One of the key things, though, is even with your wire frames, it's really important to try to use real content as much as possible. So if anything, you can use this as a starting point to capture that, right, so you know what to put into your wire frames. And it feels like, you know, you will have more, like, requirements, maybe more limitations in the wire frame form. So how much text you can put in some section, for example. Or maybe it is too much of limitation. It's more about the speed, I think, with which you can make edits, and think through this. For me, text-based deliverables and exercises, they're like thinking. They're really fast for me to do. And again, they're conversational, just like chat, I can have them in words, and so there's no immediate need to abstract that out. But I totally see the understanding, and yes, they serve the same purpose. We're trying to get a group consensus, we're trying not to make something pretty, but something that denotes structure. Does that sufficiently answer your question? Yeah. Cool, cool. So the bulleted list, again, really easy format. Later on, we'll add numbers to these, but at this point, we're more interested in the nesting relationship of these objects. So again, this version of a content inventory is not meant to replace the traditional content inventory. That spreadsheet, we need it. Those bulleted lists are for us. "We're simply borrowing the idea of a content inventory, and using it as a starting point for design." So, we need a responsive strategy, and this is helping us to begin thinking in a modular way. So, next up, we'll quickly review some design in text exercises. Design in text is an old idea that's having a comeback when it comes to responsive design. Plain text is the underlying content stream which all formatting's applied. Within HTML, I put all of my wrapping brackets around, just, plain text. So, depending on your team members, again, some will be literal, and some will be visual. Everyone can edit a text document. Everybody can contribute to the shape of sample content. So again, plain text is seeded by our simplified content inventories. They allow us to capture ideas immediately and make changes. And all teams can contribute. So again, it comes down to structure and limitation. So here's what I'm talking about when I'm talking about a plain text exercise. This is an exhibition. In content. This is my introduction content, my title, my categories, my functionality, and my navigation. The dates of the exhibition. So these aren't labels anymore, this is the actual content. And we don't worry about images yet. Images, video, all these things are secondary. Graphics, all that stuff is secondary. We are talking baseline, most-accessible, text-based content. So, you can participate in this. And again, I feel like a lot of importance decisions are made here, that are gonna greatly-influence things that I'm gonna be doing shortly, when I get into markup, and get into wire frames, and eventually visual design. So, we did this content inventory piece, we expanded that out, fleshed out piece of content, sample content, got to see how big or small this content module's parts are. And now we're gonna shrink it down one more time, and come up with some naming conventions around these things. 'Cause again, it's the same thing that we were talking about with user goals, and then beginning to group user goals together. So we've done a series of these exercises. We've done a plain text exercise for all of the unique views and content types in our website. We're beginning to notice that there are global elements and, sort of persistent elements that are repeating from page-to-page or section-to-section. That's when we do something that we call a component inventory. So a component inventory, we're gonna concentrate, again, on naming convention and grouping strategies, and we're actually gonna come up with the language and the words that I'm gonna be using for the lifecycle of the product. So, hierarchies begin to emerge. Again, you can see this is informed, and looks a lot like our simplified content inventory. But again, I'm looking at naming objects. When I'm inside an exhibition, everything inherits that exhibition namespace. And I begin saying, "This is the header, "and this is unique to the exhibition." Again, this organizing structure is the same structure that personally I use in Photoshop when I'm creating layers. It's the same naming convention that I use when I'm writing HTML, and I'm in markup. If we use the same names, and the same labels on things, it's a lot harder for us to lose track of each other. And this is gonna come into play more when, say, Andy's gonna talk about in a later segment, outputting a PSD from a graphics file, generating markup, as long as those names are being shared across files, we don't have to have subsequent follow-up conversations to confirm what one element is, and how it's different from another. So again, if it seems like work, it's because it is a little bit of work. Like, there is discipline here. We will get to play with color, I promise. But, a lot of this structure, and a lot of this, sort of, organization, again, is... This is the low-res version of our design system, and it's starting to happen at this level. And again, I begin to note the difference between a global, which is something that exists throughout the website, and a component, which is something that's specific to a view. And again, very similar convention as far as nesting, and grouping. So... Yeah. So this document is very simple. Again, it's part of the process, and helps unify the various segments across the team. So things to remember are content inventories for design are much simpler than traditional content inventories by content strategists. They're helping us pre-visualize stuff, and again, get sign-off from the client, get sign-off from the developer, everybody agrees, we can move forward with a shared understanding. Plain text exercises blow out specific pieces of content. They tell me how many words make up a sufficient exhibition. How many characters can I have in a title of an exhibition? A lot of these little fields, again, are gonna be... These are key elements that influence my design process, 'cause I wanna know how large a font I can use in my headlines, and that's gonna be dictated by how long these exhibition title names are. And then component inventories is this idea we've taken the content inventory structure, we've expanded it, and then we've contracted back, again, and we've begun to pick names for everything, and again, got sign-off from everybody on the team. That way the deliverables that flow in and out of both design and development share a lot of the same language.