I was watching Karen McGrane’s video on “The 11th Hour Sh*tstorm Problem” earlier today. (It’s a really good video. If you have anything to do with user experience or web development, go watch it. I’ll wait right here.)
Welcome back. So, while watching that, I had a few ideas.
The problem she’s discussing is VERY real. I’ve seen it too many times. But let’s look at it from my end – that of the content writer/producer.
Sometimes development teams focus on their work and think of content as “something that goes in later.” Resulting in content producers (like myself) have awkward last-minute conversations with them. Like this:
“Thank you for finally speaking to me about content. I’ve been trying to coordinate with you and the client for weeks now. What? You built the site already? Here you go then–half-baked content. Have fun figuring out how to fit it in!”
So I thought I’d blog about a question. A question that should help crystallize the “11th Hour” problem – and maybe help a few of us avoid it in future projects.
When should content “come in” in the development process?
Right now content is the red-headed stepchild in most dev processes. It’s the “black box” as Karen put it, that designers & developers block out in their minds. And to be fair, it’s not their primary job, so it makes sense.
Trouble is when they do this, one of two things happen:
The content producers are shoved to the side of the project cycle.
OR
The content itself is ignored.
Both result in – you guessed it. The 11th Hour Sh*tstorm. (Karen, that is a great metaphor. I may borrow it for future meetings.)
So how do we fix this? Well, first by answering the above question of when to bring in the content. I find that…
The best position for content “coming in” is right before the client sees the new site for the first time.
Why then? Because this position forces several changes in the overall development process. All of which help keep everyone content-aware.
Oh, and it helps create better content too.
- It reminds development that the site is not a “bucket” for content – it’s a podium for it.
- It compels use of a content strategy. If the dev team knows content is coming up, and there’s a content strategy involved in the project, then that strategy must work with the overall Web strategy. And vice-versa.
(This also gives a paper trail for everyone to refer to/save themselves with later.) - It compels early buy-in from the client. It’s easy to put content off in favor of development. But if a content writer is right there at initial planning, he’s much harder to ignore…
- It helps you organize the site around user needs. Karen made a big point of this in her presentation, and I agree 100%. The site isn’t there to astonish the client. It’s there to help their customers solve problems. Showing them content DURING development gives more time to sharpen the message.
Content Must Be a Constant Presence
When the client first sees the site, it should have content IN IT. Lorem ipsum filler is now a sign of poor development. (I have decreed it so.)
If content is to be delivered at first-version, then content R&D has to start at the same time as site development. Usability testing, audience research/interviews, UX, outlining…all done while the site goes from wireframe to HTML.
This way content providers stay in the loop. And the client receives reminders about content’s importance. Maybe this will help dev teams avoid last-minute scrambling.
Hey, we content producers don’t like it either. We’re all problem-solvers in one sense or another. So let’s fix this!
Thoughts? Anything to add? Think I’m radically oversimplifying things? Comment away.
