Which Came First? Design or Content? Neither, They Need to be Hatched at the Same Time

by Joanna Pineda Posted on November 10, 2009

Chicken and Egg There is an ongoing discussion at Matrix Group about content and Web design.

One camp says that clients need to have all of their content prepped and ready to go before design on a Web site even begins.  The other camp says this view is not realistic, content is always behind, and clients often need the design to inspire them to update their content.

So which view is right?  I actually think that both sides are right.  But I think the question is misdirected.  The real question is: how do we make content more important, earlier in the Web site design and development process?

Here’s something every Web design and development firm knows:  Content is often the responsibility of the client, it’s often delayed, and it’s the most common reason for delayed launches. A List Apart has a whole section on their site devoted to content strategy.  I love Bronwyn Jones’ article on how good design is not possible without good writing.  And I think Erin Kissane is on to something when she discusses content templates (not design templates) as a way to help subject matter experts put their knowledge down on paper.

Here is what I have learned about content, the importance of content to design, and coaxing good content out of clients:

How about you?  What content strategies have worked for your organization?  How do you get good content out of your subject matter experts?  And how do you blend your content development and design processes?

5 replies on “Which Came First? Design or Content? Neither, They Need to be Hatched at the Same Time”

Putting lorem ipsum text on designs may be easy, but it doesn’t give the client a feel for how their content will fit into the design. It’s better to use real content, no matter how dry, in the design comps. Just as some homebuyers can see beyond the blank walls and rooms, others need a home to be staged before they consider buying it.

What has client reaction been to that? My experience has been that, if the text is even remotely something that might be content, all attention immediately goes to fixing the text, and I can’t get any design feedback at all. Even using lorem ipsum, most of my clients try to read it first, then try to figure out what language it’s in, and what it says. Then I explain its purpose. Then, maybe, we can talk about design.

Hi Karen. Thanks for the comment.

You are right that some clients get derailed by the content. We recently had a design meeting that went astray because we paired the wrong cover with a featured publication.

That said, using real content has worked really well for us, especially when we present the content as part of the design. We did a design presentation the other day where we actually presented the news items, how the content would be presented and suggestions for what to put under News. The client loved it and said that we opened their eyes to using News in a more expansive way.

We will also do things like try to make their one-line description of the organization shorter, more to the point, keyword-rich and punchier. Sometimes, the client hates it, usually they love it, even if they end up tweaking later. AND, more importantly, content is part of the discussion, i.e., we show them how a punchy description enhances the overall design and user experience.

Our designers really prefer to insert real copy into their designs so they scour the existing site, we have our Communications Guru write copy, or the Project Manager develops/grabs/edits copy. Yes, there are still times when we use lorem ipsum text in a branding area or description of a featured publication, but we do try to avoid it.

I look forward to hearing more about your adventures with design and content.

I certainly remember clients reacting pretty positively, in general, to realistic content in my designs. There are a few hidden traps, though, in that designers (ie, me and my ilk) can get a bit lazy in their thoughts and add content and elements without regard to a carefully written specs document. This may not be a big deal if adding, say, styling for a blockquote block. It might be a bigger deal, though, if adding something like a magazine pullquote, that then requires a bit of development time in javascript to implement. It might be an even bigger deal if it’s an RSS feed below a news items list: the client may ask, the day after launch, “Where’s that RSS feed we saw?” To which the bewildered project manager will reply: “RSS feed?!”

As to the content debate, it can be difficult to write content in advance for the same reason that it’s difficult to implement a whole site in advance: both need clear goals and an architecture to structure them. Neither writing nor design on the web do anybody any good unless they are oriented very clearly toward a purpose. But if the goals are set (and written, and agreed to) early in the project, and the information architecture is clear and addresses the goals, I’m not sure there’s a good reason to insist that the copy for every page already be written. It seems quite acceptable, in that situation, to prepare a toolbox of page components, as you suggest, and pages with empty content blocks to the client to set them up the content writing.

Once again another timely post! We’re reworking the design of our Web site, and it has been difficult to balance how we want our content presented–and what content we want to present–with an engaging Web site.

Comments are closed.

Related Articles