Mid-November saw another Service Design event led by Lauren Currie of Snook, this time at Aston University in Birmingham.
Service Design is a methodology for creating services that are more appropriate for the people that will actually be using them; this in contrast to traditional design methodologies which involve a designer gathering requirements from some potential users, then go away and plan the service. Service Design focuses the designer on thinking about exactly who the users will be and how they might interact with the service. JISC have asked the Student Relationship Management projects to use Service Design.
This is interesting as we are keen proponents of the agile co-design methodology for designing software and it seems to have a lot of similarities, for example, using personas and scenarios to explore the range of users and uses of the system, and using storyboarding to explore what the experience will be like. At this most recent event, we were working on blueprinting, using some paper forms such as this one here:
In this detailed blueprinting, we were looking at how the various touchpoints occur in making users aware of the service, joining it, using it, “growing” it and leaving it. It was here that I started getting a little confused. It occured to me that the Southampton Student Dashboard is a tool for staff to detect when a student is struggling, and direct them towards the support services that already exist within the University. It is a thing that will eventually make a student aware of other services. In fact, is it even a service? I think it might be a product, which is why trying to apply Service Design is confusing me a little.
This got me thinking as to where software fits into the product-service spectrum. Which is it? A product is something tangible, so when you buy it, you get one to use. A service is a set of actions that the provider performs on your behalf. Software has been sold as a product for most of my life (since people have had home microcomputers), on disks in a box from a shop. I guess when the only computer you could have was a mainframe rented from and maintained by the likes of IBM, the software on it was provided as a service. And of course with the boom of cloud hosting on the Internet, there has been a resurgence of Software as a Service (SaaS).
Having talked myself in a circle, it turns out that perhaps software can be either a product or a service. In fact, as I see it the software itself is a product, but the provision of the software can be a service. As such, it means there are two separate things to design, hence the variations on the methodology and my confusion.
The Service Design workshops will certainly be helpful, because eventually we will be running the Student Dashboard as a service (it’ll be a website staff can visit, rather than a piece of software they acquire and install), and we will have to consider how to make people aware of it, and how they will join and leave the service (or whether it will just perpetual). At the moment though, we also need to consider the design of the software product.
Thanks for letting me clarify my understanding by thinking about that out loud!