What Does a Service Designer Actually Do All Day?
Service design is easier to describe in outcomes than in hours. Job adverts talk about end-to-end experiences and cross-functional collaboration, which is accurate and tells you almost nothing about what a Tuesday looks like. Anyone considering the field deserves a straighter answer than a process diagram. The honest version is less tidy, and more interesting, than the diagram suggests.
Why the tidy version of the process misleads
The version most people meet first is a diagram. Discovery, definition, ideation, prototyping and implementation, arranged left to right with confident arrows between them. It is a reasonable teaching device. It describes the logical order in which evidence ought to influence decisions, and it gives a newcomer something to hold on to while everything else is unfamiliar.
The diagram is not wrong. It is a description of the work written after the work has finished.
There is a second reason the diagram misleads. It shows a project with a beginning and an end, whereas most services already exist and are already being used by people who cannot pause while somebody redesigns them. The work is nearly always renovation carried out with the building occupied, which constrains what can be changed and when, and adds a whole category of effort that no process model shows.
A real week rarely respects those boundaries. A designer may be running interviews about one part of a service on Monday, presenting a blueprint of a different part on Wednesday, and spending Thursday in a governance meeting about whether a third part can legally change at all. Discovery does not stop when definition begins, because the first rough prototype usually exposes something the research missed. Phases overlap, double back, and occasionally collapse into each other when a deadline arrives earlier than expected.
What the evidence gathering actually consists of
Research is the part outsiders picture most clearly and still tend to get wrong. It is not a sequence of illuminating conversations with users. It is recruitment, scheduling, consent, rescheduling when someone does not turn up, and then a great deal of careful listening to people describe something they have stopped noticing because they do it every day. A good share of it is conducted with staff rather than customers, because the people delivering a service usually know precisely where it breaks and have stopped being asked.
The rest is desk work. Complaint logs, call centre notes, previous research reports nobody acted on, policy documents, the wording of standard letters, the analytics showing where people abandon a form. Organisations tend to hold most of the evidence about their own failures already. It sits in different systems, owned by different teams, in formats nobody has ever put side by side.
A large part of discovery is assembly rather than revelation.
That changes how the job feels. Some weeks the most valuable thing produced is a single document that puts four existing pieces of knowledge in the same place, with the contradictions left visible rather than smoothed away.
Where the hours really go
If a week were tracked honestly, the largest category would almost certainly be conversations. Not workshops, which are rare and highly visible, but ordinary meetings and short calls with people who each own one piece of the service. This is the part of the job that surprises newcomers most, and the part that is hardest to make look impressive in a portfolio.
A service is rarely owned by anyone in particular. It is assembled from decisions made in different places, by people who may never have met, working to targets that do not point in the same direction. A single apparently small change might require talking to:
the team that owns the digital front end
the operations manager whose staff absorb the consequences
the policy or legal lead who decides what may be asked and recorded
the finance owner whose budget any change would come from
the partner organisation delivering one step on a system nobody in the room controls
Those conversations do two things at once. They surface constraints that no amount of user research would ever reveal, and they build the working relationships that decide whether anything designed will survive contact with delivery. Much of what looks like negotiation is really translation, taking a problem described in one team's language and restating it in terms another team can act on.
Most of the design happens in the space between those owners.
The mapping, the synthesis and the writing
Mapping is the visible craft. Journey maps, service blueprints separating what the customer sees from the work happening behind it, ecosystem maps showing which organisations shape a service without ever appearing in it. The artefacts take longer than people expect: coding transcripts, clustering findings, arguing with yourself about what to leave out so the map makes a point rather than merely recording everything anyone said.
The map is not the point. Nothing changes because a wall has a good diagram on it. What changes is that a group of people who each held one fragment of the picture can now see the whole of it at once, including the parts that reflect badly on them.
Then there is writing, which occupies far more of the week than the discipline's visual reputation suggests. Research summaries, option papers, problem statements precise enough that a steering group could reasonably decide against them, briefing notes for an executive with eleven minutes. Sometimes the writing is the service itself: the letter, the error message, the question on the form.
Facilitation sits on top of all of it. A workshop that runs well is mostly preparation, deciding who genuinely needs to be in the room, what decision it has to produce, and what to do when the most senior person disagrees in the first ten minutes.
The unglamorous operational detail
A large share of the job is detail that would never appear in a case study. Referral routing. Opening hours. What happens to a case when a required document is missing. Who is permitted to authorise a refund. Which system holds the record when two systems disagree. This is where a person's actual experience is decided, long after the concept work is finished.
Take someone trying to move an appointment. From outside the change looks trivial. Inside, it may touch a booking rule, a permissions setting, a call script, a policy line about how much notice is required, and a reporting field somebody uses for capacity planning. Tracing those dependencies, and establishing which of them can be changed and by whom, can occupy weeks of otherwise unremarkable work.
This is also why the discipline resists being reduced to an interface. Vargo and Lusch describe value in service-dominant logic as something co-created through interaction among actors rather than delivered by a firm to a passive customer. Read practically, that means the experience is produced jointly by the person, the staff, the rules and the systems. Change one of those and leave the others alone, and generally very little moves.
What the work actually amounts to
Underneath the research, the mapping and the meetings, a great deal of the job is helping an organisation see itself clearly. Large organisations are usually structured so that no single person has a reason to look at the whole of a service, and the incentives reward improving one part of it in isolation. A service designer spends a surprising proportion of the week assembling a view nobody was responsible for holding, then keeping that view in the room while decisions get made.
It is worth being honest that this makes progress hard to see day by day. Weeks pass in which nothing visible ships, and the only measurable output is that four teams now agree on what the problem is, which is not nothing but is difficult to celebrate. The compensation is that when something does change, it tends to stay changed, because the people who have to operate it were part of deciding it.
That is quieter work than the discipline's imagery suggests, and slower. It also explains why the role is so often described in terms of collaboration and influence rather than deliverables. If the ambition is to spend most days making things, this may disappoint. If the ambition is to change how something genuinely works for the people relying on it, the ordinary weeks are where that happens.