≡ Menu

The content quandary: when the words won’t fit

I’ve just returned from a delightful trip to Sydney presenting at Web Directions RESPOND. I met a bunch of fantastic people and listened to smart speakers talk about responsive web design.  My presentation was about the role of content in RWD, and what to do when the words don’t fit. Here’s a copy of my speaker notes – my slides are on SlideShare.

There comes a time in every content project when the enormity of the task at hand hits home.

It’s a moment of realisation. The seeing of the light.

And it doesn’t really matter how big or small the project is. It could be a couple of pages. It could be a multi-thousand page global monster that will be translated into 25 languages.

It always happens.

It sometimes manifests as a terrifying silence during a meeting or a look of panic masked by a nervous smile. Everyone glances around in discomfort and suddenly people start talking extra resourcing for the content team.

It’s similar to what I like to call the “crowbar” scenario. That’s where (as a content strategist), you take some “real” content to the UX lead or the designer (depending on how big the site is)-—who has been slaving away on wireframes or a beautiful design, and you present them with something that simply won’t fit.

It will wreck things with its clumsy structure or verbose word count.

Yet, it’s what the real content is like.

It’s what I like to call the content quandary.

And now you have to make some tough decisions to get things back on track.

So why does this happen?

We have built a utopian view of what content means in a responsive web design.

We talk about content choreography, neat little structured packages of content, content and systems that can be easily replicated

There’s order, elegance, uniformity and nimbleness.

But in reality, content is never like that. (Well to begin with anyway.)

It’s big and scary, cumbersome and slow moving.

Not only is the content itself hard to manage, but content as a phase doesn’t fit easily within a traditional project schedule.

Kicking off a fast-paced iterative design and expecting content to be part of it, or completed in parallel, or slotting content in as a phase AFTER the design is done, can quickly turn into a nightmare.

So, where should you focus your energy to make the content side of your next responsive design project a little less painful?

Here are my top three suggestions.

1. Restructure. Content (model) first

First, avoid the crowbar moment.

The rally-cry of content first has been music to the ears of us content professionals. But just like the content utopia we have built around responsive web design, strictly following a content-first approach sometimes just isn’t possible.

Because you don’t always have content to use, or it’s not in a shape to use before wireframing starts.

That’s why suggest content model first approach.

If you can figure out the structure of your key content types and hand them to the design team, then you’re getting the foundations right.

A content model details what attributes a particular piece of content has. They can be basic or complex, depending on your requirements.

From a responsive point of view, it helps design for real character counts, assists with prioritisation and looks at the relationships between different attributes.

So, for instance, not only will you know that your product names range between 14 and 32 characters, you will also find out that each time a particular type of medical claim is mentioned, it’s a legal requirement that full journal references are visible immediately afterwards.

It means the design team can move forward and start designing, even if a bit of lorem ipsum is required until real content is available.

When the wireframes and initial designs come back, they will be accurate and when real content comes through, it’s much more likely to slot into place rather than wrecking the whole thing.

Don’t worry if it’s not perfect – try to get it about 80% there. As Cleve Gibbonsays “no model survives first contact with real content”. This means – that in the same way as design – content modelling is iterative and will evolve as it’s tested. And that’s OK.

But from a RWD project point of view, doing some initial work and getting the content model sorted for the main content types will save a lot of heartache and cost later in the project.

OK, so you’ve figured out your content models, what’s next?

Now it’s time to talk about the actual content.

2. Review. Focus on what’s on the surface

One of the main reasons that content can destroy a web project (whether it be a responsive project or not) is that content is overwhelming. When you realise your content isn’t going to cut it with the new site, the simple task of knowing where to start fixing the problem can cause paralysis.

So here’s what you do.

Pretend it’s an iceberg. 10% is above the surface. This is your priority. These are your most important pages.

And in the same way as you wouldn’t use images taken on an iPhone for the home page of the new site, you wouldn’t get just anyone to write the most important pages on a new site.

So get in a professional. Hire a copywriter to write that 10%. It ends up being a far more cost effective process for everyone involved if the person writing the content has direct access to the design team.

If you or a client is shelling out money for responsive site, you can afford a copywriter for your top 10% of pages. Think the home page, landing pages, main category pages. Key transaction points. For a really small site it’s an extra grand. For a bit site, well it’s a bit more – but I bet it will save money in design revisions and project team meetings.

It also forces a streamlined approval process and gives focus on what’s important. You are made to think about key messages, where and what the call to action should be, and how pieces of content relate to each other.

I’m not saying to ignore the other 90% lurking below the surface. This is often the messiest content, but frankly it will take more than one project to clean it up. It will take an ongoing commitment to improve.

For the new site, you can resource this content review internally you want. But make sure content creators have support.

Give them a copydeck that contains a template for each page so you get what you need.

Help them with a style guide that gives them clear direction on character counts for content components including headings and navigation.

Make sure you update their style guide to strip out directional content and instruction. We all know that in a responsive site, content can potentially end up anywhere on the page and be used on all sorts of devices. So terms like “click here”, “see below” aren’t needed and shouldn’t appear in content.

It’s language that’s littered across the web, born from a time when digital was something new and you felt like you needed to explain what to do.

Also cut out actions that might be redundant soon. Who knows how we’ll end up interacting with content. Winking or blinking will be next!

Make this clear so you don’t get a bunch of copy that simply doesn’t make sense on different screens.

3. Rethink. Content as a battleground change agent

Many web projects are used as agents of change – whether you like it or not.

“Yes, designing and developing a new website will magically solve the inherent problems in our business like lack of vision, outdated processes, no governance and of course: awful content.

Let’s re-brand at the same time and launch a few new products too.”

Heard that before?

Suddenly you’re not just figuring out the complexities of a responsive site, you’re also doing battle with a bunch of internal stakeholders.

And it’s content that quite often becomes the sticking point.

People get a new design. They can see it. They can provide feedback.

“Can you make the logo bigger?”

But rethinking how content is going to be managed in a responsive world is hard work.

It impacts workflows, style guides, approval processes and content creation itself.

The unglamorous stuff.

That’s why it’s really important to have a dedicated contact on the client-side whose sole responsibility is content. Not the project manager, not the project sponsor, someone who understands the business of content.

This might seem like overkill on a small website. But it’s important. Having a single point of content for all your content matters will help avoid the content quandary.

 Thanks to everyone to came along to listen. I hope there are some points you can take away and apply to your next RWD project.

{ 0 comments… add one }

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.