Steps to Creating Great Content

[00:00:03]
>> Okay, so we're gonna walk through, we're gonna use a project process framework and it is a little waterfally and I apologize for that. But this is the best framework in which for me to introduce these tools to you all, okay? So we're gonna start with kickoff. We're gonna talk through situation analysis, the strategy and the implementation for project work.

[00:00:21]
And this can, a lot of these artifacts are around website work, but many of them can be included to product. I tend to talk about a website as a product anyway. So, okay? All right, before we do any of that, there should typically be kind of a pre-kickoff.

[00:00:45]
How many of you actually run projects? A few of you sort of, okay. I wanna just talk through this really quickly so that hopefully we know what can and should happen in these pre kickoff meetings with core teams, okay. So this is a time to revisit project scope to make sure that everybody's on the same page about what's actually happening.

[00:01:08]
To begin what we call the documentation dump and to review stakeholder participants. So we as content strategists, when we do projects that are really focused on the content, there are typically a number of documents and artifacts that have an impact on our ultimate content recommendations. And these can be design artifacts, they can be development, they can be related to the content management system, they can be company strategy, they can be marketing and brand guidelines.

[00:01:36]
They can be organizational charts. There are always, they can be existing content artifacts and whether if everything from brochures to video to interactive timelines, right? All that stuff we need to look at and sort of categorize, because in our situation analysis, we're not just gonna report back on here is the stuff that you gave us.

[00:02:00]
But we're gonna try to work to identify, okay, what pieces of information are important as we start to shape our decisions around content, okay? So that's where that starts. So when we revisit project scope, we wanna know what the informing goals are and what strategy was in place that initiated the project itself.

[00:02:22]
What is the driving force behind this? What are our project objectives? What should this project accomplish when it's done? What's our timeframe? What's our budget and what are any known risks and assumptions? So for an example a known risk that we often have are constraints, resource constraints. And that if we are working with these resource constraints and you want it done in 8 weeks but it's gonna take 12.

[00:02:47]
Okay, and oftentimes you're like we'll figure it out and get it done in eight. Great, you can have it fast, cheap, or good. Pick two, [LAUGH], right? So this is all stuff that's good to know as you're launching a project. Here are, I kind of went through this.

[00:03:04]
These are some examples of the documentation dump that you might find useful. I think that no matter what your role on a project is, the more context you have about decisions that are being made, the better. The more informed your choices can be. Oops. So this is another thing is understanding stakeholder participants.

[00:03:24]
So understanding who is whom within your project. I don't know if it happens sometimes that you're working with even sometimes when you're working on a small team that you're not quite sure who's responsible for what. Who needs to be consulted before a decision is made versus just who needs to be kept informed of decisions?

[00:03:43]
This is on project I will say in projects within my own organization. I try to take the role of someone that just needs to be informed, but there's sort of specific trigger things that I need to be consulted on that I need to kind of give my okay to.

[00:03:56]
So in this instance with roles too, we have your owner, we've got the person who's making final decisions. Usually up above, there's somebody who said, yes, I support this project. Maybe I have given money for this project, and I'm going to champion this project among leadership. People who influence outcomes and then the derailer, and I know you all are familiar with the project derailer.

[00:04:20]
This is the person who maybe swoops in halfway through the project and says, that's not quite what I was thinking. Or didn't I tell you we're launching a massive rebranding campaign, or by the way, we're switching our CMS in six months. And so all the work that you're doing to organize whatever on SharePoint for example, that taxonomies not gonna be supported on the new CMS that we have in or we've got to roll it into a corporate taxonomy or whatever.

[00:04:48]
So those are project derailers, we wanna identify them. And then we have the people who are kind of leading strategy, whoever the experts are subject matter experts are who are gonna have an influence on the actual substantive content or functions within the application. Who's actually doing the work, the implementer to build the thing, and launch it and then user proxy, which are the people that we're in touch with to understand about user needs and expectations.

[00:05:18]
How many of you guys have actual access to user research or usability in your day to day work? Boy.
>> What type of things would fall under that with a reason your research would you usually expect?
>> Well, I think that the most straightforward and easy one are just usability testing.

[00:05:37]
Where it's like treejack testing online or just being able to watch somebody use the thing that you are building. Even just walking over to somebody in marketing or in accounting or whatever and saying, can you give me ten minutes I want you to try to find x, y or z.

[00:05:54]
Or I want you to walk through the sign up process or I want you to try checking out on this thing or whatever. That's usability testing. And that is giving you insight into whether or not what you're making makes any sense or is doing what it's supposed to do.

[00:06:12]
There are a million different ways to talk to your users. I find that an easy shortcut in terms of just being able to identify and prioritize. What people want is to talk to somebody in sales or support and kind of hear what is it that you're hearing over and over from our end customers from either potential or current customers that they're wanting or that they're lacking?

[00:06:33]
Yeah.
>> Internally, we use intercom or intercom.
>> Sure.
>> So we can have these two way conversations with our customers within the website, within the native apps, within our support email, and it's all in one central hub Facebook. And you can just basically look through support and see all the different conversations and kind of pick out here the common themes and put it into buckets and say, okay, here are the top issues that kind of feeds into our quarterly roadmap or our actual roadmap.

[00:07:13]
So we have thousands of two way conversations with our customers to inform. We don't necessarily create a roadmap based on that. But we-
>> They inform.
>> Yeah, it helps us have a perspective of the pain points of the customers.
>> That's great.
>> The common issues.
>> That's great.

[00:07:29]
That sounds like a really useful tool.
>> Really?
>> Yeah.
>> It's like basically how I built this business.
>> Yeah.
>> Is on the conversations with the customer.
>> That's great.
>> Making sure that when you see a common frustration it's like, all right, [CROSSTALK] eventually you just once you solve it, you don't get that concern anymore, that question or that, and then its customers happier and your business grows.

[00:07:55]
>> Yeah. Yeah, great. Would you guys like to know what your users think about what you're building? [LAUGH] That'd be nice. Yes, great, you can ask for that. You can ask for it you can say, this is like end user input is what really is gonna inform the success of our product long term.

[00:08:19]
We can't be making decisions just based on our own assumptions forever, right? No matter how well you know you think you know your customer, your user, think about how your own digital usage habits have changed over the last 18 months for example, right.
>> And also Code 42 locally made their developers even be in support.

[00:08:44]
I think it was for like-
>> So smart.
>> A month before they could write code. They had to do support so they could feel the pain of the customer. And then once they got into developer role, they can be like, okay, now we can actually address these things.

[00:08:58]
>> That's so smart. Yeah, so working with project stakeholders is a huge oppportunity and pain point as I like to put it. I don't know necessarily how much contact you all have with larger project teams or working teams day to day. But these are as a content strategist, these are things that I need to understand and know as I go through building anything.

[00:09:26]
So how often do people need updating? At what point do we need their feedback, especially if you are delivering content? When you start to deliver content, who needs to provide feedback on that content? What kind of edits should we expect? Do different people need to know different things?

[00:09:45]
Do we need to communicate with people differently like some people prefer email? Some people prefer Slack. Some people prefer just to be updated in monthly meetings for example. And are we able to provide updates through existing forms of communication?