Building WIGITs: Public services, IT, and users make a better Web site

Emily Daly; Michael Peper

A library’s Web presence is an important vehicle for promoting resources and services and often serves as a community’s primary portal to library resources and services. Because so much research is done on the web, internal stakeholders in a library’s Web site are often spread throughout the organization. This is certainly true at Duke University Libraries, where interest in, and governance of, the libraries’ Web site extends far beyond traditional IT staff.

In response, Duke University Libraries has worked to develop a more inclusive decision-making and priority-setting model for managing Web projects. Because the Web site involves work from a variety of library departments, it has become increasingly important to have a diverse, interdepartmental group charged with working on Web projects. This group, named the Web Interfaces Group (WIG), was originally formed in 2008 and has adapted to new needs, staffing, and organizational approaches.

WIG Implementation Team Projects List.

A constant feature of WIG, however, has been its composition of both public services and IT staff with a variety of skills and levels of responsibility. In 2010, the group was changed substantially—most notably, it was split into two standing committees that work together to provide a transparent process, frequent communication, and a wide range of assessment activities.

The first group, WIG, is charged with building strategy and formulating a vision for the library’s Web presence and is composed of department heads responsible for assigning staff to work on particular projects. WIG also includes a member of the Libraries Executive Group, providing a bridge to the highest level of decision-making in the libraries.

A second group was formed to serve as the implementation team for WIG and predictably named the Web Interfaces Group Implementation Team (WIGIT). Originally there were two WIGITs, one focusing on discovery interfaces and the other working on static content pages. It was at this time that the authors became involved with this project management model, serving as members of WIG and coordinators of the two WIGITs.

After eight months, it was clear that the overlap between the two implementation teams was so great that it would be more efficient to consolidate into a single group, with the authors serving as cochairs.

Additional WIGIT members include an electronic serials librarian, an applications developer, a Web designer, and an archivist. This membership ensures broad representation on the group, but, more importantly, a diverse collective skills set, which helps our disparate systems work well together.

Managing the work of WIGIT

Because WIGIT strives to make completed projects and decisions as visible and transparent as possible, we created a number of methods for communicating our work to our colleagues throughout the libraries. Immediately after the implementation team was formed, we offered to visit every department in the library to discuss the purpose and function of the newly formed team. We have also committed to updating all staff on projects that are proposed and completed once per semester via a monthly standing meeting devoted to technology issues that all staff are encouraged to attend. Semester updates are followed by all-staff e-mails and posts to the Duke University Libraries staff blog.

It is not, however, necessary for staff to wait for end-of-semester meetings to learn about the work of WIGIT; rather, they are encouraged to consult WIGIT’s publicly available and regularly updated Projects List that details all projects proposed to the implementation team.

This Web site,1 using Google Spreadsheets and SIMILE, lists projects by name and category (e.g., assessment, redesign) for easy sorting, and each item includes a brief description of the work to be completed; the semester WIGIT intends to begin work; the estimated completion date (e.g., Spring 2012); and the name of a contact person staff may follow up with, as necessary. It is worth noting that the contact person or “owner” associated with each project is not necessarily a WIGIT member. While WIGIT is composed of staff involved in the on-the-ground work required for each project, the primary purpose of the implementation team is to prioritize and then coordinate Web projects. In addition to a project owner, each item in the list is assigned a status (i.e., proposed, scheduled, in process, completed, declined), enabling staff to track their projects through WIGIT’s workflow.

WIGIT project case study: Public display of Summon

Like many academic libraries, Duke has explored Web-scale discovery services, and in January 2011 began licensing the Serials Solutions product, Summon. While other teams were charged with first choosing and then implementing Summon from a technical standpoint, WIGIT was tasked with determining how to represent Summon on the libraries’ homepage, marketing the new tool and assessing its effectiveness.

We introduced Summon to the Duke community as an improved Articles finder, replacing the federated search tool that had been available from the libraries’ homepage for years. WIGIT members elected to retain the existing name of the tool (“Articles”) and simply added a “(NEW)” graphic to the homepage to alert users of the change. Marketing efforts included homepage announcements, library blog posts, and help pages that documented the new tool and provided tips for effectively using it.

Original Search Resources page.

In order to assess the effectiveness of the new Articles finder, we collected usage statistics of the tool using Google Analytics, solicited feedback from users in a survey linked directly from Summon, sought input from our student advisory groups, and conducted two sets of usability tests.

Because we learned in usability testing and discussions with the libraries’ student advisory boards that patrons are indeed interested in searching subscription journals and the local library catalog simultaneously, WIGIT felt it necessary to provide users with a way to conduct a search of all (or nearly all) library resources in a single search. WIGIT members branded the tool as QuickSearch and initiated a pilot of it during Duke’s first summer session of 2011, which was approximately six weeks long. During this pilot, the Articles finder remained in place, but we added QuickSearch and made it the default search tool on the libraries’ homepage, replacing Catalog as the default search. Users could still access the catalog from the home-page by clicking directly on the catalog tab.

Our assessment measures for QuickSearch were similar to those for the Articles finder: We conducted on-the-fly usability testing in Duke’s student center, provided a way for users to submit feedback on the tool through a survey linked directly from the libraries’ homepage, and tracked usage of QuickSearch through Google Analytics. Additionally, we conducted a focus group to gather input from librarians, who have expressed strong opinions about the name, function and placement of the search tool. Because we received mixed reviews of QuickSearch during this initial pilot phase and did not feel prepared to decide how best to represent Summon on the libraries’ homepage, we elected to extend the QuickSearch pilot and remove the Articles finder so as to avoid confusion between two search environments that looked nearly identical to our users.

Revised Search Resources page.

By extending the pilot through much of the fall semester, we were able to collect additional data during a time when many more users are on campus and using the libraries’ homepage. After additional assessment, including in-depth user interviews with undergraduates and graduate students, WIGIT members compiled a report of findings and options for implementing Summon on the libraries’ homepage. We submitted this report to WIG for discussion and revision and then to the Libraries Executive Group for a final decision.

This WIGIT project is noteworthy for two reasons. First, it is indicative of the iterative approach WIGIT takes to Web design—whenever possible, we implement an interface, assess its effectiveness, make changes as needed, and then re-evaluate and complete the process, as necessary. Second, determining the best way to present Summon to our patrons—a decision that affects every staff member and library user—has required that WIGIT membership maintain a neutral and objective stance. We have worked diligently to remain unbiased as we have assessed the Articles and QuickSearch tools, openly listening to the viewpoints of library staff, soliciting feedback from a broad range of patrons, and analyzing Web metrics so that we may make a well informed, data-driven decision that will meet the needs of our diverse user base.

Challenges and future directions

While Duke University Libraries administrators and staff alike feel WIGIT has been a valuable addition to the libraries’ slate of working groups, the team’s first two years have not been without challenges. Perhaps most difficult has been defining the scope of WIGIT’s work, as any public facing Web interface on the libraries’ site falls within the purview of WIGIT. While it is important that we be aware of the work that is being completed on the libraries’ Web site, it is neither realistic nor reasonable to expect that WIGIT be responsible for coordinating every change made to the more than 10,000 individual pages that comprise the site. We have no interest in approving wording or structural changes to individual departmental pages or particular research guides but, rather, aim to coordinate assessment and improvement of interfaces that aim to meet the needs of many user groups.

Another challenge is ensuring the implementation team is composed of the staff members best suited to its purpose. We wish to include staff whose daily work is directly tied to the projects WIGIT oversees, as well as staff members who mediate patrons’ use of library interfaces. Because WIGIT meets fairly frequently and communicates through e-mail regularly, it is important that our members be invested in WIGIT’s work and feel they are in a position to make substantive contributions to our biweekly discussions. As team members’ work duties evolve and shift, it is necessary to change the membership of WIGIT—managing the composition of the team and ensuring that members do not “burn out” are responsibilities the coordinators take seriously. In fact, due in large part to changes in members’ job responsibilities over the last two years, only three of the original ten members of WIGIT are still in the group.

It is also critical that we collaborate with staff outside WIGIT to complete projects. While nearly all library staff are interested in improving Web interfaces, not all staff feel they have the time or expertise required to assess and make recommendations to change these interfaces. It is imperative, therefore, that WIGIT coordinators actively engage and empower library staff who have expertise in particular areas to contribute to the team’s work. We have found that it is most effective to charge task forces to complete discrete projects, such as redesigning the libraries’ Document Delivery/ILLiad interface or assessing the effectiveness of the libraries’ blog content and structure. Of course, involving more people requires WIGIT coordinators to manage additional communication and workflows (not to mention convene additional meetings); so far, however, the success of these discrete task forces has made the additional work worth our time and energy.

In its first two years, WIGIT has been largely effective and successful in instituting a number of positive changes. We believe our current model has been productive and takes advantage of the diverse skills among our staff. Maintaining flexibility and transparency has been essential to continuing innovation in the libraries’ Web presence. As library staff continue to imagine innovative ways to meet our users’ needs through the libraries’ Web interfaces, WIGIT coordinators are committed to turning staff ideas into fully realized user tools.

Copyright © 2012 Emily Daly and Michael Peper

Article Views (Last 12 Months)

No data available

Contact ACRL for article usage statistics from 2010-April 2017.

Article Views (By Year/Month)

January: 7
February: 10
March: 4
April: 4
April: 0
May: 3
June: 6
July: 9
August: 10
September: 4
October: 3
November: 3
December: 11