A presentation at Clearleft Mini-Conference in
September 2018 in
Brighton, UK by
What I talk about when I talk about service design
13 Sept 2018
Managing Director, Clearleft
The title of this talk, as some of you might know, is a homage to a book by Haruki Murakami called “What I talk about when I talk about running”...
"Pain is inevitable. Suffering is optional."
In Murakamiʼs lovely little book, he writes as much about the creative process and entering middle age as he does about running. But thereʼs one thing he says in relation to running marathons that really stands out to me: I know from experience that when you hit the wall at 21 miles, your legs hurt, a lot, but whether you sit down or carry on is entirely up to the runner. It got me thinking - maybe thereʼs an analogy hiding in there somewhere. not saying that being a service designer is necessarily painful or that one suffers when carrying out their work, but the job is certainly more of a marathon than a sprint. As I shall endeavour to illustrate over the next 20 minutes. Before I start, letʼs first ask ourselves:
Is UX design service design?
Is UX design service design?
It depends. Partly. It should be. It used to be.
the former Ux designer in me naturally wants to say It depends. Better answers are perhaps: Partly. It should be. It used to be.
Is UX design service design?
The man credited with the phrase ‘user experienceʼ is this man, Don Norman ... So UX design should be about designing "the way you experience the service." And by extension service design is about designing the service you experience. Arguably two ends of the same stick. Let me give you an example.
Like all councils across the country, Brighton & Hove City Council have an urgent need to reduce costs while still providing a good service to citizens. BHCC have embarked on a digital transformation programme to introduce cost savings and switch channels from more conventional, analogue means into a much improved digital experience for citizens and staff. Clearleft has been privileged to help them with some of that process. one area we were helping with was a vital council service which affects everyone in the city. Rubbish, recycling and street cleaning operated by a department called Cityclean. In order to keep the city safe and hygienic, Cityclean relies on citizens reporting issues such as graffiti, fly-tipping and broken glass. - we were asked to look at the report form because the feeling in the council was that it was difficult to use and was putting people off. - and they werenʼt wrong
i'm going pick out a few aspects of that form.
When youʼre faced with improving a form, there are two approaches you can take. 1. You can go through the form, group and lay out the inputs better, add in a bit of progressive disclosure, rewrite the labels, introduce some helpful microcopy, improve the interactions. All good stuff, second nature to a good product or UX designer. 2. Your other approach is to redesign the form. Properly. From the ground up. This is where your inner service designer starts to surface. What you need to do is understand exactly what information is really required and how that is acted upon. And you do that with the Question Protocol.
The question protocol
but the biggest effect you can have is to ask the right questions, and only the right questions. - The question protocol is rather like a structured version of the 5-whys, which youʼll be familiar with if youʼve ever had dealings with an inquisitive toddler. - The question protocol forces you — and your organisation — to ask yourselves why you are requesting a piece of information from a person. Getting to the bottom of why youʼre asking a question means determining precisely how you will be using the answer, if at all. - Every piece of information you ask for is another hurdle for your user to get over before they complete the process. - Sometimes, questions have been added to a form because somebody needed the data at some point in the past — it may no longer be relevant to gather that information. - In many situations, questions are asked because it might be ‘nice to knowʼ the answers, without a clear idea of how those answers will be interrogated or used. - There are other times when information is asked for that could have been inferred or more usefully gathered in another way or on a more appropriate occasion. -
The Question Protocol 1. Why do you need this information? 2. Who will use the information, and what
6. What happens if the information goes out of date?
decision will be made or action taken
7. Can a customer update their submitted
based on the information collected?
information? Should they be able to?
3. How will you validate the information that is submitted? 4. What happens if the submitted information is false or made up? 5. What’s the impact of the information not
8. Are you allowed (legally and ethically) to collect this information? 9. How is it shared? With whom? What are the privacy implications? 10. How securely does it need to be stored?
[go thru questions] Asking those questions should lead you to answering the ultimate one: “Is the question really necessary?” - Each piece of information you ask for has two costs: - firstly it is an impairment to accurate completion of the process; - secondly there is a time and money cost of collecting, storing and processing any additional information, and handling situations where the information is false or inconsistent.
in the long run following the question protocol can save money and improve conversions and process completion. BUT - Finding the right person to tell you whether they really need the answers to specific questions takes time and persistence - pain. - equally true whether you are an agency like Clearleft or working in-house. Arguably harder in house because as a 3rd party you have the advantage of bypassing politics What you need is a champion to alleviate the pain. One such person is with us now and he helped get Cityclean in a room to follow the question protocol with us. Also the street team felt they were being listening to properly and their concerns taken seriously some of their answers were pretty interesting
The new report form is quick and easy to use. It asks citizens to provide only the information actually used, and takes advantage of modern technology including the cameras and location services in smart phones. - and we could have left it there, new form designed. job done, but thatʼs not our style, and itʼs not the style of a service designer - all weʼve done is redesign the form by which residents report problems in the street that need cleaning up. thatʼs far from the whole story - we wanted to see for ourselves what happened next to the reports. and this is where it got really interesting.
This is the point where you can hit the wall. We knew in essence what we needed to do, but we were going to need permission and help. Permission because we were on a clientʼs budget (same would apply if you were an internal team). Help because, while we could design some solutions, we wouldnʼt be in a position to build them. And this is where we needed our champion again. He could see the value of the insight weʼd uncovered and could see how there could be a way to help the streets team be more efficient and provide a better service - two things on his remit.
So we were given the go-ahead. And we set to work with the council web team to design the solution.
A simple system to make it easy and rewarding for citizens to report problems, and for Cityclean to efficiently respond to and action those reports, and feed back to the reporter. 1. report 2. dashboard - Urgent jobs are more easily identified and assigned
Digital service design
Digital service design
That was what i'd describe as digital service design the service as a whole was cleaning the streets based on residentsʼ reports. we designed the bits that joined those things up. the digital aspects of the service. weʼre not going to tell city clean how to clean the streets, what to prioritise and how to route their trucks. but we did more than redesign the form, there was a whole journey there that, in close partnership with the council, we improved [click] when we look at ux design and service design they are part of the same picture but all good design is about designing for the context You can imagine how our story would have ended at redesigning just the form. But the improvements made were done at relatively low cost, thanks to the right set-up in the council.
Digital service design Digital service design
That was what i'd describe as digital service design the service as a whole was cleaning the streets based on residentsʼ reports. we designed the bits that joined those things up. the digital aspects of the service. weʼre not going to tell city clean how to clean the streets, what to prioritise and how to route their trucks. but we did more than redesign the form, there was a whole journey there that, in close partnership with the council, we improved [click] when we look at ux design and service design they are part of the same picture but all good design is about designing for the context You can imagine how our story could have ended at redesigning just the form. But the opportunity for wider change was seized, and the improvements made at relatively low cost thanks to the right set-up in the council.
As design capability improves in an organisation, it takes on new forms.
Centralised Defined Emergent No design
The council is somewhere here: centralised / distributed but even if you're down here (defined, where design is starting to be a thing in the organisation), a successful product can show senior decision makers the kind of impact that can be had when digital service design starts to happen. One exemplar service can sow the seeds of change. Success breeds success. People want a piece of it. Start to move you up the slope. And the further you are up the slope, the less there is of pain and suffering...
...And the more there is of win And thatʼs what I talk about when I talk about service design. Thank you for listening.
View What I talk about when I talk about service design on Notist.
Introduction to getting service design done by the back door. One of eight 20 minute talks given during a private afternoon conference for Clearleft's clients.