In one recent case, the project goal was to improve usability for a site’s new users. A card-sorting session—a perfectly appropriate discovery method for planning information architecture changes—revealed that the existing, less-than-ideal terminology used throughout the site should be retained. This happened because the team ran the card-sort with existing site users instead of the new users it aimed to entice.
The reason why I laughed was because it reminded me of this anonymous comment from a blog that wished would post more often, A Librarian's Guide to Etiquette,
Content of committee's final report: Over the last 10 months, we reviewed and tested all the designs for the web site that were offered. Since they didn't look like our current web site, we decided that they would confuse our users, so we voted to retain our 'tried and true' web site design. We will disband the committee after our next meeting, in which we want to constitute a committee to come up with training handouts we can give patrons to show them all the hidden gems on our web site and how to use them. Thank you very much.
So how can libraryland break out of this conundrum? How can we design better websites for users instead of ourselves?
One way forward is to set user-centric behaviour and usability goals that you will strive to meet for the next web redesign. That is, have the web design committee be responsible for an articulation phase that should go before any actual re-designing goes on of a library's website. From the provocatively titled article, Committees Commit, Designers Design:
Practically speaking, a successful collaborative design process has two phases: articulation, in which the needs and wants of all the stakeholders are teased out and common goals agreed upon; and design, in which the designer responds creatively to those goals. This will sound familiar to anyone who has engaged in a long-range planning exercise or participated in a community-driven urban design charrette. First, articulate what you collectively want—then, design a system to make it happen.
A more succinct argument for establishing user-behaviour based requirements comes from a ThinkVitamin web comic [via Influx] where the following exchange plays out:
Brad: [to participants] What would you like to see on the website?
Participants: a stock ticker! pictures from the brochure! sports scores! ponies!
Indi: [to Brad] What is wrong with you?! That was a terrible question!
Brad: I'm sorry, I don't know
Indi: At this stage, you don't want to ask any leading questions. You want to focus more on behaviors not features. A better question may be:
Brad: [to participants] How do you construct / fix stuff?
How do you construct / fix stuff is still a hard question, but at least its a question where you can get tangible answers to build a website around.