Leon Paternoster

Self-service for libraries

Building an innovative, lightweight, web based self-service system using the latest offline techniques.

project management, strategy, sales
Clearleft, Dootrix
A small self-service unit.


I conceived, managed and implemented a project to replace self-service machines throughout Suffolk’s 44 libraries. We built an innovative, web based system using the latest offline techniques. The project had a small, fluid budget and tight development and implementation deadline.

You can buy this system for your library service.


In 2015 Suffolk Libraries began to think about replacing its aging self-service kiosks. The kiosks consisted of a client running on Windows XP PCs, and had given us several problems:

  • XP was no longer supported by Microsoft
  • The software was slow and buggy
  • Support was expensive and variable, provided by a 3rd party
  • The machines were dated: large, ugly and not particularly easy to use

We looked at using existing replacements, but found them unsatisfactory:

  • They all ran on Windows clients, meaning we’d have to update and manage the software on dozens of kiosks
  • The providers made us buy both the software and the hardware
  • The hardware seemed overly designed for its basic purpose of checking books in and out
  • The software appeared dated, and not particularly user-friendly
  • They were expensive

I therefore thought about what we’d want from an ideal system:

  • Decoupled hardware and software, so we could choose what hardware to use, and swap out faulty components when necessary
  • Affordability
  • Easy to manage software

The obvious solution to our problem was a website. This offers several advantages over a client:

  • It can run on any device and any OS with a web browser
  • You don’t have to update any client software: update the website and all kiosks are updated
  • Responsive design means it’s easy to scale your software to any screen

I felt strongly this was a good idea, but would it be viable? If so, what form would it take? What should we be looking for? I decided to run a design sprint to find out.

Research phase: A feasibility study and design sprint

I chose one of the most respected digital agencies in the UK to carry out some research into what a web app might do, and look like.

I worked with Clearleft over a week, interviewing staff and customers, investigating the feasibility and technical aspects of our proposed approach. We did lots of different activities, some structured, some more free form.

At the end of the week we had:

  • A detailed report
  • Web app mock ups

We’d use these later in the project:

  • The report formed the basis of our request for proposal and helped define what the app would do, and how
  • We used the mock ups in the development phase, saving design work later

Read more: A 5 day sprint with Clear Left exploring library self-service machine software

Procurement phase

Having decided on the web app approach we needed to find a developer to build it.

Our Clearleft report provided the basis of a request for proposal. Instead of providing a long checklist of technical targets, I identified ten or so important features the app would need to provide, such as:

  • Platform and OS agnosticism
  • Clear user feedback
  • User-friendly error handling
  • The ability to work offline (perhaps using service workers)

We invited three developers to submit proposals and scored each against how well we thought they’d be able to meet my ten requirements. We weighted what we thought were the most important, and also scored on value for money, clarity and how dependable we felt they’d be.

Read more: Build user requirements into your requests for proposal and avoid long functional check lists

Development phase

Having carried out a research phase and armed with an app mock up, I felt we could jump straight into developing our app. This was important as we were working to a five month deadline.

We followed a sprint methodology, which consisted of agreeing work, doing it over two weeks, reviewing it and then agreeing a new sprint. It meant we could change ideas that didn’t work relatively easy, and re-prioritse features – we only had a limited amount of money and time.

I tested our prototypes regularly on customers. I also installed kiosks running our web app in four ‘beta’ libraries to get some real feedback over a two month period.

Deployment and use

The kiosks have worked successfully for three years across Suffolk’s libraries. They’ve also helped us deploy “pop up” libraries in other organisation’s buildings.

Longer term, we can look at using better, cheaper hardware as the initial devices reach the end of their use. Similarly, we can replace the enclosures, looking at a wider range of companies.

Because the software and hardware are decoupled, we can also investigate even smaller kiosks, perhaps installed on a handheld device.


Commissioning our own web app had several advantages:

  • Smaller, more portable kiosks that we can deploy anywhere, e.g. in library foyers, at events, in “pop up” libraries and on mobile libraries
  • Decoupling software and hardware
  • Better value
  • Flexibility to create our own kiosks, e.g. through using different devices, enclosures and operating systems
  • Product ownership
  • Easier to manage and deploy

Running a project like this involves a lot of work; it’s a lot easier to buy an off the shelf product. However, libraries should be looking to improve library user interfaces, and sometimes that means getting things done ourselves.