A Design-by-Committee Model that Actually Sorta Worked

Library web developers typically dread decision-making meetings, because when it comes to the library's web site, everyone has strong, and almost always differing, opinions. Determining a process that is rigorous, yet fair, and allows everyone's voice be heard is a challenge. The result is all-too-often a "design-by-committee" disaster: a web site design and information architecture based on internal politics rather than end user wants and needs. No one is happy with the final product, and everyone who was involved in the meetings just wishes for those precious hours of life back.

As a web developer, I'm big on group activities that produce quantifiable data to drive decisions. I could do usability testing full-time. Last week, we needed to discuss and vet the content of the new home page and secondary template pages among the head of digital services (my boss's boss), the sysadmin supervisor (my boss), myself, and our three-person web team (they're the content managers) before I could move forward rebuilding our new main site. For a variety of reasons, we are building and launching under a very aggressive timeline, so we're therefore using an out-of-the-box Drupal theme because there's not enough time to develop a theme from scratch.

All six of us had recently (and extensively) reviewed and discussed the 350+ responses that we received in January as part of a quick patron survey. We had agreed that there were twelve elements that should be considered for inclusion on the home page and secondary pages. So going in, we did have some direction based on user data. Most of these things are present on the current web site, but some were new additions as a result of the survey responses. Knowing that we're working with Drupal's MAYO theme, I gave everyone a list of the twelve elements and a printout of a demonstration of MAYO's regions ("regions," in Drupalspeak, are simply areas within a theme where content may be placed.) Independently, everyone matched the twelve elements to a region, indicating where the element ought to go on both the home page and the secondary page. It was okay to simply omit an element if it was deemed not important.

Once everyone had a chance to assign each of the twelve elements to regions, we collated it all on our department's giant whiteboard (which, conveniently enough, is right next to my desk). Every person used a different color of dry erase market to place all of the elements so that we could tell who put what where:

two team members assign elements to regions in the Drupal template

Placing some of the elements was easy; we unanimously that the logo belonged on the top and the "big red footer" from the existing site in Footer Columns 1-4. Those were no-brainers. A fair bit of discussion ensued about placement of a tabbed search box (essentially, embedded widgets that search our III catalog from the web site), a catalog log in widget, secondary navigation, and a carousel of featured book covers. Even if a majority determined placement of a particular element, minority reports were encouraged to describe their reasoning for their alternate choices, which sparked ideas and further discussion. If no resolution was attained after a few minutes of discussion, we recorded a user story in Pivotal Tracker, our project management software, and made a short list of possibilities for me to pursue after the meeting.

Here's an example: the legacy site has a secondary navigation that's based on item formats, i.e., "Books," "Movies," "Music," and "Downloads." The purpose of each of the pages to which these navigational tabs link is to showcase what's coming soon for each of those formats, with the exception of the "Downloads" tab, which links out to Overdrive, Tumblebooks, Freegal, etc. Two members of the group thought that these tabs could be done away with if the links were provided as part of the proposed tabbed search box, while the other half thought that they should be kept. We also made a short list of questions that web analytics for our site could help us answer with quantitative data. Take that secondary navigation example: we're going to check referrers for those pages to see how users getting to them. If most patrons arrive from the home page, it could be argued that the secondary navigation is not needed throughout the site.

The whole process was thorough, democratic, and darn it, just a teensy bit fun. Even better, I have great information that I can use to proceed in building three layout options for us to discuss further, and I can move forward building the site knowing that my colleagues all got a chance to weigh in on the process.

all responses collated on whiteboard