I've done a lot of talking and writing about a content-first design process lately. The advantages of getting your content ready before a redesign are many:

1. Fewer website delays while waiting for content to be ready
2. A website that meets user needs
3. Better return on investment for your website
4. Earlier buy-in from entire organization

Those are very important benefits. But what does a content-first design process look like? What are some specific ways this approach to web design makes a difference?

One quite obvious difference is in providing feedback on visual design. Here are examples of design feedback I have given, one for which real content was developed and given to the designer and one for which the designer was left to use lorem ipsum.

Design before content

For the design without content, these were my comments and questions:

1. Is [text] the page name or section name?
2. What is the purpose of the boxes about halfway down the page?
3. What content would go below the schedule?
4. What text will go into the slides? Is there a character limit? Is button text changeable?
5. Is the second ribbon text different from the first?
6. What does "Stay Connected" mean?

Without having real content in the design, I could not provide objective feedback on whether the design supported the content and made it user friendly. Feedback was limited to asking questions which do not have answers.

The designer made something that looked good. It followed current web design standards and trends. The colors could be debated or compared to an existing brand palette. But there was no way to comment on whether it told the right story, because there was no story to tell.

Approving this design would mean having to make content fit fairly random design decisions. There would be no way of knowing whether shorter or longer bits of text would break the design. There is no way of knowing what would happen if there was no content for a specific design element. Everything was just a design element when they should really be content elements.

Content before design

For the design that had real content to support, these were my comments and questions:

1. We may not always have photos for a project - especially in [specific] project type. Having a beautiful hero image photo works great for something like [the project we're using as a sample], but will be harder for many of the other projects.
2. On the category/headline/summary element - Will people know that the category and project name are links? This is always a struggle, and I want it to be true, but this is why we end up with the "Read about project" at the end of all the blurbs. What does your experience tell you? Also, maybe use the words "Project Name Goes Here" since these will not be news stories.
3. [For client] - Is using the word "Donate" for many of the button styles going to be a problem? We all know these are just examples of buttons, but the people who don't want this site to be about donations may fixate on the word.
4. For the phase buttons:
   • We've only identified 3 stages: Design, Construction, Completion so best to show and use those words those rather than 4 with "Phase I, Phase II, etc"
   • [For client] - will there be dates for each phase? My guess is for some we can be specific for others we can't. It's nice to see if we can, but will that be awkward to have some projects with dates and some without?
5. I like the quote, but so far we don't have any content that indicates we will have any pull quotes or quotes. I'm fine with having it as a style but wonder if stakeholders will ask where that will go and where they will get them. I suppose it's possible on the home page, but we haven't gotten there yet.
6. Should we have an element for a call out box? We have this specified for the Project display. If you do that, use this text: "Public meeting for this project on: March 21, 2017. Meeting Room A, New York Public Library" ([For client] - is this a realistic potential location? Would we need an address too?)

You can see the difference in the type of feedback for this. There is no question about what things are. Only about whether they are effective. We were able to have discussions about whether the content was represented in a user-friendly way. We could determine if the various design elements matched their specified content elements. There was no lorem ipsum, only real content that would ultimately be used on the live site. We were able to get rid of potential distractions for stakeholders who would see the design without all our background.

With this type of feedback, the client could make decisions about whether they could support new ideas for content elements that sprung from the design rather than thinking about whether it looked good.

Better feedback

As Sarah Richards says when talking about content design,

"The design influences how you write and how you write influences the design."

None of this is to say that designers can't have ideas at this stage. Not at all. What it does say is that designers have a different job when they are bringing content to life with a visual design than when they have to create a visual design. We can have more productive and objective discussions when we are critiquing with clear goals in mind. It will also reduce the number of revisions needed, which saves time and money.

Website design should be design with purpose. Designing with real content gives the design purpose.

How has designing content-first helped your organization? Leave a comment to share your success or challenge.

Ready to design your content first? Get in touch to talk about how we can make that happen. that happen.