|Table of Contents||Previous Issues||Subscribe Now!|
|VOLUME 26 • NUMBER 2 • MARCH/APRIL 2002|
Lessons for Working with Web Designers
by Holly K. Grossetta Nardini, Julie Linden, Gillian Mayman, Karen Reardon, and Andrew Shimp
Yale University Library's Web site (www.library.yale.edu)
had the same design in place for four years—a lifetime in Web terms. Like
the house that Jack built, it had accreted new bits and pieces and additions
over the years and lacked overall coherence. Its organizational principles
were murky, the home page could not gracefully accommodate modifications
and the graphic identity—a faddish metaphor, "a guide for your journey"—was
not effective in conveying information about the library. In fact, many
of the 22 Yale libraries did not use the library home page as the default
home page on their public computers. Clearly, it was time for a change.
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:
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-
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.
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.
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.
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
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.
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.
Holly K. Grossetta Nardini (holly.nardini @yale.edu) is Service Quality Support Director, Yale University Library; Julie Linden (email@example.com) is Data and Electronic Services Librarian, Yale University Social Science Library; Gillian Mayman (gillian. firstname.lastname@example.org) is Webmaster, Yale University Medical Library; Karen Reardon (karen.reardon@ yale.edu) is Manager of Workstation Support, Yale University Library; and Andrew Shimp (andrew.shimp @yale.edu) is Engineering and Applied Science Librarian, Yale University Library.
Comments? Email letters to the editor to email@example.com.