A system worth explaining
From a good question to a useful system.
A fictional service-design workflow: define the problem, make the handoffs visible, and keep the evidence close to the decision.
Four steps. One clear handoff.
Discover
Collect the constraints and observe the actual work.
Define
Agree on one decision and the evidence it needs.
Develop
Prototype the smallest useful system.
Deliver
Review the handoff and document what changed.
How the pieces fit.
01The experience
The interface people see and the actions they can take.
02The coordination
The rules that connect a request to the next responsible person.
03The service
The capabilities and source data behind each action.
04The foundation
The operational constraints and safeguards that keep the system dependable.
04
Purpose and boundaries
Make the decision clearer, not the system bigger.
A useful process has a defined outcome and a visible boundary. This illustrative service workflow starts with the decision a team needs to make.
- 01
In scope
A shared request intake, a clear decision owner and a traceable handoff between discovery and delivery.
Owner / Service lead - 02
Out of scope
Replacing every existing tool, automating judgement or claiming service improvements before evidence exists.
Guardrail / Programme sponsor
Source / Fictional FIELDWORK process brief; illustrative operating guidance
05
Inputs that make the work possible
Start with evidence the next person can use.
A short, reliable evidence pack beats a large collection without provenance. Each input carries context, a source and an owner.
- 01
Observed work
Describe a recent real request, the route it followed and where the next action became unclear. Separate observations from interpretations.
Contributor / Research lead - 02
Operating constraints
Record access limits, required approvals, dependencies and known capacity constraints. Mark assumptions that remain unverified.
Contributor / Operations - 03
Decision brief
Name the decision, intended user, deadline and evidence that would change the current view. Keep the scope small enough to test.
Contributor / Decision owner
Source / Fictional FIELDWORK process brief; illustrative operating guidance
06
Responsibility at every handoff
One accountable person at every transition.
Responsibility describes the next observable action. It is not a list of everyone who might have an opinion.
- 01
Discovery to definition
The research lead packages observations and open questions. The service lead confirms which decision the evidence will support.
Accountable / Service lead - 02
Definition to development
The decision owner agrees on scope and success evidence. The maker turns that agreement into a small, reviewable prototype.
Accountable / Product lead - 03
Development to delivery
The delivery owner checks the artifact, records remaining risks and names the person responsible for support after handoff.
Accountable / Delivery lead
Source / Fictional FIELDWORK process brief; illustrative operating guidance
07
Evidence before the next stage
Use evidence to open the next door.
Each checkpoint asks one distinct question. A stage is ready when its receiver can act, not when a meeting has taken place.
- 01
Problem understood
A concrete request and its context are documented. The team can distinguish the user need from a proposed solution.
Gate / Discovery review - 02
Decision framed
Scope, constraints and the evidence required for a choice are explicit. Unresolved assumptions are named.
Gate / Scope agreement - 03
System tested
The smallest useful prototype is tried against the actual handoff. Observed failures and changes are recorded.
Gate / Working review - 04
Handoff accepted
The receiver can locate the artifact, explain its limits and identify the next owner without another briefing.
Gate / Acceptance check
Source / Fictional FIELDWORK process brief; illustrative operating guidance
08
When the normal path breaks
Design the recovery path before you need it.
An exception should lead to a clear action without hiding the original problem. Keep the evidence and the decision trail intact.
- 01
Evidence is missing
Pause the affected decision, record what is unknown and assign the smallest investigation that can resolve it. Do not convert a guess into a requirement.
Escalation / Decision owner - 02
A handoff is rejected
Name the missing acceptance condition, return the artifact to its current owner and agree on a focused revision. Keep unrelated work moving.
Escalation / Delivery lead
Source / Fictional FIELDWORK process brief; illustrative operating guidance
09
What the team actually produces
Leave behind things people can work with.
Every stage creates an artifact with a specific purpose. The examples here are deliberately lightweight and editable.
- 01
Observation note
A dated account of what happened, who observed it, the source material and the interpretation still to be tested.
Used by / Service lead - 02
Decision record
The options considered, the constraint that mattered, the current choice and the evidence that would justify revisiting it.
Used by / Whole team - 03
Handoff packet
The working artifact, instructions to inspect it, known limits and a named receiving owner.
Used by / Delivery owner - 04
Review log
The original expectation, the observed result, the change made and the next follow-up date.
Used by / Operations
Source / Fictional FIELDWORK process brief; illustrative operating guidance
10
A usable handoff contract
The handoff is a contract for the next action.
Agree on what the receiving person needs to begin. A link alone is not enough if the context and limits stay in someone’s head.
- 01
Artifact and location
Provide the exact working file or repository location and the version under review. Avoid ambiguous links to a changing folder.
Required / Producing owner - 02
Acceptance evidence
Record which conditions were checked, how they were checked and what remains outside the tested scope.
Required / Reviewer - 03
Operating responsibility
Name the receiving owner, first action, support route and condition for escalating back to the producing team.
Required / Receiving owner
Source / Fictional FIELDWORK process brief; illustrative operating guidance
11
Introduce the system deliberately
Introduce the system in a small, honest sequence.
Use an explicit trial instead of assuming adoption. Each step should produce evidence that helps decide whether to continue.
- 01
Choose one route
Pick a recurring request with a visible handoff and willing participants. Document its current behaviour.
Stage / Baseline - 02
Run the new path
Use the proposed artifacts and ownership rules on a small number of real requests. Keep a record of friction.
Stage / Trial - 03
Review the gaps
Compare observations with the intended handoff. Fix unclear responsibilities before expanding the workflow.
Stage / Revision - 04
Expand deliberately
Extend only after the receiving team can use the process. Assign maintenance and a review date.
Stage / Adoption
Source / Fictional FIELDWORK process brief; illustrative operating guidance
12
Keep the feedback loop open
A process improves when its assumptions stay visible.
Keep the feedback loop small enough to maintain. The aim is a better next decision, not a report that no one revisits.
- 01
What changed?
Record one observable change in the handoff, including the source and the reporting window.
Review / Delivery owner - 02
What still fails?
Collect exceptions and workarounds. Look for repeated constraints rather than blaming individual behaviour.
Review / Operations - 03
What happens next?
Choose one bounded revision, assign an owner and state when the team will inspect the result.
Review / Service lead
Source / Fictional FIELDWORK process brief; illustrative operating guidance