I am starting a new project with the Oxford University Museums to work on making art more accessible. My role is a technical one but I love visiting the museums concerned and it feeds out of an interest in audio and sound.
One of the challenges at the moment is to create user stories for both haptic and audio experiences. From this, I expect to break them down into use cases.
The user stories will be shared with the other members of the team for comment and feedback. As the main technical person on the team, this provides challenges in being able to explain the format and needs for a user story (let alone a good one) and also to provide examples using non-technical language where possible.
This means being able to communicate with other team members and to remind ourselves that we are all learning each others’ language. From this, I hope that we can build a common language and agree on what we mean by certain terms: tiles, track, description and so on. This is a must for the strands (or tasks, if you prefer) to work together effectively. We all bring vastly different skills to the team. This is part of Evans’ Ubiquitous Language discussed in (Evans, 2004) where one of his many arguments is that the edges of business and technical development require a common understanding of terms and develop a language that means all parties really understand each other and share common meanings around a specific domain.
My first task was to go back across our original project document to extract the points that we made as a team. I put these into a spreadsheet using the Connextra format:
"As a <role>, I want <goal/desire> so that <benefit>"
Using a spreadsheet allows me to re-organise by user and to add extra fields so that I can link any stories together. It also enables the sharing of them across sites and allows the team members to update the fields either through some testing or a new insight.
From this, I want to derive the use cases so that tests can be developed against them. For me, the end result is providing a good user experience through the user interface so that seems the obvious place to start with the tests. From there, we drill down into the layers, linking this all back together.
A prototype should be built as very rough mock object. The need for this is two-fold: firstly, we need a set of interfaces to test against, and secondly we gain a deeper understanding of the domain. This code is rough and ready, intended to be replaced through the development, but it provides feedback and can be put into continuous integration.
One of the testing challenges that I see is that of haptic and audio and how one automates it on a research grant and budget. This is going to require some serious research. I do wonder if the interface parts of UML or CAVE language will help with visual expressions or if this requires research as well. Whilst these may not part of the agile process, they are important for documenting what we did and why.
No Comments