 Hi everybody. Thanks for joining us. I'm not actually sure if our tech is here yet to start the recording and I know that the people will continue to come in for a couple of minutes. So I would like to get a sense of who's in the room right now. How many people would describe what you primarily do as content strategy? All right. User experience? Great. Managers? Cool. Front-end developers? Oh. You do a lot of things, don't you? Awesome. Any back-end developers? So, yeah. At some point we're just going to get rolling. I don't really know what to do about the technical stuff. But the first part of this isn't going to be substantial. So let's just introduce ourselves. You've come to Student Counselor Advocate, the many hats of content strategists. My name is Brett Meyer. I'm a strategist with Think Shout. I've been building websites since 1996. So I've gone through all of the phases that Dries talked about in his keynote yesterday. For the past eight years I've been focusing primarily on nonprofits after getting out of doing development work for the financial sector. And? So that's the other Brett. I'm Brett Heckman. I'm the user experience lead at Think Shout. I've been working in web development for about 10 years now, mostly for nonprofit organizations. We're both from Think Shout. This is probably clear already. Think Shout's focus really is on serving mission-driven nonprofit organizations. And so, what is this talk all about? Anyway, did any of you go see Sam Richard and Sam Boyer's session yesterday on content deliverables? So they did a great job laying out all of the deliverables that you will end up giving to a client at some point. Our session is going to focus more on how you actually gather the information you need to create a lot of those deliverables. So we like to think about our clients as partners. And what we mean by that, we've done a lot of work comparing our Think Shout to other organizations and how they do the discovery process at those organizations. And more than once, I've seen the claim that during the discovery process, this development organization is going to learn absolutely everything about their client. They're going to learn the industry. They're going to nail what the client does. I personally think that's bullshit. Not to put too fine a point on it. It's a little arrogant. It's a little condescending to think that you're going to come in for a couple of weeks or a couple of months and figure out everything that this client is about. That's why we think about our clients as partners. We, in this room, we are the user experience experts. We're the digital strategy experts. We are the back end where the development experts. We are not necessarily experts and probably will not become expert in the work that our client does. They're going to be the experts about how their departments break down about what their organizational goals, about the products that they're selling. And by becoming partners with our clients, we lay the groundwork for making sure that as we go through the development process, we're going to iteratively get to the best product that we can together. It's also important to develop a common language or a common understanding of the language that your client speaks. Almost every client that we work with, and nonprofits are notorious for this, have an internal language that they speak to each other. They get it. They know all of the acronyms. And a big part of what we do when we're working with them is tell them that they shouldn't be using acronyms with their end users. But as you learn about your client through the discovery process and talking with them, you will pick up on what they're actually, what they mean when they say something like CDA. What does that mean? I don't know until you talk to them. And once you know their internal language, once you understand their internal dynamics, when you need to justify a feature or cutting a feature, if it comes to that, by speaking to them in their own internal language, you will prove to them that you have been listening, that you understand what they're all about, and that you really care about the work that they're trying to do. It gives you credibility when you can speak the language that your clients speak. And it's also important to find the internal advocates. As we've mentioned, we do a lot of work with nonprofit clients. Nonprofits have departments. The bigger the nonprofit, the more likely those departments are broken into silos. So communications probably wants to get names for their list. Program is going to want volunteers or people to sign up for events. Development probably wants to cultivate donors. I firmly believe that if the development department was in charge, every nonprofit homepage would be a giant donate button. So we want to avoid that. And to do that, you want to find the internal champions in the organization that you can speak to. The people who really understand what you're trying to do and the folks who can cut across those departmental barriers to take the language that you give them and turn it into their internal language to convince the internal stakeholders that may not agree with us that what we're trying to do is the best direction. So the more internal champions you can find, the better or the easier it's going to be for you to convince them that the structures that you are putting in place, the functionality that you're building, is going to be appropriate for them. So we're going to begin talking about our process, and really this is focused on, as Brett said, the information gathering process that we do. And this is even to be even more precise, this is when we have the opportunity to get on site and work with our clients for a number of days in person, which I think Brett and I can both agree is what we prefer. So project kicks off. You've probably had some internal meetings to discuss what was learned during the sales process. You've read through RFPs. You've read through and or maybe helped develop your proposal. So you have a loose idea, a general idea of what this project is that you're embarking on. But we think it's incredibly important to sort of get rid of all assumptions that you're going to make. We've all been doing this for some number of years. And you pick up on some key words that you find in an RFP or a proposal, and you think that you've got the problem solved. At ThinkShout we do a lot of event registration. So when we see that in an RFP, in a lot of ways we have the technical expertise to solve that, and we can feel very confident about that. But there's still quite a bit that we need to learn in terms of that organization's unique needs in that area. So what are the goals or what are the objectives with a lot of these exercises that we're going to talk through? The obvious ones are gathering requirements, keeping an eye out for potential risks in the project, getting a really good understanding of high level organizational goals and target audiences. But the less obvious, but maybe equally important objectives in our discovery process is really to learn about the internal dynamics of the client, our partner, the people that we're going to be collaborating with for months, possibly longer. We want to identify who potential champions could be on the client's side. We're looking for people who we're trying to identify who are the really outspoken ones and who drives the conversation. Equally important, who are the ones that are quiet and need help and maybe some extra pushing to have their voice be heard. So typical discovery process, there's some pretty common approaches. We absolutely use these common approaches, things like questionnaires, stakeholder interviews. We have user surveys. We study analytics if it's a redesign. These are all great tools and we're certainly not suggesting that we leave these behind, but they fall short of really getting us to a place where we can learn about some of those less obvious objectives of discovery, some of the more interpersonal dynamics that you're going to be forced to work with over the coming months during a collaboration. So the exercises that we're going to go through today are really focused about how to break down organizational silos, how to get the communications team, talking to development, how to facilitate conversation that promotes sort of an equal voice for all parties in the room. And there's another talk, I think, coming up with, I think it's by phase two that's really focused on active listening and what active listening is. But a lot of these exercises that we'll go through, there's a product that's generated. If it's a card sort, we leave with a pool of ideas. If it's a sketching exercise, we take those sketches home and we definitely reflect on them as we move forward in discovery, but probably more valuable than those actual material takeaways is what we get to learn from just watching that team work together. And so this means not listening to just what they say, but how they say it. And taking notice to the context, as I said, who really owns the room, who, looking at body language. All right, we're going to do this presentation with two computers now. You're all pretty much committed to staying in the room. What I didn't tell you at the top of the hour is that we're going to have some fine audience participation. You're all pretty much committed to staying here now. So think about whether or not you're willing to volunteer in exchange for some fabulous t-shirts because I'm sure you all need another t-shirt after hitting the showroom floor. Okay, card sorts. Has everybody done card sorts? All right. We like to use a lot of sticky notes. Yes? A card sort, yeah. I'm going to show three examples. So I think that we'll explain it as we get into it. To build these really technical products that we end up building for our clients, these fancy websites with all of the gigas and fanciness, we have a very low-tech process. We go to our clients with sheets of paper and pens and lots and lots of sticky notes and index cards so that we can do these kinds of card sorts. And importantly to, there we go, fill up the wall with all these sorts of things. I don't know if anybody's read it, but I think in 2012, the New Yorker published an article on the old brainstorming process that we probably all became familiar with in high school. Everybody's in a group. Everybody yells out ideas. Everybody's ideas have equal weight and nobody gets to pass judgment on those ideas. Turns out not all ideas are created equal. And that traditional brainstorming process does not really work. I highly recommend reading that article. If you haven't already, you can just Google New Yorker brainstorming and it comes right at the top of the results. So what they actually found was that you're going to get the same or better information by having people break off individually and brainstorm by themselves. So that's what we do during almost all of our card sorting sessions. Sometimes we'll do small groups. Sometimes we'll do individual. It really depends on how many people are in the room. So we traditionally ask them to go off and think about as many things as they possibly can. And we start with organizational goals. I don't know how many of you work with nonprofits, but we're finding that it's exceedingly rare for nonprofits to have an actual organizational strategy or a plan around that strategy or metrics around that strategy. So when we start out, we're really doing organizational development with them. And we've had a couple of cases where they've never gotten their departments in a room before to talk about what the shared goals for the website are going to be. So that in itself has proven to be very valuable for them. So organizational goals. We think about as they we have them think about as many things as they can write it on sticky notes, slap it up on the wall, and then we start breaking those sticky notes into themes. And a lot of what we're trying to do with all of these card sorting activities is to find the areas of commonality. Every department, as I said, is going to have competing priorities. That's why so many nonprofit home pages are such a mess because they want to put absolutely everything up there. That's not going to work. But when you get the departments to write down these things individually, start putting them up there, they're going to start seeing the common themes. What the important things for this new website is going to be? What are the important goals that they're going to share across departments? And then you can find the outliers as well. And every now and then somebody's going to have a really cool idea. And during the discussion, it'll come out that everybody agrees that that's a great idea. But it's really the areas of commonality that we're looking for. Which I think, yeah, I got ahead of a slide. We do the same thing for audiences. You can't create personas for to do any of the work that you're going to do to test user stories without understanding or hearing from your client who those users might be. And you can't just look at their website and figure out blindly what what their audiences are. They're going to have a very good idea about who they're trying to target usually, even if they haven't discussed it in those terms. So it's important, and this is going back to that treating them as partners thing, finding the shared language. You need to find out who their audiences are. And we do this with with kind of a grid prioritization. So first brainstorm is to identify the audiences, figure out who the key audiences are going to be. Then we rank those audiences by importance, but also by tolerance. People coming into a website are going to have a very different tolerance level for the information that they're looking for on a website than other audience groups. So somebody who has come back to the site, registered, visited multiple times is going to have some amount of comfort with going through the navigation to get to where they're going. Or if they're smart, they've bookmarked the page that they need to get to most of the time. As opposed to a naive user who doesn't know anything about this organization, comes into the home page. And if you're hitting them with all sorts of information, they're going to be lost. They're probably going to have a much lower tolerance than a highly engaged individual. So we talk about tolerance and then we talk about the motivations that those audiences have. So this is a separate card sort. And then they come up and they assign those motivations to each of the audience groups. Ideally, there is going to be shared motivations across audience groups. That makes it much easier to design the features that's going to appeal to everybody down the road. Doesn't always work out that way. And we also work on prioritizing features. This is usually the most fun part that everybody has during the discovery process because we ask them to write down absolutely everything that they want their website to do if they had unlimited time and budget. Of course they don't, but we get into that later. So they go off into their individual groups or individually and they write down everything that they can think of that the website should do. And then we ask them to prioritize them into three buckets. Needs, wants and stuff that would be really nice to have. The tricky part here is that almost any client you're going to work with is going to think that everything that they thought of is going to be a need. So you have to do triage during the first part of this activity to make sure that they're not just putting everything in the needs column. Because once you get through this part of the exercise, the needs are essentially the features that we have to build. And we just keep reminding them. A need is something, if you don't have it, when your site launches then the project is a failure. That has to be the standard for a need. Is it the minimum viable product? If you launch without this, is it going to be a failure? And you just have to keep saying that over and over again when they say, oh, we really need social media integration. That's definitely a need. And you start convincing them to put some things into the once pile. And well, yeah, the nice to haves, we don't tell our clients this generally and hopefully none of our clients are in here, but the nice to haves is just it goes into the freezer. Hopefully someday they're going to have the time and the budget for it. And maybe it's nothing that they actually need on their website. And it's just a way to keep track of future feature development that we can talk to them about. So once we get into the once, we've been doing these card sorts for some time. And this is the problem that Brett and I have experienced with the more traditional discovery activities when you are having them fill out surveys or questionnaires, or you're just sitting there asking them questions and groups or individually, is that if you do this long enough, they're going to glaze over, they're going to disengage from the process. So a lot of the techniques that we are going to be talking about today have actually been borrowed from teachers, because teachers are experts at keeping kids somewhat engaged for eight hours a day, which is extremely difficult when you think about it. So part of that is getting people to stand up and walk around. So once we've developed this group, this set of wants, we tell them the needs are okay, the needs are what we're going to do. Now we're going to prioritize the wants, and we ask them to stand up. And I'm going to ask for seven volunteers. Just come right to the front. So I have here seven cards. Oh, you're going to hand them out. Excellent. Seven cards. And this is not a real project. So I went with something that everybody's probably familiar with already. We are going to discuss what the best Star Wars movies are and prioritize them. As a wild card, we have thrown in unnamed episode seven, just because I wanted to see what would happen. So it's a little awkward with odd people but you want to turn to the person next to you. One person isn't going to get to do this right now. So one turn this way. No, no, you don't need to really just you're going to talk to the person. And you're each going to state the case. So Michaela turn towards this fine gentleman in the purple shirt. Exactly. Yep, you're going to talk. You're going to make an argument for your feature. In this case, a Star Wars film and whether or not it's more important than the person that you're standing next to. No. Yeah, this is probably going to happen with Star Wars. Which one do you have? Okay, then you're going to swap places. Okay, and now you and the pink talk to the person at the end. Do you need to switch is Empire? What do you have? Return to the Jedi? Which one do you think is more important here? Better? It's hard to argue with that. I mean, at least half the room is going to think that Empire should end up at the most important side. So that's where we're heading. He's going to swap places with him. Do you have a discussion here? Are you in the right place? Oh, uh, quick turn. Talk to the person in the black. Who's going to win here? All right. Yeah, you could you could think of it like that. Absolutely. So if you have enough people here, and I think you can see how this is going to go, we don't have to run through the whole exercise because we are spending time. But you see they're up. They're having fun. They're moving around. They're engaging with each other. This is another chance for us to look at their interpersonal activity, try to figure out who might be a little shyer. Nobody in here is shy. I hope that Empire strikes back ended up as the most important. All right, the process works. Thank you to our volunteers. We have prizes for you. We'll wait for the end of the session, and you can just come up here and we will pass them out. That no, no, we have t shirts. Thank you to our volunteers. Oh, you want to do it? Okay, let's do the order on you hope. Yeah, number seven. All right. Anybody disagree? Yeah, I actually saw Revenge of the Sith in French the first time I saw it, and it seemed like a remarkably better film. Thank you very much. So you can see they're up. They're engaged. They're talking to each other. It kind of breaks up the monotony of sitting around talking about features and audiences and gets the blood flowing, etc. Another kind of card sort we do is live tree testing. So we break our discovery participants into small groups, and we ask them to create a site navigation structure for their proposed new website. So they create the top level menu items, they create the secondary menu items. And if they really want to, although we discourage them, the tertiary menu items, and they write them all on index cards, different colors. So primary navigation is maybe yellow secondary navigation is pink tertiary navigation is bright red. And after they've created their navigation structure, we asked them to collapse that into piles so that only the top level navigation is showing. And it starts and then we have the group switch places. So they go and look at somebody else's navigational structure that they've built. And we give them tasks to complete. And this starts to get them in the mindset or out of the mindset that they really know their content very well because when you use a website every day, as these people probably do, you become very familiar with where to find things. Unlike a naive user to a website who come in and all they see is the navigation, the top level navigation structure until they start moving around in it. So we start to get them into the mindset of their target audiences and not necessarily of their organizational goals. And we ask them to complete tasks. So by this point in the process, we have a pretty good idea about what they're doing and as an organization. So we can customize it for that organization and say, okay, this is an audience member who is looking for the location of a food bank. And they have to go to this collapsed site map and say which of these top level navigation buttons is that most likely to live under. Click it with their hand, they spread it out and they see if it is there and they start to understand the difficulty that information architecture and user experience people have. It also makes sure that we record all of their ideas about what the site map might look like. And again, we're going to look at the commonalities and that is going to help immensely when we start developing the official site map. Also if people have really good ideas, it will help you win those internal champions because they think that you're using their ideas even if it's just information that is part of what you're doing. That all make sense? That one seemed too difficult to do in here. But I do need two more volunteers. This is for an exercise that's called big paper. As we've said a couple of times, just by dent of human personality, some people are going to be less likely to engage with the process than others. There's going to be dominant personalities. There's going to be people who just quietly sit there but might have really good ideas. So this is another way to get them up, walking around and thinking. But this is a silent activity. It's done with paper and with pens. So I need two people. And we have a quote. Oh, yeah. Preferably different people. I don't think you're going to want two t-shirts from us. For everybody out there, this is the quote that you're going to be dealing with. Did you grab pens for them, Brett? So to our participants, you want to look at this quote. You want to underline words or phrases that really stand out to you or resonate with you and then write some notes about what it makes you think in the margins. We'll hold this paper up at the end. You need to have a really big piece of paper for this. That's why it's called big paper. It's borrowed from elementary schools so that they can, they have that space to write in the margins. We've done this in particular when some of our clients want to create a community because you know community is just something that's going to happen when they build this new website. This is part of being an advocate for your client in a lot of ways because community is desperately hard to build. And unless they're willing to put the internal resources into place, it's probably going to fail. They probably need a community manager or somebody who is actively managing content for a community. So we've pulled quotes around that idea or around the idea that community is not a discussion board. Ideally, your quote is going to be somewhat controversial to really give them something to think about. And once they have finished writing all of this down, they go around to see what the other groups have written as well. So they start thinking about it. And then we bring them back together and we have an open discussion about what it is. And since maybe some more of the more shy people have taken time to write out their thoughts, they're going to be more willing in this case to defend what they had to say because they've already become engaged with the process. They care about what they wrote and if one of the more dominant personalities is trying to override them, they're going to be much more willing to speak up about what they mean. We don't have to spend too much time doing this. I am curious to see what people have to say about this. I'm not sure that we have anybody in the room who would have seen the second trilogy first. Anybody? Nope. OK. How's it going? Now it's very quiet. Does anybody have any questions about this? Any other instances? We can do it for the idea of drop-down menus. If you have an executive director who's really tied to the idea of drop-down menus, you can find some pretty good quotes and user experience websites about whether or not what drop-down menus are a good idea. So if you have somebody who's really a strong advocate for a feature, it can help bring out people who might not want to talk about it or dispute somebody who is ahead of them on the org chart, but would be more willing to do it when they're writing it down. So they're going to take this quote about drop-down menus and they're going to say, OK, maybe it's not as important. And if the person in charge, hopefully, isn't a completely I'm OK. I'll refrain from using bad language, but completely sure of themselves, they'll start to see this opposition and the quiet opposition makes it somewhat more effective than actually having this loud argument. We have seen loud arguments in these discovery processes well, but by doing it quietly, it brings out the opposition and can help you make your case for any particular direction you're trying to guide them in without making it explicit, saying we don't think this is a good idea. Because as soon as you say something like we don't think this is a good idea, if somebody thinks it's a good idea, they're going to push back and probably shut it down. Did you come up with? Yeah. So in the down menu? Yes. But yeah, absolutely. You could do it for social media sharing. I've read some stuff recently about how much the social media sharing button slowed down your website just because of all of the code is putting in place and what the relative value of having somebody click on the tweet button instead of copying and pasting the URL because they already know how to tweet, what value they're getting from that. Most everybody thinks that social media sharing buttons are something that they need to have because everybody has them. But if you have a somewhat controversial or contradictory quote, you can bring out some interesting information that way. Yes, Makayla? Part of the process is that there are actually three different quotes or four different quotes and you divide them into groups. Sorry, I didn't explain that very well. So yeah, you get a number of quotes and you break them off in their groups around the room once they've gone through this process of annotating. They switch and see what everybody else's wrote and maybe add some comments of their own until everybody has gotten through it. And let's see. Thank you, Fine Star Wars volunteers. What have you told us about JJ Abrams' quote here? Do you want to hold the paper up? This is also another way to create documentation from your discovery process that you can take back to the office with you and look at another date. It saves you from having to have somebody in the room who is just constantly taking notes. I'm sure you did. In this case, there are no yep, kids, young, quick. What did the quote trigger in you? Do you agree? Do you disagree? Are you worried? Are you worried about episode seven? So no, OK. So that is big paper. Yeah, that's going to be. All right. That is an awesome thing to know. So that's the kind of insight that you can get out of big paper. If we have some time, we can bring my colleague Stephanie up and she can talk about the extended universe of the books afterwards and how that might impact the movies as well. But all right. Thank you to our volunteers again. And now Brett's going to come up and talk about cores and paths. Does anybody have experience using cores and paths exercise? This is certainly not something that that Brett or I invented. No? No. So we always guide, many of you in the room might not know, but this is the founders of Think Shout, Lev and Sean. We like to have fun when we guide our clients through this exercise as an example before setting them off into groups for them to work through the worksheets on their own. And our hypothetical example is that Think Shout decides that they no longer want to work with nonprofits. We're going to go after the big dollar contracts and we're going to do a rebrand of our, a rebrand and redesign of our website and we're going to become ThinkShout.com. Shout think. Shout think.com. And this is what an empty cores and paths template looks like. We meant to add a link to this, but we'll make sure to sign into the session and post a link to it as a comment. But basically, what cores and paths helps us to do is it really helps us to get our clients to start thinking about their content in a much more granular way than doing your more typical design studio collaborative sketching might be because it's a lot more focused. As you can see, there's there's several key areas that we ask the clients to work through outlining user goals, organizational goals, inward paths, outward paths, search terms, key metrics and calls to action. So what does any of that mean? Basically, with cores and paths, we get them to we begin by getting them to focus on what a core content type might be. And so we'll take an event as our example. We think about what constitutes an event on their website. What information makes up an event on the website? Is it date and time and location? What other bits of information might we want to capture about an event? It's not an exhaustive list of, you know, field level data that that makes up that particular data model. But it gets them to start thinking what the components of that that content type are. That's almost the least important part. The more important parts are getting them to think about what how a user might arrive at that piece of content. We find that a lot of clients just assume that, you know, people are going to arrive on their front page of their website and that they're going to just use the navigation solely the navigation to move throughout a site and find the content that they're looking for. It's websites aren't like books. You don't move through them in that same linear fashion. So by getting them to think about how a user might arrive at a piece of content, whether that be an email newsletter that has a link directly to an event page contained in it or its organic search and they arrive two, three levels down within a site architecture. By getting them to really think about how a user gets to that piece of content, it forces them to start to think about how it fits into the larger information architecture and how the content relates to each other. By forcing them to think about user goals, you know, there's certain assumptions that we can make about a user and later test based on the fact that a user has arrived at this piece of content. It helps us to, it helps to get them to really think about what is the value that a user is looking for when they're looking at this piece of content on your website. Then by thinking about organizational goals, we get to think about how we can really sort of convert on delivering value to our users. So once, and that really feeds into what the outward paths are, how can we, when we have a user on an event page and we can assume certain things about this user, what other content on the website might we want to direct this user to that support the larger organizational goals. And that's really what we document as outward paths is we have this user here on this page of the website. What else do you want to highlight? What else is relevant to that user based on what you can assume about them? Cause to action gets them to start thinking, you know, more specifically about the language that they might want to use, tone of voice, just how they're going to be speaking to that particular audience and how they might call a user into action to support those organizational goals and send them out to those outward paths. Key metrics is one of the updates that we've made to this made to this exercise. And this really gets the client having to think about what defines success for this individual content or feature and how can we measure it after this site is built? And this is something that we will use sort of post launch. We'll look at the features, the content that we've built we'll look at what the key metrics that were identified and agreed on for a particular type of content or feature. And after the site's been launched for a period of time, we'll constantly go back and review based on the information that we can get, whether it's really delivering on those on those key metrics that we've defined. Anybody have any questions about cores and paths? How it works? The another way to think about it, and this is getting cut off, but inward paths and user goals, the template is, if you look at it from left to right, it's really about, you know, findability and user motivations. The center is what that content is, what provides value to your users and the right side is all about conversion. Knowing what you know about that particular user, how can you ask them to get more engaged and how can you convert the fact that you've delivered on the value that that user is seeking. Well, we address that more as part of the wire framing process, but I should note, you know, anybody that works in user experience, these templates filled out from a large group of stakeholders who are like gold, it's, you, it really starts to help formulate what the content strategy and where the relevant content is, but it doesn't necessarily define priority of what those various call-to-actions are. We make recommendations in the form of wireframes, and then it's more of a dialogue with the client to define what those, what those high priority call-to-actions are. We do do that. Our typical discovery process, you know, we go through an organizational goals and target audiences exercise. We have that features brainstorm. We move into doing things like cores and paths once we've identified some of the core content and features. And that's usually day one in a two-day sort of workshop situation. We sort of loop back around, and so we might address some of the same cores, but we might have different groups focusing on that same core but from the perspective of a different target audience. And so it really gets them to start thinking about how content needs to be, you know, structured to speak to their varied audiences. And it also gets them to understand that if they litter a right side, sidebar with 13 equally prominent calls to action, they're going to get nowhere in any one of those fronts. What kind of instructions do you give the users when they get the cores and paths worksheet? Because it could seem intimidating with all the lines and boxes without any sort of instruction to get them going. So we generally give a full presentation. So we walk through, we have that hypothetical use case and then do a very good job of explaining this, but we have a hypothetical use case of think, shout, rebranding as shout, think. We have, we pick a core. The core that we usually focus on is a team profile page. And we walk them through the cores and paths template, you know, section by section and show how, how to sort of move around what each section really means and what we're looking for in terms of information. If it's a remote situation, we'll just give that over a go-to meeting. If it's, if it's, you know, an in-person discovery, then people are usually broken into groups and working on these collaboratively. And we're constantly just moving throughout the room, answering questions as they need to be and really just listening to the conversations that are had as they need to, as they work through things like prioritizing what the calls to action are. And this is another exercise where I think it's really important to sort of break apart the, the departmental silos. Like I really encourage you to get development in a group with, you know, communications or, or operations and have them, have them be forced to work through a template like this together. It's created some really great conversation. That's further down the road. Yeah. We should probably keep moving. Okay. That covers, we, we knew that we were gonna spend most of the time talking about the student part of the many hats of content strategists because a lot of the tools that we have around there. But we'll quickly go through the times that you need to be a counselor as well as an advocate for them. One of the big places that you need to be a counselor is around language. I said at the top that nonprofits or probably a lot of the for-profit clients that you might work with have their own internal languages that you're not necessarily going to understand at the beginning but that you have to get a handle on. We as Drupal developers have our very, our very own very specific language. Not many clients are going to understand what a node is or what a view is or what an entity reference is until you explain it to them. It can be very confusing. Like a view in common language is nothing like a view in Drupal speak. So you have to make the translation between what Drupal is going or what the developers are going to be making for your clients and how you talk to them about it because if they don't understand what a view can do or what a node is or what a taxonomy term is, it's going to be very difficult for them to develop their own content strategy without a lot of hand holding. We need to educate our clients as well. We need to provide them with the knowledge that they need to make the decision that we think is right. Sometimes they're still going to argue with us but if we make our case very firmly and strongly and backed up with all of the experience that we've all gained over the years, you're going to be able to start to push them in the direction that we know is probably the right one as user experience or content strategy experts. And again, this is going to go back to all of the group exercises that we did because some people are going to be much less technologically savvy than others. So you need to figure out who that might be and who's going to push back on features that you might suggest just because they don't understand what you're talking about. And there is putting on this because justification is the proof behind the putting that you are suggesting. This is where you can share some studies. We've had to do a lot of justification recently around storytelling style home pages because a lot of people, particularly in nonprofits, are still hung up on the idea of the fold. If you spend most of your time doing print campaigns, you know that content above the fold is the most important. But we've developed a list of a lot of studies and analytical surveys that have come out somewhat recently that prove that scrolling has become a very natural action on the web. And by having that on hand, by being able to say, no, people are willing to scroll, here are some studies on that and here are some organizations that are doing this very well by getting that visually in front of them before we start doing a lot of design work. We can help sell them on that. This is where data analysis can help. If they have a current website, I recommend that you always ask for access to their analytics account. We have been doing some work recently with an organization that works with women who have developed breast cancer. And looking through their analytics, I noticed that their mobile traffic has exploded. It was 5% back in 2010. It's 30% now in 2013, which is higher than the average. And so I poked a little bit deeper to find out why that might be. And I found that people coming on mobile devices were much likely to go to stories about people who have survived breast cancer. So I developed the theory that, and I can back it up with data, that these women were getting this terrible diagnosis. This is like one of the worst moments in their life. And they're probably alone in a doctor's office or in their car. And they're scared. So they're going onto their mobile device and they're finding the first link that comes up. And they're trying to find evidence that this is not going to be something that is necessarily going to kill them. They want to find evidence that people are surviving this. So they're getting to our client's website, looking for this. But it's not a very good, it's not mobile friendly right now. So they have a huge mobile bounce rate and it allowed me to justify or make the case that they need to have a firmer call to action and responsive design to make sure that these women who are experiencing this terrible moment are going to get the information that they come looking for. User testing, we've started doing user testing using XERB solidify. If none of you have experienced that yet, it's really a great app that lets you take screenshots of the wireframes that you've developed to maybe even just as sketches, load them up, create hotspots and then you assign tasks and people go through the task to see if the UX that you've set up or the information architecture that you've set up is actually going to work. I can create these tasks, like five different tasks and send it out to an audience in less than an hour now. So if somebody is worried about how much budget user testing is going to take, tools like this that are coming out right now can help justify, get some data to back up the assumptions that you've made about the paths through the website to either tell you that you need to go back and rethink some things or to have this actual data that you can show to your clients saying, look, this is working so we should probably progress with it. We can talk more about user testing afterwards if you're interested. And justification also goes back with all of this work. We've documented this. We have all of these papers. If at some point during the process they push back, you always have this reminder to go back to the organizational goals. Now this is why we said this feature was going to be important because you said this was the goal or one of the goals of the website and that's why it's here now. So no, we don't want to cut it at this point. And then you have to advocate. You have to do that both internally in your own company or department and you have to do it for your clients. So you have to advocate, sometimes on behalf of the client, especially, no offense to the project managers in the room, but sometimes there are budget pressures and things need to be cut because you have spent these weeks and months trying to understand what the client needs and what their content needs are, what their content strategy needs to be. You are probably best prepared to advocate for your client internally what features might need to be prioritized. And you're going to be best positioned to help the project managers out if, say, there's not enough time or budget to develop a particular feature, you're going to be able to provide the language based on all the work that you've done so far to the client explaining why this might need to wait for phase two. Again, yep, you have to justify some of the functional requirements. Working with developers, our team at ThinkShout is great, but sometimes they get focused on the beauty or the functionality of the code itself. They haven't gone through this process, they haven't developed the bond with the client. So the business logic that necessitates a certain flow through the website might conflict with the developer's idea about what the best way to handle this use case is. So sometimes you have to say, yes, I agree that the code would be much nicer if we could do that, but it doesn't work for the client in this situation. And then you can lay out the reasons why. You sometimes have to advocate for the process. I already touched on this a little bit. We've gone through this process. There are very distinct steps. We're trying to find out the goals, the audiences, the motivations of the audiences, why they're coming to the website, and then translating the audience motivation kind of silently using the magic of the internet to get them on the path that furthers the organizational goal itself. So you have to advocate for the process sometimes. This, there are reasons that we're going through these steps, and we don't get to the third round of wireframes and then completely change our mind about what the functionality should be. So sometimes you have to go back and remind them about the process and the reason that we did all of this. You have to equip your eternal champions with the language they need to make your case to everybody else in the organization. If you've done your job well and you've developed this rapport with some people who really get it, who understand what you're trying to do as you're building out this new website, they're not necessarily going to be able to explain it very well unless you give them the language. You can give them some bullet points. This is why we're doing this. One, two, three. They can translate that into the language that their own internal stakeholders might better understand. And sometimes you have to advocate for yourself because everybody in this room is an expert around content strategy or information architecture to some degree. We've been doing this for years. So a client who makes the suggestion that the homepage should just be a giant donate button, you have to push back sometimes and say I'm sorry, we've been doing this for 15 years. We know best practices. We know that this is probably not going to work for you. Don't be afraid to stand up for yourselves when clients are being weird. And finally, at the end of this, documentation and training. Because you understand the motivations of the audiences and the end user goals, in some cases you're going to be necessary even if it's working with the developers or the project managers who are going to be delivering the training to the end users. If you want to make sure that this beautiful site that you've been spending months or years on is not going to be destroyed by the client as soon as you turn it over to them, you need to provide them with the training necessary to use the tools in the way that you think is best. And thank you very much for joining us and with putting up with the technical difficulties at the top of the hour. I hope we gave you some things to think about. I don't think we technically have time for Q&A but Brett and I are more than willing to stick around and answer a couple of questions until they kick us out. And the buff tomorrow. Oh yes, and we are also doing a Birds of a Feather session tomorrow with more of these activities that you can come do with us in person. At what time? I forget the time. Thank you very much everybody. And volunteers please come up and get your t-shirts if you want them.