One of the outputs of interviewing the stakeholders was that we have developed some user stories to describe the thoughts of the stakeholders. A user story takes the following form:
“As a <role>, I want <goal/desire>
so that <benefit>”
As you can see, it states who the user is, what they want to be able to do and the reason for wanting that.
Below are our collection of user stories developed for the student dashboard. It is a work in progress, so we will add more and amend them as we validate them with the stakeholders.
“As a <role>, I want <goal/desire>
so that <benefit>”
“As a tutor, I want to see a photo of my tutee
so that I can recognise who I am meeting”
“As a senior tutor, I want to access mobile telephone numbers
so that I can contact students that have gone AWOL”
“As a tutor/senior tutor, I want to see my tutee’s exam and coursework marks
so that I can support and advise them appropriately.”
“As a tutor, I want to see my tutee’s mitigating circumstances
so that I can ensure they are taken into account on the exam board.”
“As a senior tutor, I want to see my e-mail communications with a student
so that I have context for our meetings.”
“As a student, I want to know see my predicted degree grading
so that I am aware of my current performance.”
“As front desk staff in student services, I want quick access to all of a student’s data
so that I can deal with their inquiry immediately.”
“As a careers advisor, I want to know the course title, length of that course and which year a student is in
so that I know whether to offer advice on getting a summer placement, or applying for jobs.”
“As front desk staff in student services, I want to know a student’s alternative contact e-mail address
so that I can communicate with them prior to their enrolment, or while they are suspended.”
“As a member of faculty student services, I want to see a student’s timetable
so that I can tell them where they need to be when they ask.”
“As a tutor I wish to see a list of engagement indicators for each of my tutees. Indicators such as Attendance, Coursework Hand-in, Induction attendance, etc. Along with some straight forward factual info like A level marks, and marks obtained so far. This is an “early warning indicator” so that I can spot troubles as early as possible.”
Indeed if you have any comments or suggestions for user stories, please add them below, though we will have to compare them to the feedback we have had from our stakeholders.
On 13th October Derby hosted a cluster group meeting – the first one that Southampton have been able to attend.
Derby are doing a traffic light / dashboard on Student Engagement. They have a very useful Fried –Egg / target diagram of primary, secondary and tertiary indicators of (lack of) engagement and including miscellaneous at risk groups. We discussed the possible role of tutor /teacher “hunches” in predicting engagement and future success. The contact is Jean Mutton.
Loughborough are looking at final year progression and factors that effected students, with a view to informing relevant people of issues. Malcolm King indicated that they had probably collected too much data – some of which indicated things they could do nothing about.
Roehampton are doing work on an academic warning system which is combined with an on-line system for handling mitigating circumstances. The early warning system is using usage information from their VLE along with attendance information.
All three institutions reported that they had a lecture/tutorial attendance register system. This technology is quite advanced now…
We (Southampton) introduced our student dashboard as being the mash-up presentation of the data we have about students in different places at the “right time, in the right format for the right person” (See my previous blog post). And we discussed the issues of privacy and who should be allowed to see what data, and the student’s role in this decision. We were given some useful suggestions
- Look at what data other universities distribute to appropriate people. Apparently at Loughborough tutors have access to almost everything the university knows about the student (on paper). Tutors need to be frequently reminded of their responsibilities not to discuss this with the wrong people, over the phone etc.
- What is our initial contract with students concerning the use of data. Have they signed up for data being used this way? If not, why not?
- We could hold some kind of Hackfest/Camp inviting representatives of all stakeholders. The idea would be to look at privacy e.g. comparing Facebook with University systems.
Another realisation from the meeting for me was that what we are doing could be more than just data – it could be about “engagement analytics” (Jean Mutton’s expression). An interesting experiment that was suggested in the discussion was to compare tutor/teachers’ “hunches” with predictions for success/failure from other analytics factors.
We agreed with Lauren Currie (@RedJotter) that we would have a discussion again in a couple of months when we had developed our scenarios and story boards. However, we also offered the group that we at Southampton would be happy to host the next meeting in Southampton – and that in this meeting we would “show and tell” our storyboards and any early prototypes. I’m going to look at offering something early next semester (Feb 2012). It might make sense that if Lauren is attending this we could combine the two meetings.
In my previous posting I said that the purpose of this project is to make the information about students that we have available though many systems in the university available to the right time in the right format for the right people.
This posting is concerned with “right people”, and will be the focus of our topic at the action learning set at the cluster meeting in Derby.
Clearly a great deal of the information we have about our students is “sensitive”. For example we have marks, learning differences, fees status, accommodation details and maybe even self reported medical or psychiatric details. Who should be able to see all this? This subject will be a major issue for our project – and no doubt the data protection act will be called into the act many times by those who are frightened of sharing their data.
Well who can see these things?
- The personal tutor?
- The senior tutor?
- The reception staff in student services?
- The student?
- The student’s parents?
- Teachers on the student’s course?
- Faculty Admin staff?
We have started to consider the importance of allowing the student some control of how widely the information may be spread. In the USA they talk about “Helicopter Parenting” (Google it) – and this is increasingly happening here: as parents pay a larger and larger part of the cost of the education they expect to know more about what is going on (perhaps in the same way that a sponsor expects information on progress). At the moment if parent rings and asks me if their offspring has been seen recently or what marks they are getting I am required to say “no comment”. Perhaps the Dashboard would enable the student to specify that I could answer their parents on agreed topics?
Allow me to introduce myself. I am the director of teh Student Dashboard project, and I am the Director of Education resposible for TEL at Southampton. More about me at http://users.ecs.soton.ac.uk/hcd
I have been on sabbatical leave since February, and so somewhat disconnected from the early stages of this project. In fact more disconnected than was intended as when JISC changed their mail provider our spam filter was so certain that mail coming from JISC was spam that it2 marked it for immediate server side deletion (not even sending it to us marked as SPAM). Consequently we missed some important emails about this project and the first cluster meeting.
The second cluster meeting is on 13th October, and I have resolved to turn up mob handed to apologise for our absence at the first meeting.
However, while I have been away the project has been progressing better than I knew.
The Purpose of our project is to make the information about students that we have available though many systems in the university available to the right time in the right format for the right people.
We have collected a detailed list of the sources of information. The various CRM systems and student record systems are the most obvious, but there are some less obvious systems, such as the assignment hand-in system (so we can know whether the student is up to date on their courseworks) and email archives (so that we can revisit previous (official) conversations we have had with students.
An important issue at the start of this project was the choice of CRM. The university currently uses Oracle CRM in student services, and then a range of third party products and home grown products for recruitment, alumni contact and for faculty/departmental information. The preferred choice of nearly all the key players was to move the whole university over to Micrososft CRM which would interface best with Sharepoint which is also being rolled out across the University. However, in view of the current financial situation it was decided that this option was too expensive and disruptive. Instead it has been decided to stick with the Oracle CRM for Student Services, the existing Alumni package will continue for the moment. Banner CRM will be introduced and used for a standard university recruiting system. (Banner also provide our SRS), taking away a chunk or responsibility from the Faculties.
This means that there will continue to be a gap. All the other information that Faculties collect about their students will probably continue to fall into home grown systems and be difficult to access. Having said that, there has been a major push in the last year to centralise the collection and curation of information. The sort of information that is currently getting lost is that collected by personal tutors, senior tutors and other faculty pastoral staff, and programme directors.
This project will provide a vehicle for introducing discussion about this information and hopefully help individuals and faculties to understand the benefits of putting the data somewhere that it can be used by others.
To conclude, the Student Dashboard project is underway and up to date on all its deliverables except the open reporting (blogging). We now intend to rectify this and make sure that we share the understandings that are emerging.
The srtand of our blog specifically for the Student Dashboard project is
I imagine you’re wondering where we’ve got to with the Student Dashboard, aren’t you? In my plan of action last blog, I mentioned the stakeholder analysis we are performing, which is an initial part of the agile co-design process we are following.
Our first step was to identify the stakeholders of the Student Dashboard. Any job role in the university that interacts directly with students, or inputs or processes data about students were considered. The result was as follows:
- Academic Tutors
- Central Student Services
- Faculty Student Services
- Senior Tutors
- Module Leaders
- Alumni Office
Next, we set about interviewing these stakeholders, with the aim of determining who they are and the nature of their interactions with students. We also asked them what student information they draw on, and whether lack of access to any data is a hindrance to providing the best possible student experience.
The discussions with stakeholders will enable us construct personas and scenarios, which are an integral part of the agile co-design process and derived from human-computer interaction design theory. These personas and scenarios will be validated by the stakeholders in the next stage of the process.
Through the analysis of these interviews and the data identified by the stakeholders, we have constructed a table of the data required in the Student Dashboard, ordered by how many stakeholders require it. This has enabled us to shortlist the data that is important to the most people, and begin the process of negotiating access to the sources of these data.
Over the last couple of weeks the OneShare team has been thinking some more about the scholarly process. We began by brainstorming about potential end game scenarios for d-Roc. If we lived in a world where everyone made research objects of all of their research what would we be able to do with all the tastey distributed linked data. What we concluded was a variety searching and recommendation services. None of these really jumped out as the sort of ideas which were going to put a ding in the universe. Nevertheless what we did keep doing is making blind suggestions about what we could do with all the online artifacts themselves. Currently there is very little engagement with the existing research on the web. People download and read the paper write their own paper and upload it and thats all we see. However we all know there is more to the process than that…
In universities across the world people are talking about research. Whether that be in meetings, over coffee, while co-authoring it is definitely happening but we rarely see it online. Peer review is one of the biggest platforms for academic discussion but it is barely has a web presence at all. People discuss many things online and the mailing lists, wikis, forums and twitter feeds are bursting with discussion of a vast variety of subjects but research tend not to be one of them. There isn’t even really a good platform for doing it.
The white board quickly ballooned to include a cloud of web tools which would enable research discussion to come to the web.A sort of stack overflow for research, Peer pigeon, and having documents which are web native not locked in a PDF. I’ve concluded that the reason research seems so irrelevant and meaningless to me (and probably many people less directly engaged with it) is that the process still feels largely like an out of bounds transmission. To find out what a researcher thinks of something I have to leave the web…
All this brings me round to thinking of a presentation of Les Carr’s which, I read a few years ago but have never seen, called “Why the Web Never Took Off“. It talks about the tiny percentages of academics with there own web presence and why this might be (go read). The same sort of arguments are used for why academics don’t want to put their research in open access repositories – the famous “I dont have time”. Which I am sure is the reason academics down have a stack overflow equivalent – there would be no time. The problem is a lack of Digital Research Literacy. Academics can not see why they should engage with web because they dont really understand how they fit into it. They can not see the potential value it brings and don’t know where they would go to have a discussion about research on the web. This is a problem which I think is growing larger everyday. More research is done never engaging with the web reading masses and research is gradually becoming less and less relevant to the point of extinction. It’s ok though because we do not have time to worry about it…