I’m not sure how many people will be familar with the work of Oliver Postgate, and specifically of his stop-motion animation series, The Clangers. One of the characters in the series is Major Clanger, and he’s an inventor.
The character always comes to mind to me when thinking about development approaches as an example of a typical approach to user engagement. So the scene opens with a problem presenting itself. Major Clanger sees the problem and thinks he has an idea to solve it, so he then disappears off and shuts himself away in his cave. Cue lots of banging and noises as Major Clanger is busy inventing a device to solve ‘the problem’. Then comes the great unveilling of the invention, often accompanied by some bemusement from the other Clangers about what the new invention actually is, how it works and what it is supposed to do. Often the invention seems to turn out to not be quite what was wanted or has unforseen consequences. And that approach seems to me to characterise how we often ‘do’ development. We see a problem, we may ask users in a focus group or workshop to define their requirements, but then all too often we go and, like Major Clanger, build the product in complete isolation and then unveil it to users in what we describe as usability testing. And all too often they go ‘yeh, that’s not quite what we had in mind’ or ‘well that would have been good when we were doing X but now we want something else’.
So how do we break that circle and solve our users problems in a better development style that builds the products that users can and will use? That’s where I think that a more co-operative model of user engagement comes in. It starts with a different model of user engagement, where users are involved throughout the requirements, development and testing stages. And that’s an approach that we’ve started to call ‘co-design‘, and have piloted during our discovery research.
It starts with a Student Panel of students who agree to work with us in activities to improve library services. We recruit cohorts of a few dozen students with a committment to carry out several activities with us during a defined period. We outline the activity we are going to undertake and the approach we will take and make sure we have the necessary research/ethical approvals for the work.
For the discovery research we went through three stages:
- Requirements gathering – in this case testing a range of library search tools with a series of exercises based on typical user search activities. This helped to identify the typical features users wanted to see, or did not want to see. For example, at this stage, we were able to rule out using the ‘bento box’ results approach that has been popular at some other libraries
- Feature definition – a stage that allows you to investigate in detail some specific features – in our case we used wireframes of search box options and layouts and tested them with a number of Student panel members – ruling out tabbed search approaches and directing us much more towards a very simple search box without tabs or drop-downs. This stage lets you test a range of different features without the expense of code development, essentially letting you refine your requirements in more detail.
- Development cycles – this step took the form of a sequence of build and test cycles, creating a search interface from scratch using the requirements identified in stages one and two, and then refining it, testing specific new features and discarding or retaining them depending on user reactions. This involved working with a developer to build the site and then work through a series of development and test ‘sprints, testing features identified either in the early research or arising from each of the cycles.
These steps took us to a viable search interface and built up a pool of evidence that we used to setup and customise Primo Library Search. That work led to further stages in engagement with users as we went through a fourth stage of usability testing the interface and making further tweaks and adjustments in the light of user reactions. Importantly it’s an on-going process with a regular cycle of testing with users to continually improve the search tool. The latest testing is mainly around changes to introduce new corporate branding, but includes other updates that can be made to the setup or the CSS of the site in advance of new branding being applied.
The ‘co-design’ model also fits with a more evolutionary or incremental approach to website development and is a model that usability experts such as Nielsen Norman Group often recommend as users generally want a familiar design rather than a radical redesign. Continuous improvement systems typically expect incremental improvements as the preferred approach. Yet the ‘co-design’ model could equally be deployed for a complete site re-design, starting from scratch with a more radical design and structural changes and then using the incremental approach to refine them into a design that meets user needs and overcomes the likely level of resistence by users familar with the old site, by delivering an improved user experience to which users can quickly get comfortable with.