The translation problem
The previous post argued that service design offers programme management cultures three things they cannot generate from their own logic: the cross-cutting view, the surfacing of invisible decisions, and the temporal perspective. But possessing these capabilities is not the same as being able to deploy them. The designer who sees what programme management cannot see faces an immediate practical problem: how do you communicate insights across an epistemological boundary? How do you make the cross-cutting view legible to governance structures that are organised around decomposition?
This is not a communication skills problem, though it is often framed as one. The advice given to designers in programme management cultures - learn to speak the language, understand the governance, present your work in terms they understand - is not wrong, but it underestimates the difficulty. The difficulty is not that designers use the wrong words; it is that the concepts they need to communicate do not have straightforward translations in programme management vocabulary. "User need" translates imperfectly into "requirement". "Journey" translates imperfectly into "process". "Insight" translates imperfectly into "finding". Each translation loses something essential, and the accumulation of these losses produces the familiar experience of design work being technically accepted but substantively ignored.
Star and Griesemer (1989), working in the sociology of science, developed the concept of boundary objects to understand exactly this problem: how different social worlds coordinate despite having different practices, assumptions, and purposes. A boundary object is, in their original formulation, an object "both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites". The earlier exploration of boundary objects examined this concept in depth; what matters here is its application to the specific challenge of design practice within programme management.
Why journey maps stay on the wall
The concept of boundary objects explains a phenomenon that frustrates designers working in programme management cultures: certain design artefacts gain traction while others are admired and ignored. Journey maps, personas, insight reports - these are standard outputs of design work, and they are often well-received in the moment of presentation. Programme managers nod, ask questions, express interest. And then the artefact is pinned to a wall or saved to a shared drive and never referenced again in a governance decision.
This happens because these artefacts function as boundary objects within the design community - they are legible to other designers, they carry design intelligence, they coordinate design work effectively - but they do not function as boundary objects across the boundary that matters. Programme governance makes decisions through specific artefact types: business cases, risk registers, highlight reports, gateway review evidence, options papers, decision logs. These are the boundary objects of programme management; they are the representations through which decisions are made, resources allocated, and accountability discharged. A journey map, however insightful, does not fit into any of these governance mechanisms. It exists outside the decision-making infrastructure.
Bergman, Lyytinen, and Mark (2007) extend Star's analysis to design settings, showing how design artefacts function as boundary objects within an ecological system of interrelated representations. The implication is that the designer's task is not simply to produce good design artefacts but to understand the ecology of representations within which programme decisions are made, and to create outputs that can enter that ecology. Rasche and Pfannstiel (2018) describe how boundary objects play an important role in "overcoming differences in disciplinary viewpoints" in healthcare service design - but only when they are structured to be legible across the relevant boundaries.
Translation, not evangelism
Bessant (2011) identifies the role of the "organizational translator" - someone able to express the interests of one community in terms of another community's perspective. This is, arguably, the core competence of a designer working in programme management: translation, not evangelism. The designer who can take a user research insight and express it as a delivery risk - "if we build this without understanding the clinical workflow, we will have to rebuild it after go-live" - is translating between worlds. The same applies to the designer who expresses a cross-cutting journey as an integration dependency within the programme plan, or who reframes a usability finding as an accessibility compliance risk.
This translation work is not cynical manipulation, though it can feel that way. It is accurate reframing. Poor user experience in healthcare systems is a genuine delivery risk; cross-cutting journeys that are not designed do produce integration failures; usability problems in clinical systems do create safety incidents. The designer is not distorting the insight by translating it into programme language but expressing a dimension of the insight that is genuinely present yet not visible through the design vocabulary alone.
The practical implication is that designers working in programme management cultures need a dual literacy: the ability to do design work in design terms and the ability to express that work in programme management terms. This is more demanding than simply "learning the language" because it requires understanding what programme management is actually trying to do - managing political and operational risk - well enough to show how design work contributes to that objective.
Eberhagen (2011) describes how prototype systems in his research became "boundary-spanning objects, linking the worlds of designers and users" through iterative movement between communities. The same dynamic applies at the organisational level, where design artefacts must span the boundary between design practice and programme governance.
Boundary objects and exposure artefacts
There is a further distinction that matters in programme management contexts, one drawn from the earlier exploration of visibility and its limits. Not all artefacts that cross boundaries do the same work. Boundary objects, in Star's formulation, maintain productive ambiguity; they allow different communities to collaborate without requiring consensus on what the object means. Exposure artefacts, by contrast, force uncomfortable truths into the open; they make visible something that was previously invisible or tacitly ignored, and in doing so they disrupt the existing social equilibrium.
The designer working in programme management must make a political judgment about which kind of artefact the situation requires. Sometimes what is needed is a boundary object - something that allows design and programme management to coordinate without forcing a confrontation about whose epistemology is correct. A service blueprint that maps design insights onto programme milestones, for instance, allows both communities to work from the same artefact while interpreting it through their own frameworks. The design team reads it as a journey; the programme team reads it as a dependency map. Both readings are valid, and the ambiguity is productive.
Sometimes, however, what is needed is an exposure artefact - something that makes visible a problem that programme governance has not engaged with, and that cannot be addressed without changing how the programme operates. A map showing that users encounter eight different services from four different organisations in the course of a single pathway, and that nobody owns the transitions, is an exposure artefact. It does not maintain ambiguity; it creates common knowledge of a problem that was previously distributed across organisational boundaries and therefore invisible to any single governance structure.
Knowing when to use which kind of artefact is a political skill as much as a design skill. Boundary objects build trust and enable collaboration; exposure artefacts create discomfort, highlight risks and demand action. A designer who produces only boundary objects will be liked but will not change anything; worse, the productive ambiguity that makes boundary objects useful also makes them vulnerable to capture. The very quality that allows different communities to read an artefact through their own frameworks means that the more powerful community can absorb it into existing narratives - a service blueprint intended to reveal user needs becomes, in the hands of programme governance, evidence that the programme is already user-centred. The designer's work is incorporated, but its transformative intent is neutralised; it becomes a performative token that legitimises the status quo rather than challenging it - the captured design pattern where the rituals of user-centred practice continue while the substance of design influence is contained. A designer who produces only exposure artefacts, meanwhile, will be seen as disruptive and will eventually be excluded. The work on social defences in design identifies the defensive routines that organisations deploy when confronted with uncomfortable truths; the skilled designer reads the organisational context and chooses the right artefact for the right moment.
The conditions for translation
Translation work requires conditions that are not always present. It requires that the designer has enough access to programme governance to understand how decisions are actually made - not just the formal governance structure but the informal networks, the pre-meeting conversations, the relationships between senior responsible owners. It requires that the programme has enough tolerance, and perceived time and space, for design contributions to be heard. And it requires that the designer has enough organisational standing to be taken seriously when they express design insights in programme language.
But the question of why a programme creates space for design is more complex than it first appears, and the answer determines what kind of translation is possible. Programmes may value design for its functional contribution - the de-risking, the identification of integration dependencies, the surfacing of user needs that would otherwise emerge as delivery failures. This is the instrumental case for design, and it is genuine. Yet programmes also value design for what Meyer and Rowan (1977) would call its function as a "rationalised myth": the adoption of design practices signals that the programme is modern, user-centred, and evidence-based, regardless of whether design insights actually shape decisions. The designer's presence aestheticises the programme - journey maps and service blueprints become symbolic artefacts that demonstrate commitment to users in the same way that Gantt charts demonstrate commitment to delivery. The design work makes the programme look like a programme that cares about its users, and this symbolic function has institutional value independent of any substantive design influence.
The difficulty for the designer is that these two functions - instrumental and symbolic - are not always distinguishable from the inside. A programme that commissions user research may genuinely intend to act on the findings, or it may need the research to exist as evidence of due diligence without any mechanism for the findings to enter governance decisions or shape the design of programme touchpoints or workflows. Brunsson (1989) describes this as the logic of "organised hypocrisy": organisations routinely talk, decide, and act in three different registers, so that the talk about user needs, the decision to commission design work, and the action of building what was already planned can coexist without contradiction. The designer who assumes their translation work will be received instrumentally - that a well-framed risk will change a decision - may find instead that their work is received symbolically: acknowledged, praised, filed, but never materially employed to reshape the service or products the programme is delivering, or 'managing' in a gateway review. The conditions for translation, then, include not just access and standing but a genuine operational connection between what design produces and how programme decisions are actually made.
These conditions are not given; they must be built. The next post examines how governance itself can become a design material - not an obstacle to be navigated around but a structure that, understood properly, creates the conditions for trust and enables possibilities that would not exist without it.
References
Bergman, M., Lyytinen, K. and Mark, G. (2007) 'Boundary Objects in Design: An Ecological View of Design Artefacts', Journal of the Association for Information Systems, 8(11), pp. 546-568.
Bessant, J. (2011) Managing Innovation: Integrating Technological, Market and Organizational Change. Chichester: Wiley.
Brunsson, N. (1989) The Organization of Hypocrisy: Talk, Decisions, and Actions in Organizations. Chichester: Wiley.
Eberhagen, N. (2011) Understanding the Designing of Knowledge Work Support Tools as a Boundary Practice. Blekinge Institute of Technology.
Meyer, J.W. and Rowan, B. (1977) 'Institutionalized Organizations: Formal Structure as Myth and Ceremony', American Journal of Sociology, 83(2), pp. 340-363.
Rasche, C. and Pfannstiel, M.A. (2018) 'Service Design and Service Thinking in Healthcare and Hospital Management', in Service Design and Service Thinking in Healthcare and Hospital Management. Cham: Springer.
Star, S.L. and Griesemer, J.R. (1989) 'Institutional Ecology, "Translations" and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39', Social Studies of Science, 19(3), pp. 387-420.