In embarking on a redesign project, the library wanted to create a distinctive and elegant signature look for the Web site, and recognized the need for graphic design expertise. While the library staff were experienced in organizing information, we did not have design skills. We looked to a designer to create a more polished product, with graphical elements that could be carried through other Web pages to aid navigation and branding. In addition, hiring graphic designers seemed to be a cost-effective solution since the software, high-end workstations, and graphic design training were not available at the library. 
 

ENTER THE GRAPHIC DESIGNER

The Yale Library does not employ a Webmaster. Instead, the Web is maintained by committee, partial staff assignments, and the Library Systems Office. A task force of eight staff members (the "Front Door Redesign Task Force") was charged with redesigning the library home page and associated subpages—just the top layer of a very large site that includes numerous subsites for individual libraries and departments, research tools, and services. Given a small budget to hire designers, we established a standard RFP process, reviewed the work of several design firms, and contracted with designers whose portfolio and fee best fit our requirements. Six months later, in June 2001, our new Web site went live. 

While working with a graphic design firm was successful and produced more attractive results than we could have achieved ourselves, it also presented challenges. The lessons we learned provide helpful guidance for other organizations that consider outsourcing Web design work. 
 

DIVISION OF LABOR

While many graphic designers will organize the Web site as well as create the design, we knew that we wanted to rely on our own expertise in organizing information. The Front Door Redesign Task Force recognized that input from multiple groups would be key to identifying not only how to redesign the site but also how to reorganize the labyrinthine structure that had developed below the home page. One primary source of input was the library staff. We held library-wide forums to gather feedback on the existing site and the proposed new site, and met with smaller groups of staff throughout the redesign process. Usability testing with students also proved to be a valuable source of input to our work. The task force examined dozens of Web sites, assessed design elements and organization, and consulted with others on campus, such as the University Printer, who is responsible for Yale's main Web site.

To organize all of this feedback, the task force used a variety of techniques, including ranking content ideas from the staff forum, using a card sort technique to test ways to organize links, and creating simple HTML mockups of various iterations of the new home page content. Furthermore, we established guiding principles early on and defined what our success factors would be. 

The designers found this preparation tremendously helpful. Their early drafts were more concrete as a result of our preparation, and they were able to focus on design instead of organization and wording. 
 

DESIGN PRINCIPLES AND TECHNICAL REQUIREMENTS

From the first meeting, the task force began to compile a list of basic principles to guide us in the redesign process. Although these principles were modified and refined over time, they greatly assisted us in keeping the project focused. We eventually achieved consensus on these design-related principles:

• The site will be user-oriented, not organized to correspond to our administrative structure. 
• The site will be easy to understand and use. We will avoid library jargon.
• The site will be elegant and distinctive.
• We will allow users to seek information and learn in a variety of ways.
• We will use hierarchy to provide structure and group links accordingly.
• We will limit the number of intervening pages between the home page and content.
• Images alone will not be used to convey meaning.
• The site will not employ a visual metaphor.

• The design should avoid technologies that load slowly or require special plug-ins. 
• Frames will not be used because of the complications they can cause in users' ability to interact with a page.
• The pages will display adequately on a variety of browser versions.
• The pages will display well at a minimum resolution of 800 x 600.
• The pages will be accessible to persons with visual disabilities directly or though reader software.

RELATED WEB SITES

Although the task force had a limited charge—redesigning the library Web site's top layer—we had to consider it in relation to other sites that were important to our users. We aimed to create a site that would be easy for novices to navigate and understand, and at the same time be useful to sophisticated Yale researchers. Part of the task seemed straightforward: The library's home page and subpages had always served as an entry point to the library for new users seeking general information about the library, including collections, services, policies, and staff. Our job was complicated, however, by the existence of a Yale Library site geared toward researchers—the highly visible and heavily used "Research Workstation." 

In 1994, when the Web was emerging, the Research Workstation was designed to serve as a unified access point to various online databases and CD-ROMs. Later, the official library home page was designed, and the two sites grew separately. The Research Workstation continued to exist as a site designed specifically for Yale researchers, featuring links to resources including the online catalog, databases, and subject guides. The Research Workstation home page was used as the default home page on many library workstations. 

While library staff understood the difference between the Research Workstation site and the library home page, users found the presentation of the library from two different perspectives confusing. The task force heard comments like, "Why are there two ways to do the same thing?"

Although task force members questioned the need for two separate sites from the beginning, the early consensus was that combining the two sites would be outside of our charge, and could extend our tight timeline. As we gathered feedback and drafted a structure for the new home page, we realized that the content of the two sites would overlap considerably. Upon consultation with the committee that managed the Research Workstation site, we decided to merge the two sites.

Beyond the library Web site, we needed to consider the broader institutional Web environment. Web development responsibility at Yale Univer-
sity has traditionally been widely dispersed, with no mandated design elements. In 1999, under the direction of the University Printer, Yale implemented a distinctive Web site design. With the goal of developing a coherent Web identity for the University, the University Printer's Office promoted the idea of a derivative design approach intended to be applicable to major administrative units. Such a derivative site would adhere to certain structural, color, and typographic standards in common with the Yale front door site. A number of University departments and programs have implemented sites following this design approach.

We told our designers that we wanted to show some influence of the University design upon the new library site, without adhering to the structured page layout used on the University site. The designers came up with a new type of "Yale derivative," evocative of the Yale pages through use of common colors, typefaces, and style, but less rigid in design. The Library's new site is clearly a Yale site, but also quite recognizably the Library's site.
 

USER TESTING

Usability testing proved to be a rich source of information about our Web site and a validation of some of our language choices, as we worked to minimize jargon on our site. We asked staff and students to tell us both what worked and what didn't work in our current site. The most frequent suggestion heard from both groups was that our library catalog, Orbis, should be searchable from the home page.

We structured a simple usability test based on previous work done at Yale and the principles of Web usability expert Jakob Nielsen. We asked users to find specific information on our Web site and then observed them as they clicked around. We also showed users mockups of the proposed home page and asked if they understood the link language we used. We found that explanatory wording was necessary for terms we used for some online services. For example, instead of simply using an internal term such as "Eli Express," we chose language that would make sense to both new and experienced Yale Library readers: "Request a Book from another Yale library (Eli Express)." 

We did another usability test we called "Name that Page" in order to cross-check some of our assumptions. We stripped titles off certain pages and asked users to tell us what heading they would use. This approach helped us to establish the use of page titles like "Databases and Article Searching" rather than simply "Databases." The word "article" effectively conveyed the idea of a place to search for journal articles, especially for undergraduates. In addition, this test allowed us to see whether information was logically grouped on the pages. If the content of the page didn't make sense to our test subjects or didn't easily lend itself to naming, we reviewed the content to see if it could be streamlined or if some content should be moved elsewhere on the site.
 

ATTENTION TO CODING

One of the presumed benefits of hiring designers is the sense that "someone will take care of it." What we found was that although we contracted for coding as well as graphic design, we ended up working over the code ourselves. For most of our process, the various drafts that the designers submitted to us were simply PhotoShop images. Once we agreed on the design, the next step was to create functioning Web pages. Because of the diverse work environments of our staff and users, we needed the pages to conform to World Wide Web Consortium accessibility standards, work in a variety of HTML editors, and display correctly on most browsers. We also anticipated the need to make modifications to the design. We wanted to be able to do so as easily as possible. 

After receiving the coded draft Web pages, we learned that the designers had contracted the coding to an outside programmer. While we had asked for "clean" HTML, what we received included an abundant and unnecessary use of nested tables, single-pixel images used for spacing, and JavaScript. Because we received the coded pages so late in the process and were working on a deadline, we didn't have the luxury of the iterative process that we'd had with the designers. We were able to go back to the programmer only twice with requests for changes. When we ended up recoding much of the pages ourselves, the design remained intact with far simpler code. Perhaps if the programmer had been included in all our meetings with the designers, we would have been able to communicate our needs better and received code that required less reworking on our part. 

One major technical issue we faced involved the use of JavaScript. The programmer used JavaScript that did not function similarly in Netscape and Internet Explorer and had to be tested and debugged. We asked the programmer to rework the code to rely less on client-side JavaScript; his response was to use PHP, a server-side scripting language used to create dynamic Web pages. This solved the JavaScript problems, but we did not have support for PHP installed on our server. We decided to convert our Web server software from Netscape Enterprise Server to Apache and install PHP support. This beneficial but unanticipated upgrade required significant testing of pages, scripts, and applications installedon our server.

Finally, the task force spent considerable time insuring that the new site complied with the World Wide Web Consortium Web Content Accessibility Guidelines 1.0, Priorities 1 & 2 (www. w3.org/TR/WCAG10/ full-checklist. html), as mandated by library policy. We reviewed colors selected for the pages and tested them with colorblind people, edited the pages to include appropriate <Alt> tags for images, and appropriately coded <Table> elements.

Some graphic designers deliver a complete "soup to nuts" Web site while others provide only images to plug into existing pages. Either way, those working with the designers should make the technical specifications clear and should test the pages on various browsers. If designers are responsible for coding the pages, set a deadline for delivery of the code that is well before the site's launch date to allow for an ample testing and recoding period. 
 

AUTHORING EASE OF USE

To fully integrate a new Web site, it must be simple for all Web authors in the organization to use and maintain. Providing templates for pages helps achieve some measure of uniformity. Another step that makes replicating design easier is to hide the complicated code from the Web page author with only basic skills. Finally, using Server Side Includes for universal page changes saves time in the long run.

There are approximately 140 Web developers at the Yale University Library. These staff members are responsible for creating Web sites for a unit, department, or library within the library system. From the beginning of the redesign process, we planned to develop templates that would allow these library Web developers to create pages easily using the new design.

However, even after we streamlined the code in the pages delivered to us, the new Web pages still contained an abundance of JavaScript and other code that we felt would be confusing to most of our Web developers. In an effort to simplify the templates, we divided each page into chunks of code called Server Side Includes (SSIs). The use of SSIs allowed the task force to place graphics and formatting information in separate files, which are then called by individual pages for inclusion. For example, each HTML page might call one SSI in the beginning, which would insert a graphical banner, a navigation bar, and font specifications. Using SSIs makes it easier for us to update common elements in the future. Since the new site was launched in June 2001, we have already added a link to the navigation bar that appears at the bottom of every page. Because the image map code for this navigation bar is in a Server Side Include, it had to be edited in only one place, instead of on 250 pages.

Creating the SSIs should have been a fairly simple process of cutting out appropriate pieces of code to create standard headers and footers. Unfortunately, because of the extremely complex use of tables and the coding inconsistencies among the pages we received, this was a very lengthy process that ultimately involved recoding much of the header and footer information. The result was a set of templates that could be used in most HTML editors or easily understood in a text editor. The templates include comments pointing out the exact sections of the page where content should be added. To support staff use of the templates, we designed and implemented hands-on training sessions and written detailed documentation. A significant number of library pages have since been created or redesigned using these templates.

Another goal for the new site design was to have modular graphics, which would allow staff to create pages incorporating some of the new design elements while maintaining a unique identity. The final design, however, did not lend itself to this level of customization. This will become phase II of the project as we apply the lessons learned from this process to a series of new designs for use by individual libraries and departments within the Yale Library system.
 

COMMUNICATE AND COMPROMISE

We met with the design team several times throughout the redesign process. Early on, we shared with them our ideas about what we wanted to achieve. Later meetings focused on reviewing the drafts they submitted. Throughout, we kept them apprised of the feedback we were gathering from staff and users. In face-to-face meetings, phone calls, and emails, we stayed in touch at every stage. The designers commented favorably that we were one of the most organized clients they had ever worked with. By coming to meetings prepared with feedback and draft organizational schemes, we were able to communicate very clearly what we wanted the site to achieve. The end result was an attractive design that reflected the needs and desires of our constituents. 

Of course, every design process has points for compromise. We found that the designers were often wedded to design ideas that would not be practical for our environment. Designers sometimes like to create something with technology just because they can. We reduced the number of rollovers and fancy effects that the designers wanted to use on our site. 

We also had to insure that design harmonized with function. The draft designs incorporated images from the decorative leaded glass windows in the Sterling Memorial Library. It was our intention that these images would lend elegance and a sense of library history to the site without distracting from page content. While the designers chose images that were beautiful, some of them were inappropriate. For example, a stylized image of a warrior beheading a centaur was originally used on all of the library's Human Resources pages. Needless to say, the Human Resources department felt that this sent the wrong message. The task force ended up selecting a more appropriate images from the set chosen by the designers.

A problematic decision that became apparent late in the process was the designers' use of non-standard fonts. For visual effect, some text was rendered as graphics. We wanted to obtain the font used in these graphics in order to create new graphics as the site developed. One of the fonts selected by our designers was available in the United States, for free, for the Macintosh platform. We needed the Windows version, which was only available for purchase from its developer in Europe. We were eventually able to purchase a multiuser version of the font, but only after significant delays and some unexpected expense. In hindsight, we would have preferred that the designers use a standard font.

As with testing the new site, it is important to build in enough time for communication and compromise. The earlier you see the design and understand its elements, the more time you have to negotiate changes with the designers. 
 

RECURRING PROCESS

Overall, the redesign of the Yale University Library's Web site has been a success. Despite the complexity of the design, which does not lend itself to major customization by libraries and departments within the system, it is still flexible enough to accommodate changes.

One of the most fascinating parts of this effort has been the service quality aspects of our work. As we listen more closely to what users want from our services, we learn more about how to meet their expectations, and how to better promote the services we already offer. As Web technology evolves, as our readers become ever more sophisticated Web users, and as our configuration of resources and services develops, we will need to redesign again to keep up. Indeed, one marker of our success will be to attend to our principles and lessons learned and to have a fresh design in place a few years from now.