Some advice to designers of news websites

This morning I ran across a note at drupal.org from a beginning designer asking for a critique of his attempt to design a news site. The attempt led me to focus on some weaknesses that are common to many professionally designed sites.

There are too many "redesigns" of news sites, and the typical redesign process is set up for failure. It goes like this:

A new entity takes over the site. Maybe there's a restructuring that places the site under the control of the newspaper editor. Maybe it's a change in new-media directors. Maybe it's a designer. The goal of "make this work for the user" is inadvertently eclipsed by "put my mark on my territory." That's the wrong reason to begin with. You are at high risk of replacing one set of design errors with another, and needlessly pissing off your users in the process.

A committee is formed. You always need to pull all the stakeholders into any design process, but you have to have a more clear structure than is provided by a committee in which everyone has a different idea of how decisions are going to be made. You need to be absolutely clear about who plays what role: Sponsor, Facilitator, Contributor, Designer, Builder, Passenger, and most especially, Decisionmaker. Some people may play more than one role. Lack of clarity about roles, responsibilities and process sets you up for failure.

The wrong skillsets are put into play. Designing a news website requires a deep understanding of the content that is being displayed. If you're not a hands-on production editor, you may not realize that the proposed design is ultimately unsustainable because the available content won't support it. And design committees tend to contain many opinionated executives who want to argue about fonts and color, and no actual line editors. Keep in mind, too, that art and illustration are not design, and that someone who's good at building mockups with Photoshop may not necessarily be any good at information architecture or envisioning the interactive experience or delivering a usable system.

Somebody has to build this, and the real world needs to be considered before you get carried away. If your design process isn't informed by a full understanding of the CMS you're using, you may conjure up something that costs you far more to implement than it's worth. Real design is a process of compromise. Don't get surprised by that at the wrong stage in the process.

In many redesigns, the unstructured and underskilled committee engages in a painfully drawn-out process that leads to round after round of debate and argument about personal preferences, color choices, font sizes, etc., while underneath it all there's a process of jockeying for political advantage in the newsroom. All of this happens around a consideration of just one page -- the home page, the Web's equivalent of the holy Front Page, the focus of all power and glory in any newsroom.

Eventually the exhausted combatants grudgingly agree on a "design" and slink back to their offices and leave the field of battle to the builders.

But the job isn't done! In fact, it's not even begun. You haven't really built a news site design; you've just modeled one display page.

When you build a news site, you have, at a minimum, three radically different types of displays to design:

The home page, which focuses on recommendation and navigation. Depending on your information architecture, you may need several similar section pages.

Simple list pages, which display collections of similar things and allow the user to burrow down and make choices. The "river of news" or "headline/teaser" view that Drupal provides at /node and /blog is an example of such a page. These pages have a different mission than the home page and section fronts, and the designs should reflect that.

Story pages, which present a single story and all of its assets, but also entice a reader to explore contextually related resources on the site (or elsewhere on the Internet). Many designers fail to recognize that a story page is every bit as important as the other two primary types, and as the proportion of traffic coming from search engines and links continues to grow, the importance of designing a great story page begins to eclipse the rest of the project.

These are just the beginning, of course. The system we put in place last year at the Florida Times-Union has more than 30 content types.

When you design pages, keep in mind that you also are designing a site, which means that you need to make it clear how pages hang together into a coherent whole.

The primary tools for creating a sense of hierarchy are not limited to the taxonomy or menu system and breadcrumb trails; you also need to consider the choices you make in font sizes and other graphical elements and how those choices suggest a membership in a broader collection of information.

Take a good look at http://www.nytimes.com/ beyond the homepage. Study how each page type uses a template that helps reinforce its position in a larger sense of order, as well as how the choice and arrangement of typographical elements within a page conveys a sense of order within the pageview.

We've been redesigning the Columbia Missourian Web site over the spring and summer, and we've been trying to be very aware of the front/section/story hierarchy you talk about. We actually started on the front page, and then decided after a couple weeks it wasn't the place to start. Among other things, something like 80 percent of our traffic comes through search and goes directly to a story page, so we threw out what we had and started over with story pages. Once we did the story pages, we started with section pages, and we wound up just making the front basically an uber-section page, using a lot of the assumptions we had about section pages and how we build them to inform the front. One thing we're trying to do is offer the ability to display any tag as a reverse chron list of headlines, or quickly create a designed section page on the fly based on any tag or subject. It's been an interesting process.
PS I couldn't figure out how to indicate who I am -- Rob Weir, at the Columbia Missourian/Missouri School of Journalism. WeirR at missouri dot edu.

I think that committee's can be too bureaucratic in redesigns sometime. It reminds me of the difference between a startup and corporate culture. You spend more time meeting and arguing over things than actually implementing the changes. During one redesign process I took part in, we met once a week to check in on progress and go over features. Once a week is sufficient, and maybe even too much.
I would say the biggest advice, as you note, is to be flexible. During a redesign process you will learn things that you thought were possible aren't and if you get stuck on one feature that you can't implement, then move on and come back to it. Keep the process moving. Redesigns should be more of a constant process, I think. When you completely change your site, it tends to scare some of the readers away that have been comfortable with it for some time (of course, unless it is completely terrible).

Was a veteran of several redesigns at The Wall Street Journal Online (not that the problem was in any way unique to them), and saw everything you warn against unfold every time. From hard experience, I'd add to your wise warning about skillsets and the real world this caveat: The presence of a hands-on production editor in the room can guard against the designers writing a check you don't have the staff resources to cash, but only if you actually listen to that editor.