Traditional lists often reduce service design to five appealing words: human-centered, co-created, sequenced, evidenced, and holistic. They are useful as an introduction, but insufficient to guide decisions in real services. Empathy, collaboration, and experimentation also exist in many other approaches; they are not the field’s trademark.
What distinguishes a mature practice is its ability to work with systems, operations, conflict, evidence, and implementation. These principles guide the perspective presented on this site.
1. A service is a system, not a collection of touchpoints
A screen, a counter, and a conversation with support do not exist in isolation. Every visible encounter depends on invisible decisions: rules, systems, capacity, suppliers, targets, data, and handoffs between teams.
A systems principle asks how these parts influence one another. Improving one part can make the whole worse. Accelerating sales without increasing delivery capacity creates delays; reducing average handling time can increase repeat contacts and rework; automating a simple step can transfer complexity to someone least able to absorb it.
2. The symptom rarely appears where the cause is
Queues appear at reception, complaints arrive through an app, and delays become visible at the last step. It is tempting to fix exactly that point. In services, however, the source may lie much earlier: in an approval rule, a sales promise, an incentive, missing information, or a dependency between teams.
Designing the service means investigating patterns, delays, and causal relationships before blaming the visible part. A poor system turns capable people into permanent firefighters.
3. Users and operators are part of the same problem
There is no good customer experience that can be sustained indefinitely by a poor working experience. Inadequate tools, ambiguous roles, little autonomy, fragile handoffs, and cognitive overload inevitably cross the counter.
Being human-centered therefore does not mean choosing one “central user” and ignoring everyone else. It means understanding how customers, employees, partners, and other parties create, receive, block, and negotiate value within the system.
4. Co-creation does not make conflicting interests disappear
Services bring together actors with legitimate and often incompatible needs. Customers want speed; operations need to control risk; suppliers seek margins; frontline teams need autonomy; the organization imposes cost limits.
A collaborative workshop can make these tensions visible, but it cannot resolve them by magic. Design requires making trade-offs explicit, recognizing power relationships, and accepting that decisions will have different winners, losers, and consequences. Complexity is not simply having many parts; it also means having to choose among interests that cannot all be satisfied at once.
5. Evidence comes before the artifact
Journey maps, blueprints, and personas are not outcomes in themselves. They are provisional representations that should make evidence open to discussion and support decisions. When filled in only with the team’s opinions, they may look professional and still say nothing about the real service.
A map is a hypothesis. Its value depends on the quality of the data behind it, the question it helps answer, and the decision it can move. Without evidence, a precise diagram is just an illustration of internal beliefs.
6. Design creates conditions; it does not promise control
Services are performances distributed over time. People improvise, exceptions arise, and contexts change. No project can fully control what will happen in every encounter.
Serious work defines conditions that make good outcomes more likely: clear roles, available information, coherent rules, adequate capacity, recovery mechanisms, and responsible freedom at the frontline. The goal is not to write an impossible script, but to build a system that can work amid real variability.
7. Implementation and learning are part of design
A service does not improve when a blueprint is approved. It improves when a new configuration can operate, be observed, and evolve. Practice must therefore include service prototypes, pilots, meaningful metrics, monitoring of exceptions, and review of initial assumptions.
If a proposal never reaches operations, the project produced an intention, not a transformation. And if the solution requires permanent heroics to work, it has only moved the problem elsewhere.
A simple way to apply these principles
Before choosing a tool, ask:
- which decision needs to be made;
- what evidence is still missing;
- which parts of the system produce the current outcome;
- who gains, who loses, and who absorbs the effort;
- what needs to change in operations;
- how the change will be tested under real conditions.
For the definition behind these principles, read What Is Service Design. Then continue to the methods library.