A service rarely operates in isolation. Teams, technologies, policies and other services are woven together, so a change made to solve one problem can travel through the wider system in ways that are not obvious from a single map (Design Council, n.d.). A new digital front door might ease pressure on one channel while quietly overloading a back-office team that was never part of the original design conversation. Service Designers who trace these connections before implementing a change are far better placed to anticipate where the pressure will actually land.
People do not always behave as a process, policy or service design intends. Staff find workarounds when a new system slows them down, and users take the path that feels sensible to them rather than the one a journey map assumes. Much of the demand placed on public services is ‘failure demand’, work created because something was not done, or not done well, the first time, and this only becomes visible once real behaviour is studied rather than the process on paper (Seddon, 2008). Understanding how people actually respond, not just how a design intends them to respond, is central to predicting whether a change will succeed.
Every action in a service creates a reaction, and that reaction shapes what happens next. Reinforcing loops amplify small changes into large ones, while balancing loops pull a system back towards stability, and most service performance depends on which of these loops dominates over time (Meadows, 2008). A target introduced to speed up one stage of a service can trigger a reinforcing loop of its own, for example, encouraging staff to close cases quickly rather than well, which then feeds fresh demand back into the system it was meant to relieve.
Many of the behaviours a service exhibits are not designed into any single part of it; they emerge from the interaction between people, teams, technology and process. This is a complex domain, where cause and effect can only be understood in hindsight and where leaders learn most by running small, safe-to-fail experiments and sensing what patterns appear (Snowden and Boone, 2007). Service transformation initiatives that assume a complex service will behave like a complicated one, with a single right answer, are prone to being surprised by outcomes no individual part of the system intended.
Improvements often solve one problem while creating another. Unanticipated consequences are outcomes that follow from purposive action but were never part of its intention, and they arise even from carefully reasoned decisions (Merton, 1936). In service design, optimising one part of a journey, such as a faster call-handling target, can quietly damage another, such as first-time resolution, because local optimisation does not automatically improve the wider system it sits within.
No service map can capture every variable, and dynamic systems thinking accepts that as a starting point rather than a flaw. Effective system leaders build the habit of asking ‘and then what?’ after every proposed change, stay curious about how a system might respond, and treat each transformation as a step to learn from rather than a fixed, final answer (Patterson, 2026). For Service Designers, that means building in review points, watching for early signals and being ready to adapt a design once it meets the reality of the live system.
Action Point
Take one change you are considering for a service. Beyond the immediate map, list who else it touches, how people might realistically respond, what reaction it could trigger and what it might quietly worsen elsewhere. Agree one thing you will monitor after launch, and a point at which you will review and adapt the change.