We recently had the first LAMP community advisory and planning (CAP) group meeting.
The meeting was roughly divided into two parts: The first covered many of the agenda items you’d expect to see on a project group meeting, such as: Discussion and agreement of the groups terms of reference, review of workpackages and so on.
The second part was focussed on presenting the group with the initial use-cases and design sketches that the project team had developed. The idea was to present this initial work as a way to stimulate ideas and new use-cases as well as sense-check the focus of the project so far.
The discussions were also framed by a few assumptions: That the designs are simply sketches, not wireframes; an assumption that the types of data implied by the use-cases would be available and useable, and; all feedback was welcome.
The discussions were rich and varied, and provided plenty for the project to take-away and think about. Listed below are some of the discussion themes and issues raised:
There was a significant amount of discussion around the need for flexibility when it comes to the data and the ‘views’ on that data.
Data might be fed in from various and disparate sources, including UCAS, NSS, KIS and even employment data once students have left the university. There was a sense that LAMP could serve a number of interesting new use-cases.
In addition to this variety of external sources, there was also a feeling that the service should enable local configuration. This would allow local, closed data sets to be fed into the institutional view.
This ability to tailor the data is also reflected in the need for tailored views on that data. The audiences and use-cases for the data are multiple, so it makes sense to provide flexible views and outputs. These may be reports for directors to make business cases and strategic decisions to daily service reports or occasional flags (like a fuel gauge on a car dashboard).
Connected to the flexibility of the system configuration is the consideration of who will be the primary audience(s) for the service.
It quickly became clear that an analytics service like LAMP would potentially have multiple audiences, from librarians to library directors to external users as well. The LAMP data may well be surfaced in existing systems across the campus, with entirely new users interacting with its data.
Ultimately, the project needs to understand who is this decision making tool for? This audience may expand and morph as the project develops, but it needs to ensure it doesn’t fail its primary audience(s) by trying to serve the needs of everyone.
A few times the issue of intuitive interfaces and visualisations bubbled-up during various conversations. There seemed to be two particular issues that emerged:
An intuitive view over the data – so you may not be interacting directly with the data itself but with visualisations of that data. This does however bring up interesting ideas of data and the UI, etc.
The possibility that the visualisations and the tools used to interact with the data should already be doing some of the interpretive work (or at least displaying it in such a way as to make analysis and interpretation easier).
This is potentially a very rich area, and one where a clear understanding of what users might want to do will be critical.
An interesting point was raised about the importance of ensuring context is captured and preserved within the service. While this is a relatively simple piece of functionality: You can imagine a notes field or similar, the implications are interesting.
Ensuring the context for certain data points would ensure that any future analysis is able to take into account extraordinary events or circumstances that would affect the interpretation of data. Such events might be a fire or building closure, which in the short term would be accounted for in any analysis, but over the long term might be forgotten.
In discussing the use-cases the potential for the service to support benchmarking was something that interested the group. In particular, benchmarking that extended beyond the boundaries of the UK to international institutions.
Increasingly, UK academic institutions are judging their performance in an international or global context, not just a national one.
There was also an interesting discussion about the possibility of ‘internal benchmarking’: comparing the performance of departments and subjects within the local institution.
This first meeting of the community group was very rich, and resulted in a lot of ideas and potential ways forward. So, given the limits of resource and time here are a few of the next steps the project will take:
Continue to develop the prototype as a way to get solid feedback on the potential use-cases and functionality. The community meeting made it clear that it would be useful to have something people can actually interact with, test our assumptions and refine the kinds of functionality users require. data is the key component in this next step – both the existing data sets we might be able to use and the institutional data that will help drive some of the impact type use-cases.
Sketch out a development roadmap. This seems to be a way to both manage expectations (i.e., we’re not going to be able to deliver everything by December), and a way for us to prioritise the design as we progress.
User testing – make sure we are able to call upon small samples of potential users to test and refine the prototypes inbetween the CAP group meetings. These will likely be small, guerilla in nature, and aimed at ensuring a very iterative approach to the development.
Our next meeting is planned for July, so we’ll have plenty to do between now and then!
The full minutes from the meeting can be found here: LAMP CAP meeting minutes 16 April 2013.