to close

web design paper

This is the web version of a paper that I wrote in December of 1998 for my former employers, Talking Dog Media, to prepare for a meeting about the complete redesign of our website. As I started making notes, I realized that what I really wanted was a complete guide to the approach I felt we needed to take to web design. This is the result.

This document represents the accumulated notes and thoughts I have been preparing over the last few days for the overhaul of the Talking Dog website. The following design considerations were written with an aim toward our own website, but can also be taken as a more general philosophy and approach toward web site design.

I would hope that this document could be viewed as the beginnings of a Bible for how this company approaches web page design; but at the very least, please do think of it as Luther's thesis nailed to the door of the Cathedral at Wittenburg.

Primary Considerations

There is really only one consideration that should be held paramount when designing a website, and it's the same consideration that drives software design as well:


That's it. Everything else is just a variation on that simple idea, or just window-dressing. A website has to be simple to use. There is information on a web page -- in our case, information about who Talking Dog Media is, and what we can offer a client -- and the user has to be able to easily reach that information. If they can't get to it easily, they won't bother to get to that information at all.

For that reason, it is more helpful to think less in terms of simple design -- that is, a simple aesthetic judgement of what looks visually appealing on the page -- and more in terms of Information Architecture -- or in other words, how the order and flow of information presented on a web page will lead the user to use that page to get the information they want. Designing for the Web isn't like designing for print; we have to make sure our pages don't just look good, but work well as a user interface.

Don't think for a second that I'm just talking about dry, boring, standard text when I'm talking about "information." Information isnt just a list of facts. Everything on a website is information. Pictures, logos, font choices -- these are also conveying information about what kind of company we are.

Now. In order to design an architecture for our information, we first need to decide what kind of information were going to present. I don't think we've generally done this. Looking back at websites we've designed in the past, as well as at our own, I think we generally tend toward what I would call a "Top-down" design versus a "Bottom-up" design.

Top-down and Bottom-up Design

A "Top-down" design means that we approach a site design with an idea of what kind of categories the site should have, and then we create content downward from that initial picture; we develop pages to fit those categories.

I don't agree that this is the best approach. For one thing, it's limiting; once we've established what our categories are going to be, it discourages any kind of thinking that would break outside that envelope; we can just head safely down the routes we've already mapped out rather than charting off into unexplored territory. For another, it forces us to develop content that doesn't grow organically out of the needs of the site. For example, on our current website, we have a section for games -- and under that section, we have just one game.

I would rather see us develop our website using a "Bottom-up" approach. Start with the content. Figure out what all the different things we want on our site are. Develop all kinds of ideas for pages. Go crazy, be creative. And only then, when we know what it is we're trying to categorize, should we even begin to think in terms of categories.

Jakob Neilsen, Sun Microsystems' expert on website and user-interface design, favors an approach of sketching out the different pages for a website on index cards, and handing them to potential users you've brought in for testing, and seeing how those users organize the cards to see what categories evolve from different perspectives. While we may not necessarily want to go so far as to bring in outside help, we should certainly be open to reshuffling our own categorization as we evolve content.

Questions We Should Ask

There are several factors to consider as we approach these considerations, and they can best be thought of as a series of questions:

A Possible Mission Statement

"Our website must accomplish the following goals:

"As we will be developing websites for clients, and clients will be judging how well we represent ourselves to determine how well we could represent them, the website itself must reflect our best site design skills;

"As we are a multimedia company, our website must provide samples of our work that our clients can see;

"As we are a personable and creative company, our website must reflect our attitude;

"And as we intend to attract clients internationally, our website must provide a useful point of contact for our clients, allowing them to see work in progress when appropriate and providing them with the means to give us feedback."

Questions the User Will Ask

We've already determined what questions well be asking ourselves in creating the site. Now to consider what the user will be asking as he uses the finished site. From any point within the website, at any page, the user will be viewing the page with three questions in mind:

  1. Where am I? A user must have a clear idea at all times where the link he has just followed has landed him. All pages should be clearly identified, not only as our pages (with our logo clearly displayed), but with regard to where the page is within the hierarchy of our site.
  2. Where have I been? Surprisingly, users don't tend to rely on the Back buttons that exist in web browsers -- if a page doesn't provide a clear "escape route" back the way they came, users tend to get lost and disoriented quickly. All pages should have a link back up to the higher level of the hierarchy and a link back to our home page.
  3. Where can I go? We must be certain never to lead the user to a dead end. We need to provide links on every page to content on our site that relates to the page that they're currently viewing; either related by content, or by hierarchy.

Designing Simplicity

The overwhelming consideration for making certain that our pages meet our criteria for ease-of-use is simplicity. We don't want to overwhelm the viewer, to bombard them with flashy design elements to the point where they are unable to single out useful elements or understand the structure of the page.

IBM's Ease of Use Web Design Guidelines can say this better than I ever could:

"Your words and your design will be more powerful if you can say more with less, so be rigorous about eliminating superfluous elements. Every element of your design should support the goal of your message. While using purely decorative elements is legitimate, keep in mind that a tremendous amount of information is competing for users' attention. Information overload can cause discomfort and prevent users from finding the information they want to find."

To begin with, we need to be certain that the text on the page is readable. It's too easy to design a graphic that has text in it that might be a little small and hard to read, and to decide that it's good enough. It isn't. How easily readable the text on the page is should be the first consideration, not the second. The page exists for no other reason than to communicate. If people find it difficult to read the page, they won't bother.

There is also a technical reason to consider simplicity of paramount importance -- having a large number of huge graphics on a page increases its download time.

The Yale Center for Advanced Instructional Media's Web Style Manual correctly states, "Users will not tolerate long delays. Human-factors research has shown that for most computing tasks the threshold of frustration is around ten seconds." (The emphasis is mine.)

Note here that the whole experience of viewing the page is crammed into that ten seconds. Downloading the page, seeing it, understanding it, orienting yourself as to where you are and what you can do next, getting interested in the pages content -- all that happens either within that first ten seconds, or it doesn't happen at all. The user hits that frustration threshold, and then hits their Back button and leaves.

It's the fastest sales pitch we ever have to make. And simplicity is the key to it.

We have to simplify the design to make it obvious to users what they can do (and, when appropriate, what they are expected to do).

Note that the more complicated a design is, the more eye-catching each and every element, then it becomes nearly impossible to judge the relative importance of those elements. Sun Microsystems User Interface Design Guidelines say, "if everything is highlighted, then nothing has prominence."

Designing Visual Elements

The visual design of a web site should function as metaphors for navigation. This rather highbrow term simply means that visual elements of a website shouldn't be purely decorative, but should, again, be a means toward ease-of-use -- that they should help the users get to the information they're looking for.

Notice the term I'm using there: Get to. That's what we do with information; we get to it, we search for it, we find it. These are all spatial metaphors; it's how we understand things, even something as abstract as information. On one end of a web transaction is a sophisticated, modern computer; on the other end of the line is a person who, for all of the thousands of years of civilization that's developed, has millions of years of background as a hunter-gatherer.

To help that hunter-gatherer, graphical elements should convey concrete, physical metaphors. Up. Forward. Back. Motion.

Or they should represent concrete physical objects that still convey useful means of navigation; a magnifying glass, a telescope, a book, a file. Icons often communicate completely different information to different users, and its not always the information you'd expect them to. (This is one area where user tests are critical.)

Sun's UI Design states: "Your interface metaphors should be simple, familiar and logical to the audience -- if you want a metaphor for information design, choose a book or a library, not a spacecraft or a television set. The best information designs are the ones most users never notice."

Another visual motif that we might consider is to play into the idea of our name, Talking Dog. It often helps the user to have a sense that they have a guide leading them through an information structure (although preferably one less annoying than the little paperclip in Word 97). We might want to consider having a little graphic of a dog on the page, communicating with the user through word balloons, telling them where they could go next.

Along with appropriate visual metaphors, of equal importance to our visual design is what we don't put on the page; in other words, our use of white space, or negative space. Without the negative space used here on this printed page, this would be much more difficult to read -- if this had no margins, for example, and the text covered the entire page. Or if there were no space between paragraphs.

This is even more important on a web page than on the printed page. Consider the human eye moving back and forth across a screen, a screen thats radiating light into their eyes rather than gently reflecting it off of a piece of paper. Negative space gives the eye a chance to rest, and given that chance, the eye perceives the page as clear and inviting.

Hyperlink Design

A hyperlink, whether it's a graphic or a text link, needs to perform one function: let readers know what they are committing to.

To use an example of where our current website does not perform this function, consider the button on the main page: "Ok... What kind of dog is it?"

A user trying to puzzle out what might be behind this button might think that it had information about the company, or what kind of dog the company was named after, or any number of things, but the user almost certainly wouldn't expect to find a game behind that button. This is one example of how our current design fails to correctly set the user's expectations of what will happen when they click on a link.

As a result, the user may not click on the link at all; or they will be confused at what they find if they do.

The titles of all links must be concise, accurate, and explicit. There must be enough detail present for a user to know exactly what is behind each link; but all that detail must be crammed down into a space that can be easily and completely grasped and understood at a glance. People don't read web pages. People skim them.

What attracts a user to a link? Size is one factor. Ameritech Corporation's Web Interface Standards and Guidelines states, "In general, the larger an item is, the greater it's perceived visual importance and likelihood of attracting attention."

Color and, if used sparingly, motion (animated GIFs and rollovers) also attract users. Remember the hunter-gatherer looking at your page. As Roger Black's book Web Sites That Work puts it:

"There are certain hardwired facts about human visual response that you'd be a fool to ignore. Like instinctive reactions to colors. Red is nature's danger color and is a great way to add accent to a black-and-white page."

Colors and motion trigger those hunter instincts. They turn hyperlinks into vivid, living objects that the hunter instinctively wants to reach out and grab.

But obviously, if the user is presented with too much color, or too much motion -- or motion that doesn't make sense, that doesn't provide a clear visual metaphor -- then the eyes wont know where to look first. Simplicity again.

Site Structure

How deep should our site be?

According to William Horton's book Designing and Writing Online Documentation, research suggests that users begin to lose their bearings within a hierarchical structure once they go deeper than three levels into the structure. As Horton notes, flat hierarchical structures may cause users to have to scan longer lists of menu items, but users "will get lost less often." This is advice we should follow.

I also feel that we definitely need to cross-reference our whole site; that we should link to other relevant sections. After all, our clients, as corporations, will have a variety of needs that we could theoretically fulfill. If a client comes here looking for web page development services, they still might be interested in, say, print advertising. We should make it seductively easy for them to get from one section of our page to another.

The Opening Page

The Yale Web Style Manual draws a comparison between the opening screen of a web site and a magazine cover:

"The objective is to entice the casual browser with strong graphics and bold statements of content. All the links on your home page should point inward, toward pages within your site. Provide a very clear and concise statement of what is in the site that might interest the reader."

Ameritech's Web Interface Standards and Guidelines puts it even more simply: "Display the site's available contents clearly on the home page; inform viewers about what they might find and what they could do."

Here is an example of one approach we could take to the redesign of our main page:

Graphic of site redesign proposal

This is probably not the approach we want to take in the long run, as it places no emphasis on Distance Learning. But it serves well as an example of the principles under discussion. It immediately provides the viewer with a sense of place, of who and what we are; using concrete, physical graphic elements and clear, readable text, it provides clear and concise labels for the content that is behind the links; and it provides nothing else to distract the user. It's an example of a simple, clean design.


Although we might be tempted to consider the battle won if we can simply entice the users to open up the links on our main page and have a look inside, each new sub-page presents us with a whole new opportunity to lose their attention.

According to studies done at Sun by Jakob Nielsen, less than 10% of Web readers ever scroll beyond the top of web pages.

If this were a web page, that means that 90% of the people reading it would never have read this far.

Is there a way around this? Yes, there is. We can break up pages into smaller pages when necessary, to try to get them to fit into one screen if possible. We should also adopt journalism's "inverted pyramid" scheme in our writing for the website -- provide the most important information first, within the first screenful.

We should also, especially on longer pages, include navigational tools -- not only to access other pages on the site, but to reach sections within the page itself, so that users don't have to resort to using the scroll bar.

Technical Considerations

There are few technical issues I would like to raise. There are a couple, however.

First, I would like to note that the proposed scheme that's been put forward of offering a Java version and a non-Java version can be handled more elegantly. We can create a front page whose links will take users to one version of a sub-page if they have Javascript running, and another version if they don't. We could also make similar distinctions for Shockwave, Flash, and so on. This would be transparent to the user and would give us the best chance to show what we can do without making users who don't have such options in their browsers feel left out.

Secondly, I would like to urge that we use Flash, Javascript, and other such neat "toys" as much as possible without sacrificing the simplicity and elegance of our design. These tricks should, as much as we can manage, actually enhance the users ability to navigate the site, rather than simply being frosting on the cake. However, I feel it's important that we have them on the site so that we can demonstrate our proficiency in such current web technologies to our clients, who will surely want them for their own pages.

Finally, for similar reasons, I would like to have as much as possible on our pages be interactive. One suggestion thats been raised is to have a form available for people to fill out and submit to us so we can get back to them with a quote. Not only is this a fine idea from the sales and customer service angle, but it also enhances the user's experience -- they get to do something, not just be a passive observer -- and again, it lets us show that we can create such forms for our clients.


Again, I would like to point out that most of the issues raised in this document are not issues of a technical nature. That's because all technical considerations are of secondary importance.

The important thing about our website is not that it be a top-notch technological marvel, but that it reflect good, solid, clear principles of design.

Thanks for your consideration.