Community Payback Visibility App – Designing the Service
If you had asked me a year ago what service design was, I would have struggled to guess the answer. In my ignorance, I think I would have been quite sceptical. Probably, arrogantly, I would have said it must be one of those ooshy-mooshy things people talk about in continental cafes.
But I would have been wrong... Well, possibly not about the the cafes, but certainly about the ooshy-mooshiness.
As we pitched our app idea at the GeoVation Challenge, we were introduced to the concept of service design and began to understand the benefits it would bring.
Wikipedia describes service design as “the activity of planning and organizing (sic) people, infrastructure, communication and material components of a service in order to improve its quality and the interaction between service provider and customers.”
In other words, if you are planning to provide a service for people, make it relevant, make it useful, make it responsive, make it friendly. And don’t think you can do all that without speaking to anyone. You don’t know it all and you will not have thought of everything. Test it, prototype it, talk to users, listen carefully to the feedback. All the time, you will be informing the design.
The principles sound obvious when you think about it, but it’s incredibly easy to find examples of appallingly badly designed services – where the very people expected to use the service are tearing their hair out at how difficult it is to use, how user-unfriendly it is.
I’m sure you can think of at least one occasion when you have had bad service from a company or a public authority. Perhaps the interminable loop of automated phone options that never seems to put you in touch with the people you need to talk to. Maybe the ludicrously inept and inattentive bar person who keeps you waiting for hours to buy a round of drinks.
We don't want our app to redirect you to an auto-moron. Nor do we want it to keep you waiting for hours while it sees to something else. We want our app to be used. We don’t expect people to get beside themselves with excitement, but we don’t want them to be tearing their hair out when they try and use it.
We want the experience to be positive, so people will use it again and will recommend it to friends.
We want our staff to appreciate the design of the internal response bit. We think the actual staff who will be expected to respond to nominations are the best people to design how it works. We don’t pretend to have all the answers. We don’t want to go away, hide and design the backend then dump it on the staff and say, “There you go!” Inevitably, we will have ignored some crucial element that they will point out, by which time it will be too late.
But at the same time, we are not service design experts. We are a data analyst, an IT architect and an operational manager in Community Payback.
|David and Sean|
So we asked Nonon to help. Sean and David, two service design experts, came on board and agreed to work with us and help us… well, design the service!
After an initial meeting with the project team, Sean and David put together the prototyping bootcamp – a day spent with the actual staff who will be expected to respond to the nominations – working through the principles of service design and how to prototype a service.
We focussed on those elements of the project that we (as a group) thought were the most important to test. We began to put together a blueprint, mapping the user journey, identifying the touchpoints, highlighting the priority areas for prototyping.
When you get service design wrong, or don’t pay attention to it, you take a massive chance.
You may think you know how everyone would want to engage.
How can you be certain that the customer experience will be positive? They may well get annoyed.
And if they do, you will probably pay the price in terms of continued use or recommendations to friends.
So don't be a sceptic or a know-all. Be smart and involve the users - front and back - in the design, right from the very beginning. Make use of the experts. Or just ignore service design... at your peril!