I just exploded a killer shark with a single rifle shot…well, actually, two shots, since I missed the first time.
In gearing up for the migration to SharePoint for my library’s web portal, I began some overdue conversations with our Special Collection and Archives staff about their section of the library site. The result was a massive overhaul of their site architecture, features and design that led to a much more efficient site.
At the time that I began looking at their site, it was the largest section of the entire library portal, with dozens of pages arranged with no particular hierarchy, speaking the language of few visitors and serving up little in terms of actual content. In general, our Special Collections and Archives pages had the same kinds of problems that many other similar sites have (Dowell, 2008; Stevenson, 2008)
Clearly, there had to be a better way.
The work to fix this began about four months ago and was initially scoped by me (incorrectly) as a fairly straight-forward redesign proposal. My first plan was to have the SpCA staff come to my office, discuss options for bringing all their content (mostly PDF finding aids) into a database and wrapping a site around that.
Step 1: Discuss typical users
Step 2: Examine the current architecture
Step 3: Rationalize a new architecture by marrying lessons from steps 1 & 2.
Of course, this turned out to be ridiculously naive. And, in fact, the outcome of those first meetings was a realization that brought me back to that line in Jaws, when Chief Brody mutters in horror: “You’re gonna need a bigger boat.”
I had failed on a few fronts here, all related to time:
- I didn’t really appreciate the time it would take to get the SpCA staff on the same page as me, in terms of understanding the usability issues my solutions aimed to solve.
- I hadn’t provided enough time to do my homework in terms of analyzing the content on the site at the level required to truly improve the site.
- Most importantly, I let timelines from other projects get in the way of doing what was necessary to get the job done right.
And so, after my first redesign proposal went down in flames, I stepped back and started building that bigger boat. Step One would be to return to the information architecture methodology script straight out of the “Polar Bear Book” (Information Architecture by Morville and Rosenfeld).
My new methodology to make the special collections waters safe for swimmers was to:
1. Conduct a very informal heuristic evaluation and link problems to usability issues
2. Discuss these issues with staff
3. Conduct 1-on-1 interviews with staff about the site history and its future
4. Sit down with everyone and design user personas
5. Conduct an in-depth content analysis
6. Synthesize the findings and build a proposal from that
Suddenly, the shark was manageable. My meetings with staff began to be far more productive, largely because they learned more about the issues involved and also because I had gained a much deeper knowledge of them, their users and their site.
By the time it came to the second proposal, everyone was pretty much on the same page. And, in fact, the second iteration was light-years better than the first. Some of the changes we implemented include:
- Major consolidation of the site pages and simplification of the architecture
- Use of images and exemplars to guide users
- Use of FAQs (within LibGuides) to help novice users understand how Special Collections works.
- Greater use of appropriate language to suit the majority of users, while also allowing for different kinds of users
- Linkages to contact info, a database-driven finding aid collection and image search (currently on hold pending improvements in the image collection).
Put another way, I made success out of the initial failure. And, this has already helped with the larger project now at hand: moving the entire site to SharePoint, which is due to happen in the next few months. Yes, yes, I know I’ve been promising an update on that…