Content Strategy

Situation Analysis Review

Kristina Halvorson

Kristina Halvorson

Brain Traffic
Content Strategy

Check out a free preview of the full Content Strategy course

The "Situation Analysis Review" Lesson is part of the full, Content Strategy course featured in this preview video. Here's what you'd learn in this lesson:

With research steps completed, Kristina reveals the format for Content Strategy analysis outline, which includes recommended next steps.


Transcript from the "Situation Analysis Review" Lesson

>> How did that go?
>> I thought it was very difficult because I sometimes found myself trying to answer opportunities as opposed to answering the questions that are posed there. So opportunities being hey if I do this and I might be able to reach that map but that kind of just it felt distance for those questions.

>> And those questions actually, I think kind of brought me back to reality.
>> Yeah, good, good. Yeah, it is easy to spin off into, we can do this, and what about this, and this would be a great idea. And this would be so nice, versus coming back into and really thinking about, like, what are our current strengths and what are our real threats.

Yeah. What else? A huge part of this exercise, especially for you all, is that it's just to get you thinking about opportunities for content, to your point, differently than we've thought about them before. And to think about them on a broader scale than just, I need to fix the wording on this confirmation page, right?

So hopefully it gave you a chance to just sort of like relax your brain into thinking in new ways around content. Okay, All right, we'll go ahead and move on here. So when you are ready to frame up your situation analysis, this is what the outline will look like.

We went through early on, project scope and purpose, business and team goals, your priority audiences. And what their needs are, we usually recommend keeping priority audiences to four or fewer, three, maybe two. Sort of the themes that you were able to identify that kept coming up, which would also include sort of your SWOT pieces, any proof points that you have and what the risk is of not addressing those threats.

And then, recommended next steps. Which might include, what we usually will say is, there's not enough user research for us to make really informed recommendations around what content we are going to include. So we recommend that. If you don't do that, the risk is that we're not gonna meet the true needs of your primary users, and so we'll just include that to kind of cover our butts as we move forward.

And then sign off. Okay?
>> One other thing too that I'm noticing you're doing a lot of, and this is really awesome is that when like, under themes when you say outdated CMS, that's something chances are, visitors to the site aren't gonna notice, that's actually kind of maintaining the site.

>> That's structure and process, basically.
>> Yeah, okay.
>> Mm-hmm. Yeah, and that is the editorial and experience is the content design and that is the stuff that people are going to see, right? Systems design is the stuff that makes the content go. So it's almost like the behind the scenes piece.

But that is what is gonna have the greatest impact on your content itself. And that's why even if it, we aren't necessarily empowered to make decisions about it ourselves, it's so important for us to pay attention to it and identify it like where are the cracks? Where are the gaps, where are opportunities for me to shift a mindset or to ask for something a different way or to connect with somebody I haven't spoken with before around content requirements or my needs.

I mean, one example that I often give about a conversation that can have a terrific impact on content quality after it's been published or as it's been maintained. Is that oftentimes, what the writer, we'll talk about text here, what the writer hands off and what the developer receives, the developer does not have the information they need to appropriately code and publish the content.

So there are a million open questions that they have that are not covered off on in the document. A really simple example is metadata. Right, so the developer ends up writing their own metadata for the page. Or there are 14 different fields and buttons and interface copy that hasn't been accounted for either in the design or in the deck.

And so the developer ends up having to write that. And so a conversation that has to be had early on is we want to talk to your developers to make sure that what we're delivering, the way in which we're delivering it, whether it's in a Word doc or in the CMS or in some other kind of format, the way in which you're delivering it works.

For them, right? Because if we deliver documentation with holes, or with inconsistencies, that's gonna have a significant impact on the output. And it also has an effect on our developers' time. It's more respectful to be able to deliver what they need the first time around. So that's an example.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now