Service Design for Grannies
This week my Mum decided to try and understand how I make my living — the post below is how I explained it to her. Well, pretty much.
“What exactly is service design?”
Service design can be a noun (the object of design) or a verb (the process of designing). Every service has a “design”, no matter how good or bad that design might be. But not every service has been “designed”.
Design, as a verb, implies a deliberateness that is often lacking. Most service design is unintentional because the people doing it don’t realise they are designing services. They design elements of a service in isolation from the wider service experience. When this happens the results are, at best, mixed.
For me, service design is the practice of designing services with intent. And in the public sector, concerned with policy outcomes, good service design is that which delivers policy intent.
Service design is the design of services to deliver intended outcomes.
Notice that nowhere in here do I equate design with making things look good. That’s because good design is about effectiveness. We only worry about a design’s attractiveness when we know it is affecting our outcomes.
“Okay — but I still can’t imagine what this looks like. What do you actually do?”
There is no one way of practicing service design, no single method or process applied by all. But most of the approaches can be boiled down to some version of this:
- Research: primary and secondary research to understand the problem, desired outcomes, user needs and context, and constraints
- Prototyping: concept generation, prototyping and testing
- Iteration: iterative, hypothesis-driven service development (n.b. not only digital development).
I do these things. I design ways of doing these things. I build and lead teams of people doing these things.
Service design involves the research, prototyping and iterative development of services.
“But why do people bother? Don’t they know what they want? Why wouldn’t they go straight to building it?”
Let’s try and explain this with an analogy.
A real estate developer doesn’t build houses himself, he hires a builder to do it for him. But he doesn’t ask the builder to make his vision a reality: he hires an architect.
The architect drafts sketches and schematics to explore myriad design possibilities. He creates models that test how well different designs align with the developer’s vision for the building. He considers how best to use space and light to create the desired experience for those inside. He considers how project constraints — building regulations, the laws of physics — will affect his design. Then he translates his design into a detailed building plan for the builder to work from.
The builder makes that blueprint a reality, on time, on budget and to spec. Construction problems often don’t appear until ground is broken, so the architect will work with the builder on design refinements and adjustments throughout the build.
And sure, some building projects are so basic that having an architect would be overkill — a garden wall, a shed. Or you may have a cookie-cutter project — where the builder needs little design input because he’s built to this plan a dozen times before and has an established design pattern.
But generally — and especially if you’re trying to do something new, innovative or different from before — you’ll want an architect.
A service designer is the architect.
The service designer will sketch many, often unimagined, service propositions to meet user needs and deliver desired outcomes. She experiments with combinations of people, process, communications and technology to see what will best deliver desirable, efficient and effective services.
And, as no design survives first contact with real users, the service designer will support continuous improvement by observing users’ experience of the service and making adjusting and refining the design in response.
When you want something complex, innovative or different, you need someone who will explore, design and iterate rather than someone who goes straight to the build.