The 6 principles of service design

Search for service design principles and you will be handed six of them, then ten, then fifteen, depending on which page you happen to open. The lists are not all trying to do the same job, and that is most of why the subject feels unsettled.

The set that describes how the work gets done has six: human-centered, collaborative, iterative, sequential, real, and holistic. They come from This is Service Design Doing, by Marc Stickdorn, Adam Lawrence, Markus Hormess and Jakob Schneider.

What a service design principle actually is

A service design principle is a check you can run on a decision while the work is happening, rather than a value a team agrees on before it starts. That distinction decides whether the list is worth anything. Six words on a slide commit nobody to anything. The same six words, turned into questions asked at the points where a project makes choices, change who gets interviewed and what a second round of research is allowed to overturn.

All six describe how the work of designing a service gets done. They say nothing about what the finished service should feel like to use, which is a separate question with its own separate lists. Keeping those two apart resolves most of the confusion about the number.

The 6 principles of service design

All six come from the same source and are meant to be applied together rather than picked from. Below the list, each one gets the treatment that matters more than the definition: what it looks like when a project honors it, and what it looks like when a project has only agreed to it.

Each of those is easy to nod along to and much harder to demonstrate. What follows is what each one means in practice and, more usefully, the observable difference between a project honoring it and a project claiming it.

Human-centered

The word covers the customer, the frontline staff delivering the service, the back office team whose queue the request lands in, and anyone downstream who inherits the consequences of a design decision. It replaced "user-centered" deliberately, because "user" kept the research pointed at one group.

The check is a research plan. Pull up who was actually interviewed. If the notes are all from customers and none from the people operating the service, what you have is user-centered work under a newer name. In a hospital intake redesign, the admissions clerks usually hold the most valuable evidence in the building: the workarounds they have built to keep a broken form moving at eight in the morning. Those workarounds rarely make it into a document, because nobody with a research budget was assigned to ask about them.

Collaborative

Stakeholders from different backgrounds and functions stay engaged in the work rather than being shown it at milestones. What matters is who holds a share of the decisions, and attendance figures tell you nothing about that.

Workshops are where this gets muddled. A workshop is an event, and it is entirely possible to run four of them without a single decision changing hands. The check is to name the last decision that changed because of someone outside the design team, and to be specific about what changed and who moved it. If nobody can name one, what took place was consultation. Consultation is a perfectly reasonable thing to do, as long as it is not being counted as something else.

Iterative

Service design is exploratory, adaptive and experimental, moving toward implementation through repeated cycles rather than one pass with a launch at the end. Because the principle describes the shape of the work rather than its content, it is the easiest of the six to claim and the easiest to test.

Something has to have changed. A second round that confirms the first round is a review, not an iteration. Look for a decision that was reversed, a concept dropped after testing, or a scope boundary that moved because of what came back from users. If the plan that finished the project is recognizably the plan that started it, the cycles were scheduled but never used.

Sequential

The service is visualized and orchestrated as a sequence of interrelated actions, with rhythm and pace, rather than as a collection of touchpoints on a list. Sequence is what turns a set of interactions into something a person lived through in order.

Pace is part of the design. How long a step takes, and how long someone waits between two steps, are experienced as directly as the steps themselves. Three weeks between submitting an application and hearing a decision is not empty time from the applicant's side of the counter. Treat it as empty and you end up with a well-designed form attached to a silence nobody owns.

The check is whether the team can describe what happens between two steps as clearly as it can describe the steps. Journey maps and service blueprints exist largely to make that visible, which is why sequence problems tend to surface the moment somebody tries to draw the thing.

Real

The broadest of the six and the one most often read too narrowly. It covers three moves: research needs in reality, prototype in reality, and make intangible value tangible through physical or digital evidence.

The stock examples almost all sit in the third of those: the boarding pass that makes air travel concrete, the confirmation email that proves an appointment exists. Those examples are genuine. They are also the smallest part of what the principle asks for.

The check is where the evidence behind a design decision came from. Research conducted where the service is actually used will contradict research conducted in a meeting room. Finding out where the two disagree is the reason to leave the building. For a service with no physical component whatsoever, the principle still holds: a prototype that only ever ran on a designer's laptop has not been tested in reality.

Holistic

Consider the whole environment the service sits in, from the wider ecosystem down to the individual touchpoint, including the stretches of the experience that happen in channels the organization does not own or control. It is the widest of the six, and the one most often narrowed to fit the scope of whoever commissioned the work.

The check is about boundaries. Look at where a map or blueprint begins and ends, then ask what the person was doing in the half hour before it opens and the week after it closes. A mortgage journey that starts at "submits application" has skipped four weeks of comparing lenders, and a returns journey that finishes at "refund issued" has skipped the customer explaining to somebody at home why the money has not arrived.

Holistic also has the longest maintenance tail of the six. A whole-ecosystem view that has not been touched in eighteen months is no longer holistic about anything current, which puts the upkeep of journey maps and blueprints inside the principle rather than alongside it.

How to sort the other lists you will find

The ten- and fifteen-item lists in circulation are not competing versions of the six above. They mostly belong to a different family, and comparing across the two families is what makes the whole subject feel unsettled.

The sorting question takes one line: does this entry describe something a team did, or something a customer would notice? "Iterative" is answerable only by examining how the project ran. "A good service is easy to find" is answerable by a stranger with no knowledge of who built it. Neither statement contradicts the other, because they are not making claims about the same object.

Both families are legitimate and both are useful, and a team can score well on one while failing the other. A rigorously iterative, deeply collaborative project can still ship a service nobody can find. A service that scores beautifully against every outcome principle may have arrived there by luck, in which case nothing about the process will produce the same result twice.

The lists that give people the most trouble are the ones that mix the families without noticing, so an entry about prototyping sits three lines below an entry about accessibility. Sort the entries into their two families and the count stops mattering. You can then use each family for the job it was written to do.

Using the six as checks rather than as a slide

The six turn up on a slide in the kickoff deck of a great many projects. Everyone in the room agrees, because there is nothing in the list to argue with, and then the project runs for twelve weeks and makes several hundred decisions without any of the six being consulted once. The slide is doing no harm. It is just that a principle only does work at the moment a choice is being made, and nobody put it there.

The choices where these principles actually bite are specific, and there are fewer of them than the list length suggests.

Two of the six get dropped far more often than the others, and both go under deadline pressure. Iterative is the first, because the cheapest thing to cut when a date is fixed is the round that might invalidate work already done. Collaborative is the second, because pulling four functions into a scoping decision takes a fortnight that a project manager can reclaim by making the call alone. Both cuts are defensible in the moment and both are invisible afterwards, since the finished deliverable looks the same either way. The difference shows up later, when the thing built without those two rounds meets an operational reality nobody in the room had seen.

The artifacts you already produce carry the principles unevenly, which makes them a rough audit tool. Personas hold human-centered, and a persona set with no service-side actors in it is telling you something. Journey maps and service blueprints hold sequential and holistic, in the choice of where the sequence starts and how much of the off-stage experience made it in. Prototypes and research notes hold real, in the location field if nothing else. Collaborative and iterative leave no trace in any artifact, which is precisely why they are the two that go missing.

The six on that slide have been revised by their own authors before now, which makes the list the kind of document you are allowed to disagree with in writing.

Stakeholder alignment

Bring every function into the same view

Share maps, personas and portfolio items with the teams whose decisions shape the service.

Start free trial Explore journey management →

Frequently asked questions

Are there five or six principles of service design?

Six. Pages that list five are quoting an earlier version of the same set, from before its authors revised it and added iterative.

What is the difference between human-centered and user-centered?

Scope. User-centered points the work at the people who consume the service. Human-centered includes the staff who deliver it and anyone else affected by it, which changes who ends up on the research plan rather than just the wording of it.

Do the service design principles apply to digital-only services?

Yes, including "real", which is the one people assume does not apply. Its three parts are researching needs in real conditions, prototyping in real conditions, and making intangible value tangible. Only the third leans on physical artifacts, and a digital service still evidences itself through confirmations, receipts and status.

Who created the service design principles?

Marc Stickdorn, Adam Lawrence, Markus Hormess and Jakob Schneider, in This is Service Design Doing. Stickdorn later founded Smaply.

Are Lou Downe's 15 principles the same thing?

No, they belong to the other family. Downe's principles, written out of UK government service work, describe what a good service looks like from the outside, with entries like "a good service is easy to find". The six describe how the design work itself is done. Both are useful and they are not alternatives to each other.