The micro view is close-up: one user, one touchpoint, one moment of friction or delight. The macro view is structural: the teams, technology, policy and governance that produce every touchpoint at scale. Neither view is complete on its own. A user journey map shows what someone experiences; it rarely shows why the experience is shaped that way. A systems or organisational chart shows how work is structured; it rarely shows what that structure feels like to the person using the service. Effective transformation leadership means treating these as two lenses on the same service, not two separate jobs.
Decisions weaken quickly when only one lens is used. Attention fixed on individual touchpoints can fix a symptom while leaving its cause untouched, moving the same problem to a different part of the service (Meadows, 2009). Attention fixed only on the strategic picture risks the opposite failure: a plan that reads well on a slide but ignores the lived reality it will land on. Government’s own guidance for public services makes this explicit, requiring teams to “solve a whole problem for users” rather than a fragment of it, precisely because partial views of a service produce solutions that only partially work (GOV.UK, 2019). Deming’s long-standing observation that a bad system will beat a good person every time makes the same point from the opposite direction: blaming a frontline touchpoint for a failure that is actually structural leaves the structure untouched and the failure likely to recur (The W. Edwards Deming Institute, n.d.).
Every service touchpoint sits inside a web of interdependencies: the people who deliver it, the process steps before and after it, the technology it runs on, the policy that constrains it and the organisational structure that owns each part. Organisations behave as systems of interconnected parts held together by feedback: pull on one part, and the effect travels, often to somewhere the original decision-maker cannot see (Meadows, 2009). A transformation leader who understands only the touchpoint being redesigned, without asking who else depends on the process, system or policy behind it, is working with an incomplete map.
This is why local improvements can create system-wide challenges. Improving one part of a system in isolation, its local optimum, does not guarantee the system as a whole performs better; effort can simply shift a constraint, a queue or a cost to wherever the improvement was not looking (Goldratt and Cox, 2004). A faster step for one team can overload the team next in line. A simpler form for users can quietly remove data that another department relies on. None of this is visible from inside the improvement itself; it only becomes visible when someone is deliberately holding the wider system in view.
None of this means user experience should be sacrificed for organisational convenience. The task is to hold user outcomes and organisational priorities together rather than trading one for the other, using each touchpoint decision to test whether it still serves the transformation’s wider goals, and using each strategic decision to test whether it still serves the person at the other end of the service. Alan Mulally’s weekly Business Plan Review at Ford is a well-documented example of a process deliberately built to do both: reviewing every element of performance in close detail while treating the meeting as “both a strategic plan and a relentless implementation plan”, so that the operational detail and the strategic picture were never allowed to separate into two conversations (McKinsey & Company, 2013).
Action Point
Take a transformation opportunity you are currently exploring. Produce two one-page views: a touchpoint map showing the user’s experience, and a system map showing the people, process, technology, policy and structure it depends on. Identify one dependency you had not previously considered, and note who else should see this before the change goes live.