Prototyping Website Content

Working out the structure, categorization, grouping and labeling is actually the easy part of website information architecture. Representing content details on each page is much harder. Of course the final site copy is never ready at such an early planning stage, so we use Greeking copy (Lorem ispsum dolar) in place of final copy and blank images as place holders for final images. However, we do represent the intent, length, and detail of all content expected for each page. Some pages may just have a sentence or two, others may have multiple paragraphs with images, captions, and tables.

This ten minute video shows our process of grayscreen prototyping.
To embed this video on your site copy and paste this code:
<embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=-1308138296088477010&hl=en" flashvars=""> </embed> <br>Grayscreen Prototyping video by <a href="http://www.newfangled.com">Newfangled Web Factory</a>.

It is extremely important to represent content in detail, albeit without the real words and images, even on simple pages. Take a "jump off" or what we sometimes call a "table of contents" style page for example. Let me explain why a "table of contents" style page is sometime necessary. Some main site tabs exist primary as containers for the subpages under them. A travel site, for example, might have a section called "Destinations." Its subpages could be broken up by type: Island Getaways, Ski Resorts, Cruises, and City Tours. Each of these subsections would have considerable content, but the "Destinations" page itself might not have much else to say other than "Here are the pages that talk about our destinations."

The content on these kinds of pages is often overlooked in sitemaps and wireframes. But since the page exists, it will have to have something on it. So when we prototype, we make our best guess at how such pages should be formatted. We'd probably show a few lines of introductory "lorem ipsum" text and then list each destination as a link with short description and a "more" link. Maybe we'd throw a thumbnail image next to each item too.

By detailing the content on this simple page, the client and project manager will stop to consider it. Had the prototype merely displayed a few links that read "subsection one," "subsection two," and "subsection three," the client and the project manager would fly right past the page during review.

But with detail to respond to, their review and discussion can lead to important discoveries that might save time and frustration. Here are a couple of ways such a conversation could go.

Project Manager: "We've represented the destinations page with a few lines of intro copy and links to the four subsections, each one having a short description and thumbnail image. We call these kinds of pages "table of contents" pages because they don't serve much purpose other than directing people to the content that lives under them. In most cases, because of the way drop down menus work, most users won't actually go to these pages. They click through directly from the menu bar to the subpages. Do you feel this format will work for you?"

Client: "Well, actually we want people to see this page. Our packages have seasonal trends so we want to promote certain ones at various times of the year. We thought the main destinations page would be a good place to do this."

In this scenario we might discuss ways of working a destinations overview page as the top option in the drop down menu so people would be less likely to miss their important destination overview content. We'd go back and add more detail into the prototype to represent how they might promote their destinations on this page. This conversation might also lead to ideas for including promotions on the home page, or functionality requirements like date-based control over when promotions display.

Project Manager: "We've represented the destinations page with a few lines of intro copy and links to the four subsections, each one having a short description and thumbnail image. We call these kinds of pages "table of contents" pages because they don't serve much purpose other than directing people to the content that lives under them. In most cases, because of the way drop down menus work, most users won't actually go to these pages. They click through directly from the menu bar to the subpages. Do you feel this format will work for you?"

Client: Well, if this page is not usually seen, I think we can ditch the thumbnails. We don't want to have to pick images for a rarely viewed page. And could we just pull the first few lines from the subpage's main content as the abstract so we don't have to write text for all of these table of content's pages?

In this case we would actually simplify the prototype and minimize the amount of content the client would ultimately need to work into the final site. We would add a programmer note to remind the developer, when it comes time for coding, to display an abstract for each destination from the destination subpages.


I've used a simple page as example of how detailing content on every page can either help refine or simplify the site. These details need to be considered sooner or later. Otherwise the developer might not build the pages right, or the client might get hung up in content development. When these elements are glossed over they don't go away; they just surface much later. As a result many pages get re-coded, usually under the pressure of a looming go-live date.

And if simple pages have potential for illusions of communication, how much more complex aspects of e-commerce, account management systems, and customized applications?   next >