Sensible Library Website Development
Why do we have library websites? Teaching, posting things, a way to access resources and services, allowing access to the catalog and online resources, to help, etc. Amanda says that while we are all unique little snowflakes, we aren’t that unique in our motivations for having websites. How do those similar goals and motivations help us share and collaborate a little more for website design.
Scope refers to the parameters of a project. Whether you’re building a brand new website or redesigning, you need to define the scope of the site. It’s a mistake to assume that a redesigned site is going to include the same type and information as the existing site. Most library websites are like junk drawers—everything you could possibly want to know about the library. We put everything we can think of on the site just in case someone might need to know it. Amanda is a fan of the smaller is better approach. Less is less. If you consider the signal:noise ratio of your website is important. The pages people aren’t using are a whole lot of noise that detracts from the pages that people want and need to access. How much of your content represents your needs vs. your library user’s needs? It’s better for half of your website to be amazing than for your entire website to be bland. Another way to think about it is like a pyramid. The necessary information is the base of the pyramid. As you move up you get to destination pages – things like library-created contact, basic interactivity. Above that you see participatory activity, user-created content. And at the top you see the library website as a community portal. Amanda highlighted http://influx.us/onepager – a template for a single page library website. Most of the high use content on a library website can fit onto one page. You can download the code and play with it yourself. J Yays! The notion of less is less – aiming for less content is a good thing, but how do you start scoping your site in this way? The first is that you should really design for mobile devices first…not only because of the ubiquity of mobile devices, but if you design for mobile you have to work harder and pare back to what you and your users think of as essential functionality. “If we wouldn’t put it on our mobile version, why would we put it on our regular website?” Recommended book: Mobile First. Focus on users’ critical tasks. What are those critical tasks? How do you determine your critical tasks? Ask your users through a survey – what are the top 3 reasons you visit the site? Use a heatmapping application on your homepage to see what the top things are that users click on. Don’t ask staff – anecdotal evidence from staff does not equal real data.
The kind of reading that happens online is functional reading. People skim and scan pages. They don’t read top to bottom. Being confronted with large amounts of text on a screen doesn’t work. Remove unnecessary words. Change the way you think about your website as an FAQ. It shouldn’t be a junk drawer – but a place to find answers to the most frequently asked questions and desired tasks. Think about your website as information not documents. Adopt the inverted pyramid style for your website copy – People will look at the top and lose interest as they go down. Bold text to make it stand out. Break up text into chunks with headers. Make your web copy conversational – build content with functional reading in mind that includes a conversational and personal tone. Treat your website like a conversation between you and your users. Don’t write in the passive voice. Write in the active voice (fewer words result, too!). If you write in the passive voice, you seem authoritative and stuffy and unfriendly. If your library is supposed to be conversational, use the words we and you, not library and user.
Redesigning navigation is not an easy process. Navigation can make or break a website. Read Steve Krug’s book Don’t Make Me Think. There are general practices in web design we can draw from. Navigation needs to tell people the site name, page name, where on the site they are, where they can go next, and how they can search. Salt Lake City Public Library’s website is a good example of excellent navigation. Vancouver Public Library is another good example (Sarah’s note: I actually don’t dig on this website very much, but maybe it’s just me). Airbnb is a site Amanda likes in terms of navigation and interaction design. Apple.com also very easy to navigate. Match up your labels to your page names. Don’t disorient your users. Your navigation is not your org chart. Your users don’t care about your org chart. It’s not something they think about, so don’t design your site around your org chart. It’s not intuitive to your users. And finally – death to “click here.” (Sarah’s note: HELL TO THE YES.)
Lack of information is at the root of all bad design decisions. Make design decisions based on information and data. It is an extremely enlightening experience. The insights you gain from watching people use your site can’t be found any other way. Usability testing in five words: watch people use your website. You can gain more information and data on usability from watching people interact with it than you can from reading every usability textbook ever written. We are not our patrons. We are different than those who use our sites. Don’t test your staff. You do need to test with library users, not staff. Five testers is enough for anything. Once you go over five you start to see a lot of repetition. There’s no such thing as a usability test that’s too small. There is such a thing as one that’s too big. Make a comprehensive list of all the things you want to test, and chunk it out into 3 things at a time, which you can test with different small groups. Test early and test often. Make iterative changes constantly instead of giant big website designs. Script your usability testing – giving testers even slightly different instructions can affect the results dramatically. A script allows you as the tester to concentrate on the test and the tester. In the script: an introduction to you, your role, their role; be clear about the purpose of the test; provide testers an outline of what they’ll be doing and how long it will take; give them a printed copy of the tasks you’ll be asking them to do; ensure that the testers know that they’re not the ones being tested—it’s the site being tested. Write your scenarios carefully. If you’re testing your library databases page, don’t phrase it in library-ese. Use common language that people would actually use, and that doesn’t give them the right path or answer in the question itself.