As we’ve worked our way through the various stages of the library website project we’ve used a number of different tools and techniques.   These have included tools to find out what works on the current site, what users think, to plan how the content should be arranged and to engage with users and staff.  As we draw towards the launch of the site it seems like a good time to reflect on those tools, how we have used them and what they have told us.

We’ve been using Google Analytics for some time and in many ways it provides the foundation for our work around the website.  Google Analytics screenshot So it can be used to identify basic things such as which pages are being used in your current site (and which pages aren’t) and the paths that people use through your site. It can tell you where people are coming from to visit your site – so we know that a large number of our users come from our institutional VLE, which has informed our decisions about some of the terminology we use in the new site – we’re using Library resources to describe our ‘stuff’ to be consistent with the VLE.  Analytics gives us a vast amount of data and interpreting that data is key to any redesign project. 

Card sort exercises
It’s a pretty well established technique to use card sorting exercises to help with developing the information architecture of the site e.g.  As an early part of the design work we carried out this type of exercise with a group of library staff to try to get an idea of a sensible information architecture for the new site.  We ended up using it very much as a starting point rather than a finished article as we were keen to test it with users to validate it.  On reflection it does seem to be hard to get people to visualise how the website information architecture will translate to a navigation system in a real website.

An almost obligatory component of workshops, often found in combination with post-it notes and card-sort exercises.  Even in these digital times they still seem an inevitable element (along with post-it notes) when a group of people get together to plan something. 

Once we had come up with a prototype information architecture we wanted to test it with users to see if it made sense to them.   There are a few tools out there that allow you to setup quick tests for users to complete.  Essentially they allow you to ask users to navigate through a website structure to find a particular page.  They test whether your information architecture makes sense to users.  We went for a tool called Plainframe  It costs a small amount of money but had the advantage for us that the pricing was based on the number of tests you ran rather being time-limited.   We were able to offer the test to a group of users and it was certainly useful to see how they reacted to the site and has led to some tweaks in the IA.

We decided fairly early on that we wanted to find some different ways to engage with users.  So one of the techniques we used was to run a quick poll on the library website to ask students about features they’d want to see, particularly around ‘induction-type’ content.   Positioned prominently on the website homepage we got really good reaction with several hundred responses that greatly helped with defining the content for this section.

The key document for the project was a specification.  This set out the audience for the site, the page layouts, the information architecture and navigation.  So it was created as an output from the workshops, surveys and exercises. The intention was that it would be focus for discussions about what went into the site and end up as a tool that we would use to get agreement over how the site was to be created.  It probably didn’t work quite as well as we’d expected, we found it difficult to get people to engage with the document and visualise what it would look like when turned into a real website.  And we ended up having to make changes to things like the IA once the site structure started to take shape. 

In an ideal world with a project of this nature you want a functional specification that is created and agreed before any development work starts.  In reality it is diificult to do that when you move to a new platform like Drupal as you don’t always know when you start exactly what is and isn’t possible.  Users often need to see some form of prototype to be able to decide what they want, and a paper prototype (whilst useful) isn’t always enough.

One of the starting points for us was the results (and particularly the detail) from the Library Survey that was carried out in 2010.  Although the results were good it did identify some particular problems with search and accessing library resources.   

We’ve also been conscious throughout the project that there is a big issue around terminology (something that libraries seem to have a particular problem with).  Users seem to struggle with library terminology so we used further surveys using a tool called Survey Monkey ( to design questionnaires for users to find out their preferences on the information architecture and terminology of the site.  SueveyMonkey logoWe will also use SurveyMonkey to capture some structured feedback from users once the site goes into the beta and launch stages.  We find SurveyMonkey really useful to run surveys and use it extensively to get feedback from users and it lets you design a series of questions and then collect, analyse and download the results in a way that can be easily analysed.

One of the main techniques used to plan out what your website is going to look like when it is built.  Website wireframeWe’ve made extensive use of wireframes for the home page and sub-pages within the new site.   I think they are essential to help to visualise what the site will look like, but I am aware that some people find it hard to visualise what the website will look like from a wireframe and want to see something that looks much more like a prototype website.

W is for … Workshops
We found that we used workshops extensively in the project.  In the initial stages it was to help with user requirements and information architecture.  We’ve made a lot of use of them to help with the work around arranging the subject categories and subject resources.  They can be quite time-consuming to setup, run and particularly to analyse the results, but they have the distinct advantage of being a great way of getting people engaged with the project and creating new ideas.