• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL



My career as a designer of interactive products began on the Labor Day weekend of 1990. My poor parents still aren’t sure what I do, and unfortunately, they’re not the only ones. Although my tenure as an interactive designer has been accompanied by an explosion in the complexity and quantity of interactive hardware and software products, the art, discipline, and craft of interactive design in general and Web design in particular remain a work in progress.

For better and for worse, the Web’s openness, accessibility, and technical flexibility have enabled, if not encouraged, individual solutions to what are often collective problems. A behavioral convention or visual standard on one site might be completely different on another site. The result is a level of inconsistency detrimental to both individual users and to the Web as an interactive medium. Unfortunately, because the Web lacks a central authority to recommend, encourage, or impose consistency, the description and adoption of relevant conventions are typically preceded by years of evolution, inconsistency, and confusion.

Exacerbating the situation, the sheer newness of the Web and the speed at which it’s been adopted, has failed to provide the time to develop the comprehensive methodologies, processes, or disciplines necessary for the consistent, controlled creation of truly useful and usable sites.

Goals and Objectives

It is these two concerns—inconsistency in implementation and inconsistency in approach—that led me to write Making the Web Work. The goal of this book is two-fold. On one level, it sets out to describe, analyze, and recommend solutions to common Web-based interface problems. At a higher level, it also sets out to provide a standard methodology for deconstructing and prioritizing the issues involved in the design of interactive products in general and Web applications in particular.

My hope is that Making the Web Work will serve as a catalog and critique of some of the visual and interactive conventions in use on the modern Web. I also hope my analysis and critique will add to your understanding and appreciation of the discipline of interactive design as well as your own ability to practice that discipline. Finally, I hope the process and methodology of my analysis will serve as a useful illustration of how to systematically deconstruct an entire application into a collection of separate but interrelated problems.

Put another way, I hope that in these pages I have given you not only a few fish and a few good fishing tips, but also a method for thinking about the practice of fishing and how to ensure that it’s repeatable, sustainable, and well-managed.

Why I Wrote Making the Web Work

There are a lot of different reasons to write a book. Some authors have a particular perspective to advocate; others have a story to tell; still others, an event to report. The more altruistic say they want to give something back to their readers. I decided to write a book because I wanted to learn how to be a better designer. I wanted to develop a deeper understanding of what I had been doing for the past decade, and the best way I knew to do that was to try to explain it to somebody else.

Surely you will disagree with things you read here, and even if you don’t, there will certainly be plenty of others who will. That’s fine. Part of the fun and interest of working in the field of interactive design is the uncertainty and complexity of it all.

As you’re reading, keep in mind that I don’t have the answer to the problem you’re trying to solve. I don’t know the problem you’re trying to solve. What I do have, however, is experience with similar problems and a way of thinking about them that you may find useful. Between these pages, you won’t find any magic solutions, “Tips and Tricks,” or “Top 10 Dos and Don’ts.” Instead, you’ll find an analysis and approach to the problems you’re likely to encounter during the process of designing an interactive experience, be it an entire site or one small feature. I don’t expect anything I say here to be the last word. In fact, I hope that in many cases it is but the first word, and look forward to continuing the conversation. You can reach me at bob@baxleydesign.com.

Who You Are

Like a design project, when you sit down to write a book, it’s important to consider who’s going to be doing the reading. For Making the Web Work, I envisioned three types of readers:

  • Practicing designers. These are the people “on the ground” with the day-to-day responsibility of solving design problems. If you’re an experienced part of this group, I suspect you already perform the type of analysis presented here; however, my catalog of problems and solutions may shortcut some of your own efforts. On the flip side, if you’re a relative newcomer, my analysis and methodology may aid your understanding of the unique challenges and methods associated with interactive design.

  • Product marketers. If you work in product marketing and don’t have the support of a professional designer on your product, and so the responsibility for design decisions likely falls to you. And even if you do have a dedicated designer, you probably still have significant input on many design decisions because different solutions invariably have unique cost/benefit profiles. If you fall into this camp, Making the Web Work will give you an understanding of how to approach and prioritize the issues and decisions you’re likely to encounter.

  • Software engineers. Even in organizations with robust design resources, chances are good that the engineering staff outnumbers the design staff at least 10 to 1. If you’re an engineer, you already know that any specification is unlikely to fully capture or anticipate every permutation and corner case the code must ultimately address. As a result, it’s not uncommon for you to have to make decisions affecting the design. For you, Making the Web Work will provide a method for considering and prioritizing issues according to their impact on both the code and users. In addition, it will give you examples of the analysis designers typically use to solve problems and highlight some of the best practices currently in use on the Web.

What You Will Find

This book starts with the assumption that you have an interest in creating Web sites that are easy to use. It presupposes the basic tenant of user-centered design: Products should serve the goals and desires of the people consuming the product, not the goals and desires of the people or organizations that created them. If you don’t enter this book with at least an open mind about the value and role of design, we’re going to have a difficult time.

Making the Web Work is divided into five parts. Here is an overview of what you’ll encounter in each part:

Part I, Foundations, sets the stage for the rest of the book by defining common terminology, outlining the typical phases of the design process, and presenting a comprehensive model for deconstructing and prioritizing an entire application.

Part II, Tier 1: Structure analyzes the key aspects of designing the overall structure of a Web application.

Part III, Tier 2: Behavior, addresses the behavioral aspects of a Web application’s user interface. The part’s chapters delve into designing navigation, manipulating the state of the application, editing information, online help, and reporting errors.

Part IV, Tier 3: Presentation, discusses the visual and textual presentation of an application. The part’s chapters address page layout, table layout, typography, color, and visual style as well as labels and other textual elements.

Part V, Case Studies, synthesizes the concepts introduced in the preceding parts, demonstrating how the best sites on the Web solve interface problems:

What You Will Not Find

In the interest of setting appropriate expectations, it’s good to know at the beginning what you will not be getting in the end. I have deliberately excluded a variety of topics not because I don’t think they’re important, but because they are well covered in other books.

Although it is a common component of books about interactive design, you will not find anything here about user research, including usability studies, ethnographic studies, contextual inquiry, market research, or focus groups. Certainly, these functions offer important input into the design process as well as validation of the design’s results; however, the focus of this book is the design activity itself.

Similarly, there is nothing in Making the Web Work about the technical details for implementing any designs. Although successful designers must have intimate knowledge of their medium’s abilities and limitations, I have chosen not to provide that knowledge here. If this were a photography book, you might say it covered composition instead of chemistry.

A more thorny exclusion involves requirements gathering and task analysis. Although both activities play a critical role in defining the problem the interface has to ultimately address, these topics are more closely related to the larger issue of product design in general than to interface design in particular.

Clearly, these topics have an important role in developing and creating Web applications. You should not assume from their absence that I don’t think them important or that they shouldn’t be part of the designer’s vocabulary. For a detailed bibliography and recommendations for a variety of book and resources, please visit my Web site at www.baxleydesign.com.

Conventions Used In This Book

In addition to deciding what to put in and what to leave out, writing a book forces authors to standardize terminology and other conventions. Sometimes these decisions have philosophical implications; other times they’re simply ways to enforce consistency. In either case, I’ve settled on the following standards.


User interface versus user experience: The sudden and dramatic influx of graphic designers into the interactive design arena has been accompanied by a host of new terms and job titles. One of the most popular is “user experience.” As I understand it, user experience encompasses every aspect of a person’s interaction with an organization—everything from the company Web site, to customer support, to shipping labels, to how the receptionist answers the phone. In other words, everything.

Unfortunately, user experience has become entangled, confused, and synonymous with the more specific term “user interface,” a term that has been used in the software industry for decades. Despite its techno-babble overtone, user interface is the correct term for describing the specific layer of an interactive product where the technology and the user come together. Making the Web Work is about user interface, not user experience.

Information architecture: Information architecture, as a term and a job title, was popularized by Richard Saul Wurman in his book Information Architects. Wurman’s book profiled a number of professionals from the graphic design community, who specialized in presenting complex information in a visually digestible form. Wurman referred to them as “information architects” because he believed they were taking raw information and shaping it into a particular form to communicate a particular message.

Somewhere in the middle of the Internet explosion, the term was co-opted to refer to the design activity concerned with organizing content and functionality. Since that transformation, there has been an ongoing debate within the design community as to exactly what IA means and exactly what information architects do. I have chosen to avoid the debate by using the term “organizational model” to refer to the organization and classification aspects of the interface.

I have made this choice for two reasons. First, the title of architect is inappropriate to the creation of interactive media as well as the role of design in that medium. Second, I do not believe that information architecture is a design activity separate and distinct from other design activities. Clearly, it’s a specialty at which some are more skilled than others, but it’s simply a different aspect of the design. Therefore, I think of information architects as designers specializing in organization and “findability.”

Conventions versus patterns: Taken from the lingo of object-oriented programming, the term “patterns” is often used to describe the set of solutions that have developed to address recurring interface problems. In a very real sense, this book serves to document some of the patterns currently in use in Web applications. Unfortunately, the use of the word “pattern” in this context, although definitely accurate, is a bit arcane. Therefore, I’ve chosen to use the more common word “conventions.”


Books about design are a unique and challenging combination of words and pictures. Although the words are clearly the product of the author, the pictures are typically gathered from other sources.

Instead of relying on my own designs and creations, I have generally chosen to use images taken from actual Web sites that are publicly available. As a result, my examples are almost exclusively from consumer sites rather than corporate intranets, licensed software, or other proprietary sites. Although this approach results in a book that appears to be focused on consumer sites, the problems presented affect all types of Web applications, regardless of their business niche or audience.

Looking at the examples, you will notice a lack of specific URL references. The dynamic nature of Web applications generally requires programming variables and other information to be carried along in a hopelessly long, cryptic, and dynamically generated URL. Including these URLs would not only be tedious, but also useless because the programming logic and design of URLs undergo constant revision. Even without their specific addresses, however, most of the examples are shown with enough context to illustrate the point and to show you how to get to the site if needed.


Early on in the process, I wrote a short list of values I hoped to instill in the book. There was one for each vowel, which made them a bit easier to remember:

  • Approachable

  • Educational

  • Inspirational

  • Objective

  • Useful

Of course it’s you, the reader, who is the ultimate judge of whether I’ve pulled it off. I hope you’ll let me know.

All the best…

—Bob Baxley

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint