Skip to content →

Managing a project to design and install library self-service software


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.


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:

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

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

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

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 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:

We’d use these later in the project:

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:

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.


Commissioning our own web app has several advantages:

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.