When we develop software, we are guided by our customers to tell us what they need. Quite often, however, the people who will be using the final product are not our customers, but their customers. To put the icing on the cake, we need to do some Usability Testing with real users. Such as Chris.

Chris Who?

Chris McLaughlin is a former colleague of mine who now runs a a busy academic bookshop at Glasgow Caledonian University. He has a button named after him. The Chris Button. Well that’s what we call it, anyway.

Testing, Testing …

As software developers, we’re testing things all the time. As soon as we have written a chunk of code to do something, we will test it to see if it does what we want. The bigger the system gets, the more we need to test, and of course, if we go back and change something, we need to test that the change hasn’t broken something else. You can’t really get away from that kind of testing. However, that’s not what I want to talk about today. This article is about the importance of usability testing, which can often be overlooked.

What is Usability Testing?

Usability testing involves evaluating a working piece of software by presenting it to a user – a real user, preferably someone who is going to be using the finished product – and observing what they do with it. There are no rights or wrongs for the tester, we just want to know what they make of the software, so we resist the urge to jump in and correct them when they do something unexpected. We can learn a huge amount by watching (and listening, if they are happy to think aloud as they test), and this can feed back into the software design to make the next release better.

A New Returns Solution for the Book Industry

In 2009 I was working on a project to implement a returns system for books. The book industry has an agreed process whereby bookshops can return books to the suppliers if they don’t sell within an agreed timescale. First they have request permission from the supplier. The supplier responds with an authorisation message, which indicates how many copies they will accept, and then, all being well, the books are returned, and the shop sends a third message to the supplier to let them know how many copies have actually been sent. This whole process can be done manually via email, fax or (in the old days, when I was a bookseller) by post. However, it is time consuming, and tedious. The Batch Returns service provides a standard way for booksellers and suppliers to send and receive electronic Returns messages, resulting in a turnaround time of a few hours. The only manual bit is putting the books into boxes.

Giving Something Back

I was delighted to be working on this project, given my bookselling background; I must have handled thousands of book returns, and reams of associated paperwork, twenty-odd years ago before Batch Returns even existed. And here I was, giving something back. However, mindful of the fact that I hadn’t worked in bookselling for several years, I was keen to get real users involved in evaluating the system as development progressed. I made a few phone calls and arranged to visit Chris at his shop to show him what I had so far. I think I met with him three times in total, and each time I would come away with a few ideas on how to improve the interface and the workflow. During one of our meetings I learned that he sometimes needed to return a long list of books, each with the same quantity, and that using the arrow keys to move down the list adjusting the quantities one by one was a pain. I took this on board and on the next visit I introduced him to the Chris Button which was well received.

The Chris button allows users to quickly set all quantities in a long list of books to the same value.

On seeing the Chris button, Batch recognised its potential on other screens, and we added a variation to the suppliers’ interface to speed up the process of authorising returns.

The “Set All” Button on the Suppliers’ Authorisation screen offers a choice of fields to set.

The idea of a button which allows the user to apply the same action to multiple lines is by no means groundbreaking. We see it in software all the time. But this story highlights the importance of spending time with end users, learning how to make their experience better. Never assume you know better than a real user.