This is the fifth post in The Contested Prototype series. The first post described the practical situation; the second developed a prototyping typology grounded in Floyd (1984) and the Scandinavian participatory design tradition; the third examined why organisations default to specification-led processes, drawing on institutional sociology and the agile literature. Each of those posts approaches the contested prototype from the perspective of the artefact itself - what kind of thing it is, what the organisation does to it, why.
This post offers a different analytical lens. Where the previous posts asked "what happens to the prototype?", this one asks "what is the designer accountable for - and what is the organisation accountable for?" The framework I find most useful for that question is borrowed from service design and, before that, from sociology: the distinction between frontstage and backstage, and the line of visibility that separates them.
Where the metaphor comes from
Erving Goffman's The Presentation of Self in Everyday Life (1959) introduced the dramaturgical metaphor that has since become foundational across sociology, organisational studies, and service design. Goffman observed that social interaction operates like a theatrical performance. There is a frontstage - the region where the performance is presented to an audience, where impressions are carefully managed - and a backstage - the region where the performance is prepared, where the props are assembled, where the actors can drop their public presentation and behave differently.
The key insight is not the existence of these two regions but the work required to maintain the boundary between them. Goffman describes elaborate strategies performers use to prevent audiences from seeing backstage activity - because the credibility of the frontstage performance depends on the audience not witnessing the mess, the disagreements, the improvisation that produced it.
Anyone who has worked in a large organisation will recognise this instantly.
From sociology to service design
Lynn Shostack (1977) was the first to adapt Goffman's framework for service management, introducing the concept of a line of visibility to distinguish what customers experience from what the organisation does behind the scenes. As Polaine, Løvlie, and Reason (2013) trace it, Shostack's line of visibility has since been augmented by additional demarcations - a line of external interaction (everything the customer does), a line of internal interaction (how backstage activities coordinate), and a line of implementation (supporting systems and infrastructure). Together, these form the architecture of a service blueprint.
Bitner, Ostrom, and Morgan (2008) formalised service blueprinting as a practical technique for service innovation, demonstrating how the blueprint's layered structure makes visible the relationship between what customers experience and the organisational machinery that produces that experience. Magyari and Secomandi (2024) describe the blueprint's distinctive contribution as lying in its separation of two domains of service production - the visible and the invisible - connected by the line of visibility.
Kalbach (2016) puts it plainly: the blueprint highlights the separation of frontstage interactions - what the individual experiences - from backstage processes - what the organisation does to enable that experience. The power of the blueprint is precisely this: it makes the dependency between frontstage quality and backstage capability structurally visible.
Why this matters for design governance
Here is where I want to take the metaphor beyond service blueprinting and into design governance - specifically, into the question of who is accountable for what when a designer works inside a large organisation with contested authority structures.
Consider a performance dashboard in the public sector. The frontstage is what users encounter: the information architecture, the visual hierarchy, the interaction patterns, the content, the accessibility compliance, the cognitive load, the narrative the dashboard tells (or fails to tell). These are design decisions - professional judgements grounded in user research, usability evidence, design principles, and established government digital service standards and the DDaT framework.
The backstage is everything that produces the frontstage: the data pipelines, the team structures, the governance processes, the sign-off chains, the stakeholder dynamics, the political context, the programme brief (clear or ambiguous), the product ownership (present or absent), the decision-making culture (evidence-based or committee-driven). The designer observes and works within the backstage. But the designer does not own it.
The line of visibility is the boundary between these two domains. And my proposition is this: the line of visibility is also an accountability boundary.
The accountability proposition
The designer is professionally accountable for frontstage quality. When a user encounters an interface that is confusing, inaccessible, incoherent, or fails to support their task - the designer should be able to explain the design rationale, point to the evidence base, and either defend the decision or acknowledge a gap that needs addressing. This accountability is grounded in professional training, in the competencies defined by the DDaT framework, in the public sector service standard, and in the design principles that govern the work.
The designer is not professionally accountable for backstage dysfunction. When the programme brief is strategically ambiguous to protect senior sponsors from accountability - that is an organisational design problem, not a UX problem. When product ownership is vacant or distributed across people who lack product management training - that is a governance problem. When stakeholders provide contradictory feedback without user evidence, or when design decisions are made by committee on the basis of seniority rather than evidence - those are backstage failures that contaminate the frontstage.
Hood (2011), in his analysis of blame avoidance in government, identifies three categories of strategy through which accountability is redistributed: presentational (spin and narrative control), agency (structural design of who is accountable - "delegation increases governments' opportunities to pursue blame avoidance while constraining others' ability to attribute blame to them"), and policy/operational (using quantitative measures and devolved responsibilities as a veneer of deniability). Middle managers, in Hood's account, are "the meat in the sandwich" - caught between credit-seeking leaders and blame-avoiding professionals. The backstage, in other words, is not neutral infrastructure; it is a terrain where accountability is actively managed, directed, and deflected.
Kate Tarling (2023) asks the diagnostic question directly: does the governance process put appropriate decision-making in the hands of the teams closest to the work? If not, the problem is structural, not individual. She describes how large organisations accumulate governance forums - design authorities, business design authorities, programme boards - that frequently separate decision-making from the people who hold the knowledge to make those decisions well.
This is not an argument for designers to wash their hands of organisational context. Designers who work in complex environments need to understand the backstage - to read the political dynamics, to recognise when backstage constraints will prevent frontstage quality, to document where the failures sit. The argument is about where accountability properly lies.
How backstage dysfunction contaminates the frontstage
The line of visibility is analytically clean. In practice, it leaks. Backstage dysfunction does not stay backstage - it manifests as frontstage failure, and the patterns through which this happens are worth naming because they recur so consistently.
The unclear brief produces the incoherent interface. Eisenberg (1984), in his seminal work on strategic ambiguity in organisational communication, argues that ambiguity is not accidental but functional - it "preserves privileged positions" and enables multiple interpretations so that the same brief can later be claimed as success or failure depending on who is evaluating it. When a programme operates under this kind of strategic ambiguity - where the stated aims are broad enough to accommodate multiple, incompatible interpretations - design teams inherit that ambiguity. They must make frontstage decisions (what to prioritise, what to show first, what hierarchy to impose) without a clear backstage signal about which theory of change the dashboard is meant to enact. The result is an interface that tries to serve everyone and satisfies no one. The frontstage failure is visible; the backstage cause is not.
The absent product owner produces scope drift. Without someone empowered to say "this is what we are building and why", every stakeholder with an opinion becomes a de facto product owner. The designer receives contradictory requirements from multiple directions, each backed by authority but none backed by user evidence. The frontstage accumulates features without coherence. The backstage vacancy is invisible to users; the frontstage confusion is not.
The committee produces the compromise. When design decisions require consensus from a group of stakeholders with different mental models, the result is typically a least-common-denominator solution - one that nobody objects to but nobody champions either. The frontstage reflects this: safe, generic, lacking the sharpness that comes from a clear point of view. Bason (2016) identifies this as one of the central challenges of introducing design into public policy - reaching a point where design is considered a legitimate way of conducting business, rather than something to be approved by everyone before it ships.
And then there is the intermediary who compensates for the design failure. In the programme I work on, entire data intermediary roles have emerged within public-sector organisations whose job is to translate dashboard data into executive-ready narratives. These intermediary roles are a classic service design indicator: they are compensating mechanisms that emerge when the frontstage fails to serve its intended users. The backstage has generated a workaround for its own frontstage inadequacy. Treating the intermediary as a "user" to design for is one response; recognising that the intermediary's existence signals a structural failure is another.
The designer's position
So what does this framing offer a designer working inside contested organisational environments?
It provides a vocabulary. Instead of saying "the process is broken" - which sounds like a complaint - the designer can say "backstage dysfunction in governance is contaminating the frontstage through [specific mechanism]". This is a diagnostic statement, not a grievance. It locates the problem structurally, names the transmission mechanism, and implies a structural remedy without placing the burden of that remedy on the designer.
It clarifies accountability. The designer can say: "I am accountable for the quality of what users experience. I can demonstrate the evidence base for my frontstage decisions. The backstage conditions that constrain those decisions - unclear briefs, absent product ownership, committee sign-off - are documented, and I can show how they affect the frontstage. But fixing those backstage conditions requires organisational authority I do not hold".
It creates a professional record. Documenting the relationship between backstage conditions and frontstage outcomes - through decision logs, design rationale documents, assumption registers, or indeed blog posts like this one - creates a trace. If the frontstage fails, the record shows where the constraints came from. This is not about blame; it is about learning. Tarling (2023) argues for bringing governance and accountability closer to the work, embedding it as a lifecycle. Documentation of backstage-frontstage contamination is one mechanism for doing that.
And it supports the case for structural change. If you can demonstrate repeatedly that the same backstage pattern (unclear brief, absent PO, committee sign-off) produces the same frontstage outcome (incoherent interface, scope drift, compromise solution), you are making an evidence-based case for organisational design change. Not as a complaint, but as a diagnosis. Merholz and Skinner's (2016) argument for a centralised partnership model, Cagan's (2018) argument for empowered product teams, Tarling's argument for governance that puts decision-making closest to the work - all of these are backstage interventions aimed at improving frontstage quality.
The line of visibility as a design governance tool
I want to propose that the line of visibility, adapted from service blueprinting, should be explicitly adopted as a design governance tool in programmes where authority is contested or unclear.
In practice, this means mapping the frontstage explicitly - what does the user encounter, what design decisions shape that encounter, what evidence supports those decisions, who holds design authority for each element? This is the designer's domain. It means mapping the backstage with equal care - what organisational processes, governance structures, team configurations, and decision-making cultures produce the frontstage, where the dependencies sit, where the failure points cluster. This is documented by the designer but owned by the organisation.
It means drawing the line of visibility and making the boundary explicit. When stakeholder feedback arrives, classify it: is this a frontstage concern (the interface doesn't work for users) or a backstage concern (the governance process isn't producing clear direction)? Frontstage concerns are the designer's to address. Backstage concerns are the organisation's to address - and the designer's to document.
And it means tracking contamination. When backstage dysfunction produces frontstage failure, log the mechanism. Over time, these logs become an evidence base for structural improvement. They also protect the designer from absorbing accountability for outcomes they couldn't control.
Questions I'm sitting with
Goffman's original framework describes how performers actively manage the boundary between frontstage and backstage. In organisations, who manages the line of visibility - and what happens when nobody does? The service blueprint makes the line of visibility structurally visible, but blueprints are typically created during service design phases that precede implementation; what happens when the blueprint doesn't exist and the service has already been running for years?
The accountability proposition assumes a clear professional jurisdiction for the designer. The next post in this series examines what the sociology of professions says about how that jurisdiction is established and contested. Can frontstage accountability hold when professional jurisdiction is not structurally embedded?
At what point does documenting backstage dysfunction become a responsibility to escalate? The framing gives the designer permission to observe and record - but does it also create an obligation to act? And the intermediary roles I observe (data intermediaries, analysts who prepare board packs) sit on the line of visibility itself - they are simultaneously backstage actors and frontstage performers. How does the framework account for people whose role is to translate between the two domains?
References
Bason, C. (2016) Design for Policy. Abingdon: Routledge.
Bitner, M. J., Ostrom, A. L. and Morgan, F. N. (2008) 'Service Blueprinting: A Practical Technique for Service Innovation', California Management Review, 50(3), pp. 66–94.
Cagan, M. (2018) 'Product vs. Feature Teams', SVPG Blog. Available at: https://www.svpg.com/product-vs-feature-teams/
Eisenberg, E. M. (1984) 'Ambiguity as Strategy in Organizational Communication', Communication Monographs, 51(3), pp. 227–242.
Goffman, E. (1959) The Presentation of Self in Everyday Life. New York: Doubleday.
Hood, C. (2011) The Blame Game: Spin, Bureaucracy, and Self-Preservation in Government. Princeton: Princeton University Press.
Kalbach, J. (2016) Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams. Sebastopol, CA: O'Reilly Media.
Magyari, R. and Secomandi, F. (2024) 'Service Blueprinting for Better Collaboration in Human-Centric AI'.
Merholz, P. and Skinner, K. (2016) Org Design for Design Orgs. Sebastopol, CA: O'Reilly Media.
Polaine, A., Løvlie, L. and Reason, B. (2013) Service Design: From Insight to Implementation. Brooklyn, NY: Rosenfeld Media.
Shostack, G. L. (1977) 'Breaking Free from Product Marketing', Journal of Marketing, 41(2), pp. 73–80.
Tarling, K. (2023) The Service Organization.