SERVICE DESIGN · PUBLIC SECTOR · COMPLEX TRANSFORMATION

Moving Beyond the Empty Folder: Connected Service Design in Complex Public-Sector Transformation

A Service Design pack has no value simply because the folder exists. It becomes valuable when journeys, blueprints, ecosystems, processes, research, architecture and business language connect to form one coherent view of how a service works, where it is failing and what must change.

1. The Hook: The Empty Folder Philosophy

One of the easiest mistakes to make in a large transformation programme is to confuse the existence of Service Design artefacts with the existence of Service Design value.

A folder can contain a user journey, a service blueprint, an ecosystem map and a process catalogue and still tell the organisation very little.

The folder is only the container. The value sits in the connections between what is inside it.

In a large public-sector transformation programme, that distinction matters. The work is rarely about introducing one new digital interface or changing a single operational process.

The broader challenge is to connect user experience, operational activity, information, decision-making and organisational outcomes so that the service can respond more effectively.

That kind of transformation cannot be explained by one diagram. It crosses external users, internal teams, information sources, operational decisions, digital services and wider organisational dependencies.

Service Design therefore needs to act as the connective tissue between those parts.

The mindset shift is important.

We are not producing artefacts simply because a delivery framework says we should have them. We are building a live model of the service that helps product, operations, research, technology and leadership make better decisions.

2. The Anatomy of Connected Artefacts

I think of the Service Design pack as a pipeline rather than a collection of files.

Each artefact should add another layer of understanding, but it should also be traceable backwards and forwards through the service.

The real value comes when somebody can move from the broad ecosystem view into the user experience, then into the operational detail and finally into the language and processes used across the organisation.

Participation diagrams and ecosystem maps

Participation diagrams and ecosystem maps provide the macro view. They show who contributes to the service, what information moves between participants, and which teams depend on the resulting outcomes.

In a complex transformation context, that means making visible the relationship between information sources, central operational capabilities and the services or teams that depend on their outputs.

The point is not simply to draw boxes and arrows.

The map should answer practical questions. Who owns the information? When is it needed? Who relies on it? What happens if it is incomplete? Which part of the service depends on the outcome? Where does human intervention still matter?

Once those questions are attached to the ecosystem, the map starts to reveal dependencies, failure points and opportunities for improvement.

It becomes something the programme can use to reason about the service rather than simply something it can display.

User journeys and service blueprints

The user journey moves the conversation from organisations and systems to human experience.

In a complex public service there can be several very different perspectives to understand.

External users may need to provide information or evidence, while internal operational users need to interpret information, make decisions and progress work.

Consider an external user submitting information or supporting evidence through a digital public service.

The front-stage experience may look relatively simple. Information is submitted, evidence is provided and the user expects the organisation to process it correctly.

Behind that interaction, however, the service may involve validation, routing, operational checks, decision support and human decision-making.

A service blueprint makes those invisible activities visible and connects what the user experiences to what the organisation must do behind the scenes.

This is why the blueprint matters.

It links something the user can see to the organisational activity needed to make that experience possible.

It gives the programme a shared place to discuss where user needs, operational activity, information and technology meet.

It also creates a shared design surface between Service Design and architecture.

Service Design should not recreate technical architecture, and architecture should not replace the service blueprint.

The two should connect at the level required to test feasibility. The blueprint describes what the service needs to do, while architecture establishes whether the supporting environment can enable it.

The process catalogue and taxonomy

Journeys and blueprints become much more powerful when they connect to a formal process catalogue.

Without that connection, teams can easily describe the same business activity using different words.

One team may describe an activity in terms of assessment. Another may call it triage. A specialist team may use terminology associated with its particular discipline. An operational team may describe the same activity in terms of work selection or progression.

All of those descriptions may refer to overlapping parts of the same underlying capability.

The process catalogue creates the formal anchor. The taxonomy creates the language.

Together, they allow Service Design to connect human experience with operational activity, business capability and technical implementation.

This becomes especially important when data and digital decision support introduce another layer of terminology.

Concepts such as recommendations, confidence, assurance and human intervention still need to map back to recognised business processes and outcomes.

The blueprint-to-taxonomy pipeline therefore creates traceability.

If a process appears in the blueprint, it should have a recognised place in the catalogue. If the catalogue changes, we should understand which journeys, services and users are affected.

3. The Power Triad: Cross-Functional Collaboration

Service Design cannot build this picture alone.

In a programme of significant complexity, designing in isolation almost guarantees that the artefacts will become detached from reality.

The Service Designer needs to work as part of a small but powerful collaborative group, supported by stakeholders and sponsors who hold the wider strategic context.

Each discipline brings a different part of the truth, and the quality of the service model depends on those perspectives being connected.

The Business Analyst may understand the rule.

The User Researcher may understand why the rule creates friction. The Solution Architect may understand why the current environment cannot support the desired interaction.

The Service Designer brings those perspectives together and makes the trade-offs visible.

That is where Service Design becomes strategic.

The value is not the diagram itself. The value is creating a shared understanding that allows the multidisciplinary team to make a better decision.

Business Analysts: turning the blueprint into operational detail

A blueprint may show that system-supported information is produced before an operational user reviews a piece of work.

That description is useful, but it is not enough for delivery. The BA helps unpack what must be true for that step to work.

What information is required? Which business rules apply? What exceptions exist? Which process owns the decision? What needs to be recorded?

That operational detail can then feed back into the blueprint so the service model becomes more accurate rather than remaining an idealised picture.

User Researchers: ensuring the service reflects reality

User journeys are dangerous when they describe what we think users do rather than what research shows they actually do.

Research with external users can reveal problems with evidence submission, comprehension, trust or accessibility.

Research with internal users can expose workarounds, hidden steps, duplication, judgement calls and points where digital support creates additional cognitive load rather than removing it.

Those findings should not sit in a separate research repository. They should change the journey, the blueprint and eventually the design of the service.

Solution Architects: connecting service intent to technical feasibility

Service Designers should be ambitious, but ambition has to connect to feasibility.

If the desired future service depends on timely information reaching an operational user, the supporting architecture needs to enable it.

If the service requires feedback between stages, the relevant systems and information flows need to support that safely and reliably.

If assurance or explanation is required at a decision point, the solution needs to provide the information necessary for appropriate human understanding and oversight.

Working with Solution Architects allows the team to identify those constraints early, when the service can still be shaped, rather than discovering them after the future-state design has already been treated as a commitment.

4. Smashing Silos: Portfolio Interdependencies

The final piece is often the hardest because it sits outside the immediate delivery team.

A transformation programme does not exist in isolation.

Adjacent teams may already be designing information services, operational capabilities, interfaces or processes that affect the same end-to-end user journey.

If those teams do not speak to one another, the organisation risks solving the same problem several times.

Even worse, each project can produce something that works perfectly inside its own boundary but creates friction at the boundary with another service.

This is why portfolio engagement is part of Service Design rather than an optional stakeholder activity.

Teams need to understand what adjacent work has already discovered, which artefacts already exist, where terminology differs and where planned changes may create dependencies across the wider service.

Earlier and more effective intervention depends on this connected view.

End-to-end improvement cannot be delivered by an isolated technology component because user interactions, operational decisions and downstream actions cross team and service boundaries.

Breaking down those silos is therefore not a cultural nice-to-have. It is a design requirement.

What a valuable Service Design pack should actually do

A strong Service Design pack should allow somebody new to the programme to understand the service without needing ten separate teams to explain it.

They should be able to follow the story from the ecosystem to the user journey, from the journey to the blueprint, from the blueprint to the processes, and from those processes to the organisational and technical capabilities that support them.

They should also be able to see where evidence came from, which teams own which activities, what remains uncertain and where a change in one part of the service will affect another.

In other words, the pack should help people understand relationships, not simply locate documents.

Conclusion

The phrase “empty folder” is useful because it reminds us that Service Design does not create value by producing documents.

The value comes from turning fragmented knowledge into a connected view of the service.

In complex public services, that means connecting users, operational colleagues, processes, information, architecture and outcomes into one coherent service story.

Participation diagrams tell us who is involved. Journeys tell us what people experience. Blueprints reveal the work behind that experience.

Process catalogues make the work explicit. Taxonomies give everyone a shared language. Research grounds the design in reality. Architecture tests whether the design can work.

None of those artefacts is enough by itself.

Their power comes from the connections between them, and those connections are built through collaboration between Service Design, Business Analysis, User Research, Solution Architecture, programme leadership and the wider portfolio.

If the ambition is to identify problems earlier and create a more joined-up operating model, then Service Design must also move upstream.

It needs to help shape the service before individual projects, processes and technologies harden into separate solutions.