It was suggested a while back on this blog by SitePoint’s own Matthew Magain as to Why The 10 Commandments Of Web Design Are Complete Baloney. In his post Matthew waxed lyrical about how content was realistically not that important to the designing of a web site. To an extent he is right, but he is also wrong—yes, this is another classic case of web design not being black and white. I’m now going to put to you the case for why content is still more important than design.
Now we all know that design and content can mean different things to different people, so let’s start with a few definitions:
- Design: the final visual interface design, the high-fidelity design for the site, not the interactive design or information architecture design, as these are separate to the final visual design process.
- Content: this is about having an understanding of the content types and the information that is expected to be delivered. Also to know what information the users are expecting to see from their previous experience. It’s not about having every last morsel of the copy for the site.
Just to be clear, I’m also not discussing the separation of content and design in terms of the developmental process—that’s an entirely different topic.
Design and the Small Site
When we design a small site, we are usually presented with a business direction and some functionality requirements, an idea of the audience, maybe a logo, or previous marketing material (if we are lucky).
These are all good design starting points and sources of inspiration—there usually isn’t much content at this point. The outlining of the site map for the site really just follows the generic “products, about, contacts” structure suited for brochure sites; there is generally nothing unusual that will present any problem here. And even if there is an issue, you can usually just add a high level item to the menu, after some consideration without much of a problem.
The detail of the content that is delivered later on may present a layout issue—for example, suppose you were suddenly presented with a series of short testimonials for insertion into a shopping cart site. However, because you can design the main content area to be very open, genetic and modular, this issue can be easily accommodated for.
In this case, design is more important than the content. But wait—what of larger sites?
Content and the Larger Site
When we consider a larger corporate site, other than the basic design specification information (as I’ve elaborated on above) there is also often a history of previous legacy designs, as well as a large amount of content both online or waiting to go online that needs to be considered. It’s at this point that the sheer volume of information starts to out weigh the design in the overall developmental process. This information becomes the driving force behind the web site, and it is at this point that content becomes king over design.
Ideally we really need to consider the content; I know this often isn’t possible on smaller sites, as demonstrated above. However when it is taken into account I have found that it allows for a considerably more robust design of a site in terms of the positive user experience it delivers.
When I design a site, I really want the design to flow with the content to the point that they become seamless. Sure, in reality that doesn’t always happen—I know I have worked on sites in which I have forced content into a design that just doesn’t suit the topic of the story or the conversation the site is having with the user. When that happens, it’s bad design, and it really needs to stop.
Understanding the content of a site completely before you begin any design allows you to glean a number of design elements that may not be specified, for example:
- The number of navigational areas that will exist on any given page.
- The width of the main menu buttons: if the information architecture is not complete, how else can you finalise the structure and labels?
- Any themes in the content that could be extended into the visual design, by the telling of a story or visual conversation with the user.
- Requirements for any breakout content such as testimonials, side comments, explanations, definitions or the like.
- The general length of the page coming from the amount of content that is going to be displayed.
- The use of new media elements, such as video, screencasts, inline audio players and the like.
- The length of the content title elements, and if you are going to expect them to wrap. Mind you, you should be allowing for this anyway, as you have no control over the fine details in the future content.
- The size and style of images: you really need to know if there are going to ever be large images, such as graphs, charts, or maps that often don’t scale well as bitmap images (JPGs, GIFs or PNGs).
- Allowance for marketing adverts, product links or ad-hoc content.
- Any other requirements for ad-hoc content, such as news items or emergency response information.
Without knowing any of this information you are just second guessing from your own experience the type of site the client and users really want represented in the design.
For instance, you could specify a minimum and maximum content area width size incorrectly, due to a requirement for the insertion of large maps on a section of the site. In this example, without knowledge of the content, as soon as the client inserts the large maps, they’re likely to suddenly find that the entire visual design breaks.
What of Content Management Solutions?
In the corporate and government sectors it is common to have the majority of the design in place before the content is delivered. This occurs when an enterprise level content management system (CMS) is used within the final solution. These content management systems vary; often only allow a reskinning of the base design template to complete layout customisation. In a way it could be seen that a lot of the design decisions have been made for you with the CMS implementation.
Isn’t this design before content? No — in such a scenario, the content is known, as in most cases the majority of the information architecture will have been finished before the CMS implementation. Having the IA completed means that a good deal of the design considerations will have been dealt with, as the information architecture looks in-depth at the content to design issues.
For any items that have not been covered off by the information architecture, I have often found, in the last few years, that the system design and development team for the CMS vendor have developed such a generic template design for the CMS that most of the design issues have been already taken into account. This will of course vary from platform to platform.
Like it or Not, Design Doesn’t Matter
Of course these points all become moot when you discover that users really don’t care a great deal about the visual user interface elements as long as they can find the content. Getting to the information is their primary goal.
Sure, they have to use the visual interface extensively to get to the information, even if it’s an application. At end of the day, though, they’re only focused on one thing — the content. If the content is poor or unfindable, they will leave, no matter how pretty the site is.
This is why getting the information architecture right is so important; it’s also why content is king.
Image Attribution: Mark Coggins
Gary Barber
