Specifying user requirements: workflow to deposit use cases

What came first, the chicken or the egg? Or in the case of a technical project such as this one, who came first, the developer or the user? In my experience, working in a computer science group that produces an unending stream of talented developers, it’s invariably the former. In a twist on this theme, here we seek to inform the design and requirements collection for enhancing repository deposit by working with users, content creators such as scientists, and content curators such as repository managers.

Developers work on instinct and an unflagging belief that what they do will work (after a bit of debugging). They turn complex problems into solutions in ways that can amaze the rest of us. Towards the end of the work, however, often there can be a lack of time for full user testing, or little interest in the results.

Does what it says on the tin, photo by chris5aw

If it does what it says on the proverbial tin, who specified the problem, and whose requirements are being addressed? Many developers will argue they know the intended use case and the users (for it is they). This can work well for original, highly innovative products or for projects sans users. In other cases, where users are key, or which are refinements and extensions of known products, the outputs will have to be measurable against clearly specified requirements, ideally with reference to real users. This project falls squarely into the latter category. Repository deposit interfaces are hardly new – how could they be – so what we seek to add has to be measured against what is already there.

It is important this is addressed before devising a plan for test and evaluation of the product, otherwise you may end up testing against a limited set of (developer) requirements – it works exactly as the developer said it would – or it doesn’t work with reference to a wider set of (user) requirements, because that’s not what the developer was building.

DepositMO has been a developer-driven project, with a team of developers working for it. As you can tell from entries to this blog, unless we missed something big we have some concepts so far, but not yet implementations for users to try and for us to report. We have requirements, set out in the project proposal, but technical frameworks can be a moving target. For example, we are working with the technical advisory group to produce the next version of SWORD, v2, which we expect will be a core component of what the project produces. That has yet to be finalised.

So at risk of a wilting response from the developers – “you can’t do that”, or “that won’t work” – we convened our user panel, sans developers (well, one crept in, but with a different hat on), to establish a preliminary plan for user testing and evaluation of the products and services from the DepositMO project, and to sketch out some use case scenarios based on identified scientist/author/repository workflows. It’s the use case scenarios we will concentrate on here (Table 1).

Represented on this panel, ultimately, are scientists at the University of Southampton from a number of disciplinary areas – archaeology, chemistry and materials science, as well as representatives of different institutional repositories, notably EdShare, which presents teaching and learning materials, and ePrints Soton, the university’s main institutional repository, which focuses on research papers and presentations. Table 1 shows feedback from a meeting of some from this panel held on 21 January.

Table 1. Use case scenarios leading to deposit for sciences and repositories

What does Table 1 reveal? It confirms that scientists are creating a variety of digital content and formats, not just text, using different applications but noting that Word remains in wide use, which is good for our project approach. Prior to publication this content is shared informally between team members using a range of methods. In terms of sharing, Dropbox emerged as the joker in the pack. It was suggested that this service is popular among the colleagues of our scientists. We shall investigate this service further in a later blog post, but one feature to be commented on is the use of Windows Explorer as a file deposit tool for use with Dropbox. A file management interface is on the agenda of our project developers.

Table 1 also shows that the repository requirements are not the same as those of the authors, and that by virtue of their different collection requirements, so the requirements of the two repositories will differ. These all have implications for the design and functionality of the proposed deposit interfaces, which connect authors with their chosen repositories. One requirement not recorded here is for single-click deposit to multiple repositories – that is already a design requirement and one of the original promises of SWORD – but perhaps not a straightforward task given even the brief repository findings here.

The need to find and list works by an author for later update has already been identified as a developer requirement, but mention of ResearcherID introduces a specific service providing author identification.

From Table 1 we can expand a possible use case: etheses. One of the problems, we are told, in making etheses available open access via repositories is the need to embargo sensitive or commercial content. It is usually the case, however, that not all the text need be embargoed, just certain sections, but because the thesis typically exists as a single document the embargoed material cannot be separated from the rest. It was suggested that a deposit approach might encourage a thesis to be deposited in sections, or ‘chunks’, allowing an embargo to be set for affected sections but with access to the rest.

BTW, in view of our emerging table of requirements an additional case study might be drawn from a recent paper by colleagues at Southampton (and elsewhere; 16 authors!) which describes scientists’ workflow, reuse, and publication in virtual research environments (VREs) such as myExperiment (rather than repositories): Why Linked Data is Not Enough for Scientists.

We shall return to the task of building a test plan at the next meeting of the user panel. Watch this space.

I am grateful to Kate Walker, Mark Scott, Debra Morris and Simon Coles for their contributions to this work.