How to Explain Service Design to People Who Do Not Get It
Every service designer has had the conversation. Someone asks what you do, you give the answer you have given a hundred times, and you watch it fail to land. The polite version ends with a nod. The honest version ends with a question about whether that is not just what the product manager already does. The problem is usually not the listener, and it is usually not the discipline.
Why the usual definitions fail
The standard definitions are built out of abstractions stacked on other abstractions. Designing end-to-end experiences across touchpoints and channels. Orchestrating the frontstage and backstage of value delivery. Aligning organisational capability with user need. Each phrase is defensible and each one requires the listener to already understand the field in order to decode it.
There is a second problem, and it does more damage. Most definitions describe territory rather than a problem. When a definition mentions the whole journey, the whole organisation, or every channel, an operations director hears a claim over things they are currently accountable for. That is a reasonable thing to hear, because that is what the sentence says. The response is not confusion. It is caution.
A definition tells someone what you call yourself. It does not tell them which of their problems you make smaller. Most people are not withholding agreement because they lack a term. They are waiting to hear what changes if you are in the room.
How would you say it to the person in front of you
The explanation should start from what the listener is already accountable for, and use the vocabulary they already trust. This is not dumbing anything down. It is describing the same work from the angle where it is visible to them.
To an engineer
Engineers usually understand this faster than anyone else, because the concept already exists in their world under different names. Systems rarely fail inside a well-tested component. They fail at the interface, in the retry logic, in the state that was assumed and not passed.
Something like: "Most outages are not inside a service, they are in the contract between two services. I look at the same class of failure, except the failing interface is between two teams, or between a team and a person, and there is no error log for it."
To an operations lead
Operations leads live with the consequences of poor service design daily, under names like avoidable contact, rework and escalation. They do not need persuading that the process is broken. They need someone whose job it is to find out why.
Something like: "I want to understand why people contact us a second and third time about the same thing. If I can show you the three points in the process where that gets created, you can decide whether any of them are worth changing."
To a finance director
Finance conversations go wrong when they become bids for discovery on principle. They go better when the subject is the cost of failure that already exists, and the risk of paying to reproduce it in new technology.
Something like: "Before we spend the money on the new portal, it is worth knowing which parts of the current process generate the contact we are paying to handle. If we do not, we will build a faster version of the same problem and the call volume will not move."
To a policy owner
Policy owners care whether intent survives contact with delivery. That is a genuine service design question, and it is rarely framed to them as one.
Something like: "The policy says people should receive a decision they can understand and act on. I would like to look at what actually reaches them, in the letter and on the phone, and where the intent gets lost between the rule and the wording."
What persuades when vocabulary does not
Evidence moves these conversations and terminology does not. The useful evidence is almost always already inside the organisation, unglamorous and unloved: contact centre reason codes, complaint themes, drop-off points, the number of cases that come back, the notes staff write to each other in the case management system because the fields do not fit reality.
The strongest single piece of evidence tends to be a person's own account of the process, played in the room. A short recording of someone describing what happened to them, or a verbatim quotation from a staff member explaining the workaround they built to keep things moving, does more than any framing slide. It converts an abstract claim about joins and handovers into a specific thing that happened to a specific person, which is much harder to file under interesting.
Two cautions matter here. Do not present anecdote as measurement, and do not claim causation you have not established. Say what you observed, say how many cases you looked at and how they were chosen, and be honest that the pattern may not hold at scale. Overclaiming buys one meeting and costs the next three. Ben Reason, Lavrans Løvlie and Melvin Brand Flu's Service Design for Business is written for exactly this audience, and it is often a more effective thing to hand a sceptical executive than any explanation of the discipline.
Why showing one real service beats defining the discipline
The single most reliable move is to stop explaining and start showing. Take a real service the people in the room are responsible for, map it as it actually runs, and put it on the wall: every step, every channel, every handover, every wait, with the person's experience along the top and the internal reality underneath.
What happens next is consistent enough to plan for. Someone points at a section and says that is not how it works any more. Someone else says they had no idea the letter went out at that point. Two people discover they own adjacent steps and have never spoken. The map stops being a designer's artefact and becomes the first shared picture of the service anyone in that organisation has seen, and the conversation shifts from what service design is to what should happen about the thing on the wall.
That shift is the whole point. Nobody adopts a discipline because it was well defined. They adopt it because a way of working produced something they could not get otherwise. A blueprint or a journey map of a real service does that in one meeting, and it also quietly demonstrates the method, which means you never have to describe it.
When it sounds like you are asking for a bigger remit
There is a specific failure worth naming, because it is easy to walk into. You describe a problem that spans four teams, and what the room hears is a proposal that those four teams should now report through you, or at least defer to you. Defensiveness follows, and it is not irrational.
The way out is to be explicit that you are describing a problem, not requesting authority, and then to prove it by giving the work away. Name the owner of each part as the person who should decide what to do about it. Ask for access and time rather than governance. Something like: "I am not proposing to take anything over. I want to describe what happens across the whole thing accurately, so the people who own each part can see the bits they cannot see today. What you do with your part stays yours."
It also helps to arrive with a scoped, finite ask instead of an open commitment. Two weeks looking at one service, one specific question, a named output and a date. Service-dominant logic makes the theoretical case here, in that value is co-created among many actors rather than produced by one and consumed by another, so no single team can own the outcome alone. In the room, the practical version of that argument is more persuasive: nobody has to lose territory for the whole to get better, and somebody does have to look at the whole.
What to practise
The skill worth building is not a better definition. It is the habit of translating one piece of work into the terms of whoever is listening, and then letting evidence carry the rest.
Three things are worth practising until they are automatic. Lead with the problem the listener already has, in their language. Bring one real, verifiable piece of evidence rather than a framing. Ask for something small, specific and finite, with a clear owner for whatever it finds.
If the work is any good, the argument for it eventually stops being an argument. People start describing it themselves, usually in words you would not have chosen, which is the most reliable sign that it landed.