You are currently browsing the category archive for the ‘usability’ category.
It has long intrigued me why libraries (or maybe librarians) like to use different words instead of the words that our users would commonly use. The issue/discharge, check-in/checkout, return/borrow terminology always used to seem to me to be at odds with how users thought of the processes. In most cases in my experience library users (borrowers, readers, patrons…) would say ‘I want to take this out’ or ‘I want to bring this back’ but I’ve never yet seen any library that uses those words to describe the processes.
And we’ve carried on this process into the web-sphere, as this recent report by John Kupersmith from Berkeley ‘Library Terms that Users Understand’ clearly identifies. Looking at 51 usability studies he has picked out seve
ral terms that users simply don’t understand (shown in the image on the right). Terms like database, periodical, serial, and resource are included in the list and they are all familiar from usability tests we’ve done ourselves. Database is one that I always find particularly interesting. To most people a database is something like Microsoft Access and few people outside libraries would ever consider them to be a collection of library stuff.
It’s good to see recommen
dations about the use of natural language such as ‘Find’ in the report. That certainly matches what we have found from our own work and we’ve ended up going with ‘Find’ for our search feature on the home page of our website. Journals, articles and ebooks may not be quite the best terms to use with Find maybe.
I am slightly surprised to find that users aren’t that sure about the term ‘Library catalog’ but maybe I shouldn’t be, as I think that libraries themseleves are maybe slightly confused about what is in a library catalogue these days, in the age of knowledge bases and discovery systems. Is your catalogue just a list of printed materials, or a list of everything owned or licensed by the library? I wonder whether users were any clearer about what a library catalogue was in the past?
We’ve used a couple of different usability tools at various stages through the library website project. We’re fortunate in having access to a high level of expertise and advice/guidance from colleagues at the University’s Institute of Educational Technology . This means that we have access to some advanced usability tools such as eye-tracking software.
We’ve used two different tools. Firstly, Morae usability software, which we have on a laptop, and is used to track and record mouse movements and audio commentaries. This is quite portable and allows us to do some small-scale testing. We most recently used it for some of the search evaluation work. Its limitation is that although it tracks what people do with the mouse it may be very different to where they are looking on screen.
At a workshop I was at the other day, people talked about users scanning web-pages in an ‘F’ pattern, so would scan across in two horizontal lines followed by one vertical line on the left. This implies that they will pick up items in the left hand column and across the top quite easily. This was something reported by Jakob Nielsen here back in 2006, with some sample heatmap screenshots shown below.
For the latest testing, we’ve been able to use the Tobii eye-tracking system in the IET Usability labs, which as the name suggests track the users eye-movements about the screen and give a much richer indication of how they are interacting with the website. So you can show where users are looking as a heatmap, as shown in Jakob Nielsen’s example above, or alternatively you can show gaze opacity. This shows where users are looking in white, with the more opaque the white the more time their gaze is concentrated on that location. So places that aren’t being viewed show up as black. 
The example shown is from the latest library website testing and you can quite clearly see the same sort of ‘F’ shaped scanning behaviour on one of the sub-pages on the website. Looking through some of the other pages then it isn’t always quite as clear cut.
Keren, my colleague on the project team who has been running the usability testing stage is currently going through the images and the transcripts/notes at the moment and will pull out of it some recommendations to modify the website to address any areas that users found difficult to use. These recommendations then get reviewed by our Website Editorial Group and prioritised as to whether they are high priority and need to be fixed before the site can go live, or of lesser priority and can be resolved over a longer time period.
The value of this sort of testing is quite high as it isn’t really until users actually engage with your website and try to use it in practice that you really find out how well it works. It is time-consuming, in that there’s some organising to do to find people to take part in the testing (in our case a research panel to go through to get approval and then emails out to students). It also takes time to write and fine-tune the scripts that will be used for the testing, and then time to carry out the testing and then to analyse the outputs, but that time is well-spent if you want to understand how easy users will find your site to use.
In the last few weeks I’ve taken part in a couple of activities that involved the use of ‘personas’. If you’ve not come across personas before, then they are a made up person, with a name and a personal history, that represent one of your key client groups. [There's some good information about personas here on the usability.gov website]. 
Personas are a really a useful service design and usability tool as they allow you to visualise your service through the eyes of one of your users.
Typically your persona would have a name, a photograph (because it makes them easier to relate to), and a back-story: educational background; employment status; personal circumstances; aspirations and motivations; for example. It’s also good to have things such as whether they use social networking and what sorts of things they are interested in. Generally you’d also want to try to categorise them with a short phrase that makes it easier to discuss them. Often you’d create a set of sheets or cards with the details of each persona.
In the two exercises I’ve recently taken part in they have been used to look at two very different stages of the website design process. Firstly as a demonstration of their value in website design and usability, looking quite specifically at a website to see what elements of a particular page were going to be of use to different personas (and also which elements were not going to be relevant). To use the personas you have to put yourself in their place and look at your website through their eyes. So what are they looking for, what is their level of experience or knowledge, for example. It does throw up some really useful insights into how your website is viewed by users.
In the second exercise, the personas were being used at a much earlier stage of the design process, to help look at priorities for the future direction of the Virtual Learning Environment by thinking about what the attitudes of different personas would be to a set of statements about developments. That was quite a useful exercise as it allows you to think about how your users and potential users will react to or view things you might develop. Hopefully it would prevent you contemplating developing services or features that wouldn’t be wanted by users.
Personas have been used for a while to look at both websites and the VLE at the University. To an extent they have been created around market segments and with students/potential students as the primary focus, but there are plans to develop others and to make personas much more widely used as a design tool. So although the ones that exist are of use when planning and developing a library website, there are a few missing for our purposes as we’ve also got staff and researchers to consider.
Although it’s now a bit late in our website design process to use personas for the design stages I’m certainly thinking about using them as a tool to check and review the site, and will see whether we can use them much more in future. A useful tool for website design.
We’re in the middle of a set of usability tests as part of our work on the new library website and my colleague who is running this work suddenly came out with the comment ‘the user is not broken’. It wasn’t a phrase I’d come across but it seemed to perfectly sum up what was the right attitude to why we do usability testing.
I’m told that the phrase dates back to a meme in 2006 from Karen G. Schneider (there is a copy of her presentation here and a blog post here
The user is not broken.
Your system is broken until proven otherwise.
That vendor who just sold you the million-dollar system because “librarians need to help people” doesn’t have a clue what he’s talking about, and his system is broken, too.
It seems to me to have exactly the right attitude to bear in mind when you are testing your website. You have to build your website so it can be used by your users and you shouldn’t have to provide them with training to use it. So if usability testing identifies features that users cannot easily use then those features are broken. And that is a tough thing to accept. The standard library approach (and I’m not sure if it is peculiar to libraries and librarians) is that we will provide helpsheets, guidance, training sessions and signs to help users, i.e. we try to ‘fix the user’ as if they were broken. But if you look at the commercial web world (Apple with their iOS 5 upgrade for example) then they launch their website or software, provide some information about the features, but don’t ever really offer lots of training on how to use it. Maybe that is a product of extensive testing and confidence in their product but I’m not so sure that that is it.
In part, at least I think there is a matter of scale at play. If you run a physical library and your users visit your library building then you do have day to day contact with your users, but even so, you don’t talk to every single person who comes into your library, or provide them with individual guidance. They might see a helpsheet or leaflet, but they are more likely to use your services by trial and error or following what other people do. With a virtual library you actually talk to a tiny fraction of your user community and can only realistically be able to provide training to a handful of users. So your systems, websites etc have to work, with a minimum of on-screen guidance. Have you ever seen a user guide to a cash machine? No?, thought not.
