Content-Heavy Websites: A Better Design Process
Since the beginning of time (i.e. August 6, 1991), we’ve been working on perfecting the process of creating websites. We have a large number of things to take into consideration: planning, architecture, design, development, font-end coding, testing and deployment. The general process most web design firms use goes something like this:
This approach may work well for certain kinds of projects, but when it comes to large, content-heavy websites with a large number of page types and content types, there is room for improvement. A lot has been written about “Content First” approaches to site development (Luke Wroblewski, Jeffrey Zeldman, Georgy Cohen), especially in the age of responsive design. These ideas are all well and good, but in the real world, having content developed before initiating the site build isn’t usually realistic. However, we can include content in the process sooner and more often than we are now. Much of the work in the emerging field of content strategy focuses on exactly this approach.
Content Development is Hard!
Let’s get this out of the way: content development is always, always, always the hardest part of a website project. Yet how often do we underestimate the amount of effort it takes to collect, analyze, write and edit good site copy? And don’t even get me started on imagery. Hours spent, from needle-in-the-haystack scrolls through stock photo libraries to hiring illustrators, turning those beautiful design comps into something that works in reality.
Think about it: the whole reason you’re building a site is to get your point across, right? Yet, time and again, when it comes to large-scale websites, some design firms (and clients) treat content as a separate part of the process that happens in tandem, but separately from design and development.
The problem with this is that once the visual design work is done, unless a design firm is handling content development as an integrated part of the process, clients are asked to create and/or massage content to fit idealized designs.
Now, this isn’t always a bad thing; sometimes a little structure is good to help rein in content. Good design comps can help give clients an idea of how a new site design will help them frame the discussion, but rarely do the results live up to the promise once the designs have been approved and development and theming commences.
The Discontents of Content
As a Producer, I’m at the epicenter of bringing content, design and technology together. I’ve begun to realize that approaching a website by designing lots of great-looking comps and/or prototypes, building them, and then populating with content can be problematic.
When it comes to large, content-rich websites, you can run into serious trouble when the real content is integrated into the idealized world of site design comps. Symptoms include: content that doesn’t consistently fit the templates, content that exists but has no place to live, content that breaks the visual designs, and so on.
And this problem extends to the development side as well: when final content is delivered after CMSs are architected, it rarely fits into the neat little boxes we create to support it—or unanticipated content creates problems, forcing the redevelopment of pages or features.
For many projects, after content is entered, there is a period of fixing where designers and developers spend countless hours work together to get the pages to “work” — tightening up all the loose ends and pushing ever closer to those idyllic design comps the client (and designers) fell in love with. This introduces a painful period of rework into the process:
But this duplication of effort points to a flaw in how we plan and design for the real content.
Given all of this, it seems we need some “content reality checks” along the way. Ultimately, the real content must meet the real designs and decisions need to be made when there are issues. If we can have add checks throughout the process, we would save a lot of time and money. Something like this:
Two things are different here:
- There are periodic checkins between the content developers, the designers and the developers. The designers and developers should have access to some of the content plans and the content developers need to have some idea of what is going on with design and development. There is a lot of efficiency to be gained if visual designers, developers and content developers can work together more.
- Deferring Theming (which includes front end coding and its integration with the CMS) until at least some representative content is entered into the CMS allows the front-end coders to make real-life decisions on how pages will render. This also prevents them from having to refactor their front-end code to handle last-minute changes to the site. Additionally, this is a major boon when working on projects with a responsive design component, as the front-end coder can test real-world content on a variety of devices and screen-sizes while they’re coding.
A More Integrated Approach
If more of an effort is made to incorporate content strategy and content development into the design and development process and periodic checks are made at all stages (design, development, theming, etc.), a lot of time and effort can be saved.
The finished product will then be what is meant to be: content, design, and technology brought perfectly together to communicate with the audience.