You are currently browsing the tag archive for the ‘library website’ tag.
“Benchmarking is the process of comparing one’s business processes and performance metrics to industry bests or best practices from other industries. Dimensions typically measured are quality, time and cost. In the process of benchmarking, management identifies the best firms in their industry, or in another industry where similar processes exist, and compare the results and processes of those studied (the “targets”) to one’s own results and processes. In this way, they learn how well the targets perform and, more importantly, the business processes that explain why these firms are successful.” http://en.wikipedia.org/wiki/Benchmarking
It’s easy enough to describe what benchmarking is, but the critical question it seems to me is who do you benchmark against, particularly when what you are benchmarking, is a web-based experience. Is it enough to benchmark against organisations who are competing for your customers directly in the market in which you operate, or do you need to look more widely? For comparability you can argue that only those organisations who are in the same business as you are offer a way of directly benchmarking what you do with what the best the competition can offer. And yes, I’d agree with that.
But I’d argue that you are also competing more generally with a wider group of comparators, in that you are competing for your customers (or potential customers) time and attention, and I think that you are competing on reputation with the best examples who are operating in the channel (i.e. the web) that you are using. And I feel that that argues for a wider range of benchmarking comparators.
So what groups would I expect us to benchmark against?:
- libraries in distance learning institutions who might be offering a similar set of services to us, both direct competitors in our own market, but also those in other markets
- wider HE libraries – even campus-based, will all be offering an online experience – it might be additional to their location based service, and some of their services won’t be relevant – but may still have valuable lessons – and these again would not just be local competitors but would be from across the world
- sector organisations and service providers – these could be the best of cultural organisations such as museums, or service providers such as discovery system providers or content providers or other organisations in the sector
- commercial service sector providers – online shopping and online supermarkets, concierge-style services, other online public services and commercial services – all are competing for attention and define what an online experience should be like
- social, communications, media systems and organisations – news organisations for example. But these types of websites are often good examples of best practice and also environments where our users will spend a great deal of time, influencing their perception of what makes a great website experience.
So there’s quite a range of different types of organizations and websites that I’d want to look at to see what we could learn about how to make our website better. In the same way as the hotel industry has influenced the concept of boutique libraries, then there are lessons that we can learn from other sectors that will help. So for example, concepts around using recommendations for library resources can draw on practices from websites such as Amazon.
There’s one final thought about benchmarking, in that the most important group to ‘benchmark’ against is your own customers. What are their expectations? You may have a list of good ideas that come out of your benchmarking exercise, but which of them would your customers prioritise?
Workshops… and yet more workshops
In parallel with some of the technical preparatory work we’ve kicked off a series of workshops with our staff. Organised by one of the web team we are using them as a way of getting library staff involved in the process and generating some discussion about aspects such as user requirements. These ideas then lead on to a prototype information architecture and a set of ideas that can be tested with users to validate or modify them.
So far we’ve run three different workshops. About half of the library staff have been to at least one of the workshops so we’re pretty pleased at the amount of engagement we’ve had so far. And they’ve brought up a lot of interesting ideas and some challenges. In this blog post I’m going to outline the activities that we’ve been running and put down some thoughts about the things that are coming out of the workshops.
We kicked off the process with a small workshop with participants drawn from the two groups in the library who are most closely involved with the website: our website editorial group and our User Experience Group. Between them there is representation from across the library, with a strong core of learning and teaching librarians, who have day to day contact with users via our library Helpdesk service.
The workshop was asked to carry out an exercise to identify the different types of users of our website, identify what their needs were, why they were coming to the website, and what tasks they were trying to accomplish. The background to this is that at the moment there is a single website that tries to meet all user needs, yet the library services that are available to students are distinctly different to those available to academics for example. So, whilst knowing how to renew a library book is important for an academic based on campus it isn’t much use for a student who isn’t able to borrow.
This workshop was open to staff across the library as part of our regular programme of Staff Development activities. In an hour-long session a fairly large group were asked to carry out two activities. Firstly a card sort exercise, taking the current 2nd level website titles and structuring them into what seemed like a logical structure. They were also asked to comment on any terminology that was unclear.
As a second exercise the group was asked to look at some examples of retail websites and look at them from the point of view of their Help and Support services. This exercise was to get staff away from a narrow view of what library websites could be (as there is a tendancy for them to end up with similar features – although you could argue that they are trying to meet similar needs).
The final workshop had a smaller number of staff (about 10) from across the library and again looked at the website structure. The workshop looked at the output from the earlier structure workshop and refined it further. It also looked again at page naming and how best to handle the different requirements of distinct user types.
Outcomes and reflections
There were a few key messages coming out of the workshops.
- Separate landing pages for some of the main user groups may be a good idea – this implies users having to login which opens up some customisation and personalisation potential but means that users would have services relevant to them on the home page
- A simpler structure and simpler terminology e.g. About Us rather than Library Information
- Language should be used that is more familar to students
- Some pages need better names, could be dropped or merged – there was quite a lot of feedback that it wasn’t clear what some pages were about
- Where pages have information aimed at different user groups then they either need to have a consistent format (i.e. always with the student information at the top), or be split into separate pages that are fed to appropriate users
As an output from the workshops we now have a prototype Information Architecture and some ideas around naming conventions. Our next step is to start to check these ideas with users, probably through surveys at this stage. So we will want to check what they want to see on the home page, how they would like the site to be structured and what they would prefer sections to be called. Ideally it would be good to use something like treejack to help with testing the structure.
As with any project one of the key steps is to plan how you are going to go about your task. So with our library website migration we sat down to work through the stages we will need to go through between setting out the initial objectives, as described in an earlier blog post and the new site being launched. So in this blog post I’m going to cover the stages we are planning to break our website migration project into. Some will be unique to us as they reflect our particular circumstances, but others will be more generic.
We’ve arranged the stages as a series of workpackages covering different themes rather than as a straightforward set of tasks arranged by date. It tends to be a bit easier to work out where you are by grouping the tasks in themes or workpackages. To draw up the plan we’ve been using Excel as a high-level tool. It’s a bit easier for people to look at an Excel version of the plan (using a great Excel 2007 template for gantt charts) rather than having to use MS Project. For project management purposes we’ll use an MS Project version. So the Excel version looks like this:
We’re planning to split the project into workpackages that cover the different themes of the project, so, for example there are workpackages covering the technical preparation of the site environment, activities around reviewing and migrating content, a workpackage covering usability and accessibility testing, and another one around the creation of a mobile version of the website. [I’m still getting used to the idea that the mobile library isn’t a large bus full of books – too many years struggling to get reliable online technology onto them I suppose!].
Workpackage 1 – Site setup
This is covering our site preparation activities, from agreeing the URL, through setting up the test environment, loading the design templates, configuring the site structure and setting up the standard website features. In the main this work is being carried out by our website developer with help from other university colleagues. The bulk of this work happens in the first few months while we are on the development site.
Workpackage 2 – Content
This covers a wide range of tasks from reviewing the Information Architecture, through looking at User requirements, to reviewing the content, documenting new processes and then training staff, and the actual content migration into the new site. There’s a lot of preparation needed so it’s one of the earliest workpackages to start. So we’ve begun with some workshops to look at the current Information Architecture and user requirements. We’ve been looking at results from surveys, from user feedback and at analytics data to inform that work. One of the next steps will be to survey users with some specific questions about the website. This then needs to be pulled together into a prototype Information Architecture that can be tested with users later in the year.
Workpackage 3 – dynamic content and search
Our current website displays some content as lists taken from our library catalogue and other sources. These include lists of databases, ejournals and FAQs. Our analytics data show that these are the most popular elements of the site so we need to retain these in the new site. Generating them dynamically from systems where they are already being updated is much more sensible than having to create a separate static list and then update it. Search is also a very important element of our site, whether that is search of our electronic resources, library catalogue or the website itself.
Workpackage 4 – Help and Support
Analysing our site shows that a large proportion of our content is Help and Support materials such as FAQs, How To guides and other help materials. Finding a way of helping users find relevant help materials more easily on the new site is a key objective for this workpackage.
Workpackage 5 – Mobiles
We’ve had a mobile version of the website for a few years now. It gets a steady stream of users, mainly ipad and iphone but with an increasing number of android phone accesses. As part of this workpackage we are working with other university colleagues to create a new version of the mobile library website.
Workpackage 6 – Testing
Although the plan is very much to test as we go along, we’ve put our testing into a separate workpackage, as much as anything, to make sure it gets the attention it needs. We’re planning our accessibility testing using a range of devices we have such as screenreader software. We also plan usability testing with eye-tracker software to check the prototype site. And we expect to make the site available in ‘beta’ to gain feedback and allow us to address any issues before the final launch.
Alongside the workpackages are the usal activities around project management, reporting on progress, managing risks and issues and communicating to stakeholders/users about progress. As we go through the project I’m going to try to update this blog with thoughts and reflections on how the project is taking shape.
Over the next few months we are planning to redevelop our library website. It’s a long process, there are a lot of different stakeholders and a lot of stages to go through. I’m going to try to blog about the process as we go along to try to keep a record of what we do, how it goes and what lessons we discover as we go through the whole website migration project.
I ‘m going to start with covering why do we want to change the website. What is driving the change?
- Feedback from users – comments from surveys and questionnaires indicate that users don’t find the navigation easy, don’t like the design that much and don’t find it that easy to find relevant help information. They particularly have difficulty with finding access to electronic resources.
- Feedback from staff that they would like different things to be on the homepage to what students want, e.g. services such as book renewals and document delivery, which in our institution is mostly of interest to staff
- We have an increasing range of different types of users (students, academics and researchers for example) and partners who all have a slightly different need from the website. The current website offers a ‘one-size-fits-all’ approach and doesn’t allow users to have a view of it that meets their specific needs or to allow them to customise or personalise it.
- ‘To be where our users are’ – increasingly we are wanting users to access our services directly from where they are (in the VLE, or in Google Apps) rather than by having to come to our website. So we want to facilitate that.
- We want to make more use of dynamic content, which we do to a certain extent already by taking lists of resources from the catalogue and presenting in the website.
- The Information Architecture of the site was designed in 2008 and we want to review it to reflect changes in the way our services have developed.
- We want to update the design of the website to give it a more consistent University style
- The underlying website technology ‘Cold Fusion’ is no longer a preferred website technology for us and we want to develop the site using technology that is more Web 2.0 friendly.
- Library staff working with other University units has thrown up some different ideas about how we might present help and support on the website. This has lead us to thinking about trying to deliver it in a different way – in context, so users get relevant help and support materials prevented in context, rather than being sent to a help page and being expected to search through lists of pages, videos and podcasts.
So our key objectives for the website migration are:
- improved user experience
- easier to navigate
- improved search – [being addressed partially by introducing a new third-party search system from Ebsco]
- personalised – so students get things that are relevant to them, academics get services relevant to them etc
- context-specific help and support – placed wherever you are on the website
- easy to access information about how to contact us to get help
- a cleaner, fresher design
- in a more Web 2.0 friendly development environment that lets us develop new services to keep pace with user needs
- ideally that we can develop services once that can then be deployed to wherever our users are – a type of ‘build once, use many times’ approach
Next time I want to start to look at the approach we are taking and the steps we are planning.
Most websites go through a process of continued development and change. I’d argue that they are never really finished, it’s just that every so often they get to the stage where you want to start again from a clean (or clean’ish) slate. Often the motivation is as much a feeling of we can’t do what we want to do with the site now, mixed with there’s other sites out there that look better, have better navigation or features for example. I’d also say that there’s an element of website ‘fashion’ that make sites look out-of-date even when they are perfectly functional but that it can drive user perceptions of a site. So refreshing a site at regular intervals is something I’d want to do. In between regular site redevelopments there will always be a myriad of minor or even major changes to the site and it is one of the challenges of website management to keep track of (and manage) these changes. To do that we’ve developed a process around a Website Improvement Plan.
The Website Improvement Plan
In essence the Website Improvement Plan is a document that outlines the steps you are going to take to address issues with the site and it works to shape the development of the site over a period of time. We only use the plan to record significant changes on the site – so we wouldn’t record minor content changes but would record an activity like adding a completely new section of content with several pages. There is quite a variation in the scope of the activities – so it can range from a task to implement a new search system, or to add a rolling news feature to the home page, for example. We use the plan as a rolling document across each year updating it as we go along. We have an approval process to get new items into the plan and we record the following information about each item:
- a unique reference number for each item
- a description of the item
- the date it was added to the plan
- details of the resources needed to deliver the item and a note if it forms part of a project
- the owner of the item – the person responsible for the item
- the date the change is required
- a category – we split tasks into categories such as Content; Infrsastructure; User Experience etc
- details of when the item was approved
- a status column – updated monthly that is used to track progress of the task
We then colour-code each item to make it easy to check which items are at which stage. So pending items are unhighlighted, approved but not yet started (yellow highlight), in progress (green), completed (grey) as seen below
Pros and Cons of this approach
The processes around approving items to go into the plan and reviewing them (done monthly at a Web Quality Improvement Group meeting) help to focus people’s attention on the work taking place around the website and let people identify where there are obvious gaps in work that is planned. We feed in activities from various projects and strategic plans to take care of the higher-level activities. It’s an open document so it is available to all library staff to view and it’s reported to various library management groups. As a tool to bring together everything we are doing it seems to work.
On the negative side – there is some added bureaucracy around managing the plan and some potential delays in making sure that people have signed off developments before they take place. There is a danger that you can end up managing the plan rather than the service.
We keep version control over the document so we can compare different versions of it. This means that we can track the number of tasks that are completed or in progress and how that changes across the year as a form of fairly crude metric around website development. Within the unit we also have activity data from staff that we can use to identify the cost of website services. For us the process seems to work reasonably OK for day-to-day website management.