User Stories are an approach used in software development and product management. They are a method of defining the functionality of the product, by capturing what the user of it does or needs to do as part of their job.
It is important that user stories are not confused with use cases. Where use cases cover processes and workflows, user stories are short and concise (1-2 sentences), written in everyday language to express the ‘who’, ‘what’ and ‘why’ of a specific requirement.
An example would be:
As a teacher, I want to search for resources by their qualification level
The various user research activities undertaken by the project to date, have helped us develop a significant number of user stories. These include:
- Two online user surveys
- Outreach workshops with practitioners
- Discussions with users at RSC forum meetings
- Anecdotal conversations with practitioners
- Market research study – 40+ hours of targeted interviews with FE staff
Together, these activities have given us a rich insight into some of the perceptions and uses of Jisc digital resources for FE. They have also highlighted some of the barriers FE practitioners encounter when finding and using digital materials, and the kind of things they would wish for as users of the FE Skills Window.
Developing the stories
In particular, the findings of the market research done by Alchemy Research has given the project a great deal of rich information – in the form of bullet-pointed overviews of the report, and specific quotes included from those interviewed.
To pick out just a few …
|“What would be useful is if somebody had already gone through them and said what can be used for what subject.”||“My thoughts are that it all needs to be in some sort of central way, a central location and then the different technologies just access it.”|
|“People would say if it takes three clicks, students won’t do it, two they might.”||Enhance the ability to share materials.|
|Confusion with scope/volume of digital materials available.||Restrictive licence agreements.|
Using these findings, along with the responses to surveys and the ongoing conversations with practitioners, the project has developed a collection of over 40 user stories. First though, we broke down the requirements into three key areas:
- Searching for resources
- Viewing results
The first two of these are self-explanatory. The third, “interactions”, is what we considered as extra actions that users would like to take once they have found a specific resource. This includes such things as sharing, previewing, commenting, and ‘rating’.
The table below gives a brief example of just some of the stories we have developed across these areas.
|As a lecturer I want to search for resources by subject||As a user I want to see search results that are easily digestible, so I don’t get overwhelmed by the list of results being displayed||As a learning technologist I want to easily email a resource link, so I can quickly share a resource with colleagues|
|As a user I want to search from a single place for resources so I don’t have to visit multiple sources||As a librarian I want to see any subscription models attached to material, so I can tell if we have access to the resources from our organisation||As a lecturer I want to tweet the link to a resource and its description, so I can easily share it with my professional network|
|As a lecturer, I want to simply type in my free text search, so that I don’t have to think about using more advanced search conventions.||As a lecturer I want to see how old a resource is so that I can easily assess whether the material is up-to-date||As a learning resources manager I want to access resources with as few clicks as possible, so I don’t find myself having to visit a new site and use a new interface to actually get the material|
The next step the project has taken was to apply the MoSCoW method to prioritise the stories and better organise them before passing them to the technical developers on the team. This is a technique used to place the level of importance of each requirement (function).
M – is a MUST (happen)
S – is a SHOULD (happen) – often still a critical requirement but one that can be satisfied in other ways
C – is a COULD (happen) – Definitely desirable but not strictly necessary. Included if time and resources are available
W – is a WON’T (happen) – Maybe looked at for a later version
In this way we’re looking to prioritise the requirements – and, as ever, we are asking for your input and thoughts.
The project is using Trello – a free, web-based project management application, to create our user story ‘cards’ – and manage the workflow between the community engagement and requirement gathering of the project, with our technical developers.