Building a Site-Wide Search Utility: Lessons Learned

September 25, 2002
2:50 pm - 4:00 pm
Halligan 111
Speaker: Dr. Joel Angiolillo, Verizon Laboratories


In 2001 Verizon launched a complete new web site. Every component of the site was new, from the home page down to the lowliest FAQ. In the process, every utility on the site was redesigned, including site- search. (Site-search provides the ability to search the contents of site one is on.) The new search utility was based on a Verity(TM) search engine, but the user interface was completely home grown. This talk is a travel log of our 18-month trip through the design and test of the search utility. has over 100K pages of information. Any single user may be looking for only one of those many pages. In the worse case, users don't know what they are looking for and might not recognize useful content if the "right" page is delivered. To make looking for information more successful, what sorts of Input, Output, and System features should a search utility have? Input Questions: Should there be a search utility on the site at all? Why? If there is one, where should it be located? On the Home Page? On every page? Should it be a search box or a link to a page that allows for more controlled searching? Should Boolean features be offered? What types of keywords is the user likely to type? Output Questions: How many matches should be displayed? What information should be displayed with each match? How should the results be sorted? Should synonym matching be used? What should the system do if too many or too few results are returned? System Questions: How should pages be coded and the site organized to support searchers? Why type of process should be in place to assure continuous improvement? How much money should we have to do ongoing test and development? To answer these, and other, questions we employed many of the standard tools in the human factors toolbox. We researched the literature, studied competitive sites, conducted focus groups, built prototypes, ran usability tests, studied log analyses, wrote requirements. However, in the end, it came down to the weekly Search Team meetings and our working relationship with fellow team members. The art of good design walks with its cousins, negotiation and compromise. If we had to do it all over again, what would we do differently? What are the questions we need the researcher to answer, what are the solutions we need the technologist to build, and, in turn, what can the researcher and technologist learn from the travels of the practitioner?