The Question Behind the Framework
If services are fundamentally promise-based systems - where capabilities promise performance and resources promise affordance - what happens when promises break? And more troublingly: what happens when broken promises go unseen?
This question has been circling my work on the design system. We build components, document patterns, establish guidelines; but the harder problem is not "how do we build good interfaces?" but "how do we know when things go wrong?". In a system spanning dozens of trusts, hundreds of users, and thousands of daily interactions, failures can disappear into aggregate statistics or vanish entirely. This post explores the failure modes of service systems through the lens of promise theory, and asks whether our framework design choices make failures visible or invisible, accountable or diffuse.
The Invisibility of Service Failure
Lou Downe captures the problem starkly in Good Services (Downe, 2020): service failure is "hidden in wrongly worded questions, broken links and poorly trained staff; in emails not sent, phone lines that have been closed". We have, she argues, "a collective blindness for services. They are the gaps between things, and so not only do we fail to see them, but we fail to recognise when they fail". A waiting list validation that does not happen is not logged anywhere; a patient whose breach was not flagged because the algorithm had the wrong threshold does not generate an error message. The service worked perfectly - it just did not serve the patient.
Services are, by nature, distributed across time, space, channels, and actors. When something goes wrong, the failure often occurs in the interstices - in handoffs, in timing mismatches, in signals that never arrive. Polaine, Løvlie and Reason (2013) make a similar point: "the answer to why so many services are poorly designed lies in the lack of attention paid to the invisible elements of time and context". What is invisible cannot be fixed; and what is invisible often cannot be attributed - which creates perverse incentives for keeping failures hidden.
Promise Theory and Fault Detection
Mark Burgess's promise theory (Burgess, 2020) offers a rigorous framework for thinking about failure. Promises make failures detectable because they create explicit expectations against which outcomes can be measured. Without promises, we have only outcomes - and no way to know whether those outcomes represent success or failure. As Burgess puts it, "promises act as calibrators for fault detection. In the traditional black box model, all of these modes of failure are random faults, and the cause is hidden. The existence of a documented promise enables any agent, in principle, to probe and detect when this is happening".
If the system promises "we will flag all patients approaching 52-week breach", then we can detect when that promise is not kept. But if the system only promises "we will display patient data", the breach-flagging failure is invisible - it is not a promise violation, just an absence. Burgess identifies several ways promises can fail: the promise may not be kept at all; it may be kept too late, violating the timing expectation; it may be kept but not observable, so the outcome happens but the requester cannot see it; or promise assessment may be blocked, where the receiver refuses to allow auditing of whether the promise was kept. The last two are particularly insidious - a promise might be technically kept while functionally failing because the signals that would confirm it are missing or suppressed.
Signal Failure Modes
Drawing on the analysis of demand and supply signals developed in the previous post, we can identify failure modes at each stage of the signal flow.
Demand signals can fail in several ways: the signal may not be sent at all, because the user cannot express their need - a button that does not respond, a form that will not submit. The signal may not be received, because the system fails to detect the demand - a workflow action that fails silently. It may be misrouted, so that the demand goes to the wrong handler and the wrong record is updated. Or it may be misinterpreted, so that the demand is understood incorrectly - a date format confusion, a field-mapping error.
Transition failures occur when the system receives the demand but does not act on it correctly. The action may not be taken despite the signal; the wrong action may be taken, applying force in the wrong direction; the action may be partial, leaving the state inconsistently updated; or the action may appear to succeed while silently failing - a database write that does not complete.
Supply signal failures are where accountability most commonly breaks down. The system may offer no acknowledgement at all, so the user cannot confirm their request was received. It may offer a false acknowledgement - "saved" appears on screen but the data is lost. The response may arrive too late to be useful - a batch job that completes overnight after the user has moved on. Or the action may complete but the user is never informed - a patient transferred but the referring trust not notified. Each missing supply signal represents an accountability gap: a point where failure becomes invisible.
Programme Orientations
The motivation literature (Elliot, 2013; Heckhausen and Heckhausen, 2010) distinguishes between approach motivation - directing behaviour toward positive or rewarding stimuli - and avoidance motivation - directing behaviour away from negative or punishing stimuli. This distinction maps onto how service systems are oriented, and the orientation shapes which failures become visible.
Building on Mazzucato's work on mission-oriented innovation and Hill's (2012) strategic design vocabulary, we can identify four orientations that programmes tend toward. These function as contextual conditions that shape how interventions fire - and in the case of accountability, they determine which failures become visible and which remain hidden.
Risk-oriented programmes focus on minimising downside: avoiding failure, managing liability, tracking error rates and compliance scores. As Bason (2018) notes, "the expectation of public organisations is often that they will avoid any kind of error. This often translates almost directly into an internal culture of risk aversion". This orientation makes visible failures highly visible - every error is tracked, investigated, attributed - but creates systematic blindness to invisible failures: the service not offered, the need not recognised, the demand never expressed because the system did not make it possible.
Efficiency-oriented programmes focus on maximising throughput and reducing cost per transaction - the New Public Management inheritance. Arundel and Bloch (2014) describe how "the traditional governance model was criticized for a command-and-control management style", leading to reforms focused on efficiency metrics. The problem is that efficiency metrics optimise supply without understanding demand; a service that processes validations faster is not necessarily better if it is validating the wrong patients, or if patients who most need validation cannot access it.
Provider-oriented programmes focus on managing the supply of performance and affordance, starting from what the system can provide rather than what users need. Pope (2024) observes that "the aim of most digital programmes is the status quo, delivered more cheaply. The digitization of public services has, by and large, happened on the terms of existing institutions". This orientation makes the system accountable to itself - did we deliver what we said we would deliver? - rather than accountable to users.
Demand-oriented programmes focus on understanding and responding to user needs - the service design promise. Pope notes that "GOV.UK had been designed around the concept of 'user needs'". But demand orientation requires capability to sense demand, and this is where the political economy becomes critical.
The Political Economy of Accountability
Mazzucato and Collington (2023) identify a structural problem: "the more governments and businesses outsource, the less they know how to do, causing organizations to become hollowed out, stuck in time and unable to learn". Contracting out can "directly erode existing in-house knowledge and institutional memory: the less an organization does internally, the less able it is to do in the future". This creates a vicious cycle for demand-oriented programmes.
When capability sits outside the organisation, so does the ability to understand and respond to demand. This connects to what Dan Hill (2012) calls the "dark matter" of strategic design: "organisational culture, policy environments, market mechanisms, legislation, finance models and other incentive structures... that shape what gets designed and how". Finance models that require cost recovery push toward efficiency metrics; audit regimes push toward risk orientation; procurement rules push toward provider orientation; short political cycles discourage long-term demand sensing; and professional cultures within technical disciplines may resist user research. As Hill puts it, "you can't design a transformative service without redesigning the organisation". The accountability structures of a service are downstream of organisational design, which is downstream of policy and governance choices.
Mazzucato and Collington (2023) reframe the fundamental question: "rebuilding capabilities in public sector organizations must begin with recognizing government as a value creator in the economy - rather than a mere fixer of market failures". A value-creating orientation asks what outcomes would create value for users, what capabilities are needed to deliver those outcomes, and what promises can be made and kept. A value-extracting orientation - or even a passive "service delivery" orientation - asks only what services are currently provided, how they can be provided more cheaply, and how to avoid blame when things go wrong. The accountability structures follow from these questions: value creation requires understanding demand, which requires investment in sensing capability; value extraction only requires managing supply, which can be outsourced.
The Abductive Gap
Service design at its best is abductive: it generates novel possibilities by creatively reframing problems. User research is not just about understanding existing needs but about recognising latent needs, unarticulated desires, and possibilities that users themselves have not imagined. But abductive capability requires time to explore before committing to solutions, safety to be wrong and to prototype and fail, proximity to users and their contexts, and skills to interpret, synthesise, and create. Risk-oriented and efficiency-oriented programmes systematically erode these conditions: time is compressed by delivery pressure, safety is eliminated by blame culture, proximity is lost to outsourcing, and capability is hollowed out.
The result is programmes that can only deductively apply existing solutions to problems framed in terms the system already understands. Demand that does not fit existing categories becomes invisible. Innovation becomes impossible.
Accountability, Visibility, and the Promise Gap
Who is responsible when a promise breaks? Burgess (2020) notes that "the assessment that a promise has not been kept is a subjective one: different agents observing the system might assess it differently". In service systems with multiple handoffs, accountability can diffuse to the point of disappearance. Causal chains become obscure when multiple agents are involved; temporal distance means failures surface long after the causing event, breaking the causal link; counterfactual invisibility means we cannot see the service that should have been offered but was not; and aggregation hides individual failures within statistics.
Systems can also be designed - intentionally or otherwise - to evade accountability. If users do not receive acknowledgement, they cannot prove they made a request. Without reference numbers, individual cases cannot be tracked. Without timestamps, delays cannot be measured. Without audit trails, reconstructing what happened is impossible. Without escalation paths, failures cannot surface. Burgess hints at the strategic dimension: "the receiver can disrupt a promise-binding by refusal to cooperate, as well as refuse to allow an assessor or auditor of the promise access to the outcome". Actors can strategically suppress visibility to avoid accountability, whether through complexity that makes failures hard to trace, metric gaming that measures only what makes the system look good, blame-shifting that attributes failures to users, channel fragmentation that splits journeys so no one sees the whole, or temporal diffusion that introduces delays so cause and effect disconnect.
The promise visibility matrix clarifies the goal of accountable design: to move everything into the visible row. Visible success is celebrated and reinforced; visible failure is painful but learnable - it can be fixed. Invisible success is a missed opportunity, since we do not know what worked. Hidden failure is the danger zone - harm occurs without correction.
Design for Accountability
Safety engineering offers relevant concepts here. Poel and Royakkers (2011) describe "inherently safe design" as "an approach to safe design that avoids hazards instead of coping with them", and advocate for "multiple independent safety barriers" that "can be designed to operate independently so that if the first fails the others still work". Adapting this for service design suggests two principles.
The first is inherently accountable design, which avoids accountability gaps rather than trying to assign blame after the fact: every demand signal generates an acknowledgement, every promise is documented and observable, every transition leaves an auditable trace, and every failure triggers an alert. The second is layered accountability barriers, where multiple mechanisms catch failures that slip through earlier layers: real-time confirmation gives immediate feedback, case tracking provides persistent reference through the journey, progress visibility lets users check status at any point, escalation triggers fire automatic alerts when service levels breach, complaint loops offer easy paths to report problems, and audit reconstruction enables tracing what happened after the fact.
The signals that enable accountability map directly onto the signal model developed in the previous post. A demand signal proves the user made a request; an acknowledgement proves the system received it; a progress signal proves action is underway; a completion signal proves the outcome was delivered; an error signal proves failure was detected; and an escalation signal proves failure was surfaced. A service that lacks any of these signals has a corresponding accountability gap.
Implications for the Design System
If we take accountability seriously, the design system framework needs to address several dimensions. Every capability should articulate what it promises - what will be delivered, under what conditions, in what timeframe, and how completion will be signalled. For every demand signal there should be corresponding supply signals: acknowledgement, progress for long-running operations, and completion or failure notification.
Each element in the framework should have associated failure modes, asking how a signifier can fail to prompt action, how a demand signal can fail to reach the system, how a transition can fail to complete, and how a supply signal can fail to reach the user. And for each promise in the system, the framework should identify who is responsible for keeping it, how keeping or breaking is detected, who is notified on breach, and what remediation is available.
The deeper question is political, not technical. As Pope (2024) observes, "public services only get better because of feedback loops; they require an element of co-production". But feedback loops make failures visible, and visible failures create political problems. The framework can create the possibility of accountability, but whether accountability is enacted depends on power, incentives, and political will. Promise theory suggests explicit promises, observable outcomes, and independent assessment; the cost is complexity and friction, but the benefit is that broken promises become visible, attributable, and - potentially - fixable. The framework's role is to make the choice legible: here is what accountability would require, here is what we are currently doing, here is the gap. What happens next is politics.
References
Arundel, A. and Bloch, C. (2014). Surveys of innovation in the public sector. In Creating a Better Understanding of Public Sector Innovation. Danish Centre for Studies in Research and Research Policy.
Bason, C. (2018). Leading Public Sector Innovation: Co-creating for a Better Society. Policy Press.
Burgess, M. (2020). A Treatise on Systems, Volume 2: Intentional Systems Theory. ChiTek-i.
Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.
Elliot, A. J. (2013). Approach and avoidance motivation. In A. J. Elliot (ed.), Handbook of Approach and Avoidance Motivation. Psychology Press.
Heckhausen, J. and Heckhausen, H. (2010). Motivation and Action. Cambridge University Press.
Hill, D. (2012). Dark Matter and Trojan Horses: A Strategic Design Vocabulary. Strelka Press.
Mazzucato, M. and Collington, R. (2023). The Big Con: How the Consulting Industry Weakens Our Businesses, Infantilizes Our Governments, and Warps Our Economies. Allen Lane.
Poel, I. van de and Royakkers, L. (2011). Ethics, Technology, and Engineering: An Introduction. Wiley-Blackwell.
Polaine, A., Løvlie, L. and Reason, B. (2013). Service Design: From Insight to Implementation. Rosenfeld Media.
Pope, R. (2024). Platformland: An Anatomy of Next-Generation Public Services. London Publishing Partnership.