Service Design Needs Knowledge Access

A service can look simple from the customer side and still depend on a long chain of people, tools, rooms, schedules, records, and small decisions behind the counter, where simplicity is usually being maintained through considerable effort.

Richard Buchanan’s definition begins there. The design of activities and organized services includes the older management concern for logistics: combining physical resources, instrumentalities, and human beings in efficient sequences and schedules to reach specified objectives. It has expanded into logical decision-making and strategic planning. The language is formal, but the work is recognizable. Someone has to decide which person acts first, what information they need, where a handoff occurs, what happens when the normal sequence fails, and how the service changes without making the people using it carry the confusion.

Design thinking is often discussed as if it arrives at the beginning of a project carrying sketches and a workshop. I find this account more useful because it places design inside the ongoing operation, where a service designer has to understand the physical, psychological, social, and cultural relationships among services, products, and the people affected by them. Look at the practical sequence, then ask what that sequence does to the person trying to complete a task.

Knowledge management becomes useful here because the relevant understanding is rarely held in one form. Explicit knowledge may exist in procedures, schedules, service maps, project records, and reports. Tacit knowledge is the knowledge people use without having fully written it down: the adjustment a staff member makes when a queue changes, the phrase that helps a client understand a choice, the timing that prevents an equipment problem from interrupting the next step. A service can be redesigned from documents alone and still fail because it did not reach the people who know where the document stops.

Take a familiar handoff. A client receives an initial explanation, submits information, waits while a team reviews it, and receives a decision or next appointment. The formal process might specify each stage cleanly. Staff may know that the handoff fails when a particular form uses terms clients do not recognize, when a message reaches the wrong person, or when the schedule leaves no time to explain an exception. Those observations are not incidental commentary. They are evidence about the service’s actual behavior.

The design task is to trace the resources, people, sequences, and schedules without turning them into a diagram that nobody can use. Which physical resources does the service require? Which tools carry information between people? Who has authority to make a decision? Which sequence is fixed, and which can change according to context? Where does a schedule improve clarity, and where does it produce an unnecessary wait? The answers give a service team something more specific than a general desire to improve experience.

Accessible knowledge makes that investigation faster and more honest. A project record can show what has already been tried. A repository can surface a comparable service decision. A frontline worker’s account can explain why a formally efficient route creates workarounds. An interview or observation can identify a need that was invisible in the original specification. The point is not to replace judgment with a larger collection. It is to keep the relevant record and the relevant experience within reach of the people doing the design.

When an improvement works, it can become a concrete service innovation that another team can adapt. Replication requires more than the final description. It requires enough context to understand the conditions under which the service changed: the people involved, the sequence altered, the resources available, and the tacit practice that made the new arrangement viable. Otherwise the improvement travels as a slogan and breaks when it reaches a different setting.

This is where knowledge management acts as a catalyst. It makes explicit and tacit knowledge accessible and discoverable, allowing a design team to recognize a relevant precedent, test it against local conditions, and learn from the result. The service still needs people to choose. Knowledge access does not design the sequence for them.

Before changing a service, ask whether the people responsible for it can see the records, routines, and lived adjustments already determining how it works. If they cannot, the design process has begun after essential information was left out, and the clean journey map will likely rediscover that information as a surprise somewhere behind the counter.