Designing in Code - But Whose Code?
Last week I was asked to scope what it would take to build a React component library for a national healthcare data platform. As I've been writing the scoping document, I keep returning to a tension that's been present throughout my career: the relationship between designing and building.
I'm a designer who codes. I've built React applications, macOS applications, iOS applications. I believe, that whilst there are situations when lo-fi prototyping and Figma are the right solution, there is also immense value in the power of working prototypes over static specifications; Brad Frost (2016) captures this well when he argues that "once the designs are in the browser, they should stay in the browser" (p. 9) and sometimes particular dynamic data driven products or services demand being programmatically prototyped, not just to test how they render at different responsive resolutions, but in response to dynamic data and user interactions.
When I reflect on the "just build it" methodology of one of our current platform vendors, the objection is not to designing in code per se, but to the question of which code, which design sensibility, and which problems get centred when we skip the conversation about what should be built, and how genuinely collaborative the code-based iteration can be in practice.
The vendor's approach to building software is called Forward Deployed Engineering - a model pioneered by Palantir in the early 2010s that claims lineage from military design thinking, a field I've studied as part of my doctoral research and encountered professionally during my time at FOI, the Swedish Defence Research Agency. Having spent time with both the practice and the wider literature around military design thinking, I'm increasingly convinced that the FDE model has inherited a preoccupation with the alleged "need for speed" of military operations and building in code or directly on a platform,while discarding the representation and reflection that makes military design thinking, and design prototyping actually work in practice, particularly in non-military healthcare contexts.
The Forward Deployed Engineer
The Forward Deployed Software Engineer (FDE) concept is straightforward: instead of building software in an office and shipping it to customers, you embed engineers directly with customers to build software in situ. Palantir (2022) describe the role as a software engineer who "embeds directly with our customers to configure [the vendor's] existing software platforms to solve their toughest problems". The pitch is compelling: rather than the "gulf between user and developer" that plagued traditional defence contractors, FDEs work alongside the people who will use the software.
Karp and Zamiska (2025) tell the origin story through the lens of Afghanistan. In 2011, soldiers were being killed by IEDs while the Army's incumbent software couldn't help them analyse the intelligence they needed. The problem, Karp argues, was distance: "those designing the army's software system at the time... were too far and too disconnected from the actual users of the software, the soldiers and intelligence analysts, in the field" and "the gulf, between user and developer, had grown too wide to sustain any sort of productive cycle of rapid iteration and development" (p. 22). The solution was proximity - engineers sent to Kandahar, software built alongside soldiers, feedback loops compressed from months to hours.
This is a powerful critique of traditional enterprise software development; the procurement processes, the layers of subcontractors, the separation of specification from implementation really do produce software that fails its users. Scaman (2025) captures the FDE ethos: engineers "go into client organisations and build fast, hacky, whatever-works solutions". The approach has genuine strengths, but it also has structural absences that become visible when set against the military design thinking tradition it claims to draw upon.
What Military Design Thinking Actually Says
The FDE model draws on military imagery - "forward deployed" is itself a military term meaning positioned at the front lines - and the emphasis on speed, iteration, and user proximity echoes themes from military design thinking literature.
During my time at FOI, I became familiar with how Scandinavian defence research approaches complex operational environments. Later, through my doctoral studies, I have engaged more deeply with the academic literature on military design thinking - a field that emerged in response to the recognition that modern warfare is complex and adaptive. What that literature describes, however, is quite different from the FDE model.
Wrigley et al.'s (2021) extensive review of military design thinking identifies "conception of the environment as a system" as a core characteristic, noting that "systems thinking, and the representation of systems using diagrams, is a common element of military design" (p. 12). The emphasis is mine, but the point is theirs: representation matters. Military design thinking emerged from a recognition that you can't plan your way to victory using traditional analytical methods; the response wasn't to abandon planning but to change how planning works. Design became about "framing" problems, developing shared mental models, and - crucially - representing those models in forms that could be examined, critiqued, and revised.
Zweibelson (2023), drawing on Donald Schön's work, distinguishes between "knowing in action" and "reflecting on action"; reflective practitioners don't just do, they think about what they're doing while they're doing it. This requires slowing down enough to represent what you're learning, moving away from what Zweibelson calls "what-centric descriptions that reinforce legacy sanctioned activities" toward a practice where "reflective practitioners consider 'knowing in action'" (p. 9). The US Army's doctrinal approach to design includes "the development of environment and problem frames to ensure adequate understanding" (Jackson, 2019, p. 9). Frames are representations - diagrams, maps, models, ways of making complexity legible so it can be discussed.
Military design thinking takes the opposite view: the shared representation matters - not as a contractual specification but as the vehicle through which collective sensemaking becomes possible.
The Divergence
The FDE model's divergence from its claimed military heritage reflects a broader pattern. The US Department of Defense's own acquisition reform, as Hobson (2023) documents, was driven by a "particularly keen focus on engaging with, and emulating, the apparent agility, speed and boldness of private sector innovation - especially that of 'move fast and break stuff' start-up culture, Silicon Valley and Venture Capital" (p. 85). The FDE model emerged from this nexus, and it carries the same selective inheritance: speed, iteration, customer proximity, outcome focus - the bits that suit a commercial software company - while leaving behind deliberation, representation, reflection, and shared mental models. Bailey (2021) identifies the same logic operating in UK public sector design, where speed "is reflected in the nomenclature - 'rapid' prototyping, lateral thinking 'sprints', hackdays and 'jams'" and design "proposes itself as a light-footed and entrepreneurial catalyst of change" in contrast to "the supposed inertia of the bureaucratic machine" (p. 179). As Holliday (2022) warns, the technology and innovation mantra of "move fast and break things" risks genuinely bad outcomes in public service contexts, where the consequences of building the wrong thing fall on people who depend on services they didn't choose (p. 15) rather than one they can find an alternative to.
Part of the divergence is the nature of the product itself. The vendor's platforms are "ontology-oriented" in their language: they model the customer's world in software. As Palantir (2024) describe it, the ontology is "a technical solution to this linguistic challenge: instead of treating each different interface as a distinct language, an ontology represents a single language capable of being expressed in graphical, verbal and programmatic forms". The vendor's instinct is to build rather than to discuss; to model the customer's world directly in the platform's own object and conceptual structures rather than to develop shared representations that might precede or challenge those structures. From the vendor's perspective, why spend time drawing a systems map or debating what the right solution might be when you can build a working version shaped by - and, crucially, constrained to - what the platform already supports?
Part of it is competitive advantage. Speed is a moat; if you can build overnight what your competitors take months to specify, you win deals. Karp and Zamiska (2025) celebrate this: their engineers in Afghanistan built software that the Army's procurement process couldn't deliver in years.
There is a cost, however. A React application built overnight to justify drag-and-drop tiles, then removed two weeks later when a stakeholder decided "we want it to look the same for everyone", illustrates the pattern: the speed was real, the iteration was real, but the sensemaking never happened. Nobody asked what problem was actually being solved. The feature was built, shipped, and removed without that question ever being addressed - velocity without direction.
Responding primarily to what individual, often very senior, users request at a given moment risks creating a patchwork of features that neither fit together nor reflect the needs of the wider user base, generating technical and design debt that over-indexes on one user's expressed preference while slowing future development. In healthcare contexts, what the FDE model optimises for - speed - is insufficient on its own; what matters is velocity (building the right thing at pace) and quality, which means accounting for the wider health system the product sits within rather than just the demands in the room.
Contrast with GDS and Agile Approaches
The FDE model isn't just different from traditional waterfall development; it's also different from the agile and GDS-influenced approaches that have shaped UK public sector digital practice.
The Government Digital Service established a delivery model with explicit phases: Discovery, Alpha, Beta, Live. Each phase has a purpose - discovery for understanding the problem before committing to a solution, alpha for prototyping and testing hypotheses, beta for building and iterating with real users. As Kimbell (2015) observes, "the idea of prototyping is already familiar to some people within government", noting that "GDS has a clearly defined delivery life cycle for digital projects, including discovery, alpha, beta and live phases" (p. 27). This isn't bureaucracy for its own sake; it's a structured approach to ensuring that representation - in the form of research findings, prototypes, and tested hypotheses - precedes and helps risk-assess commitment.
The key difference is where design happens in the process. In GDS-influenced approaches, design happens before and during development; user research informs design decisions, prototypes are tested before code is committed, and there is a "double diamond" of divergent and convergent thinking with explicit space for exploring the problem before committing to solutions. In the FDE model, design happens through development; the artefact is the software itself, and feedback comes from usage rather than from pre-implementation review. Herbert (2023) notes that "with the advent of GDS came a brave new world of user-centrism, where the requirement to consider user needs became the dominant focus" (p. 24); the FDE model shares this focus on users but inverts the methodology, building first and then, in theory at least, observing whether needs are met rather than researching needs before building.
Both approaches can work, but they require different conditions. The FDE model works when you have embedded engineers with strong product intuition, when the problem space is relatively well-understood, and when iteration cycles can be genuinely rapid. The GDS model works when problems are contested, when multiple stakeholders need to align, and when the cost of building the wrong thing is high. Healthcare, for the most part, particularly when working in a national health system, is the latter: clinical users have complex, often conflicting needs; accessibility requirements are non-negotiable; the consequences of poor design - interrupted workflows, missed information, excluded users - can affect patient care.
Where This Leaves Public Sector Design
The two models collide in daily practice. Public sector user-centred design is representation-heavy: research, synthesis, and prototyping produce artefacts - journey maps, service blueprints, design principles - that exist to be examined, critiqued, and revised before anything gets built. Designing in code makes the running prototype the primary artefact, but prototyping in code is still representation-heavy in the relevant sense; the prototype exists to explore and communicate design decisions before committing to production, and it can be tested and debated just as a static specification can. The important difference from the FDE model is that code-based prototypes can be built in open design systems, meaning design possibilities are not constrained to what the vendor's platform configuration interface supports.
One of the key problems is power asymmetry. The vendor's forward-deployed engineers have platform access; they can build overnight. Public sector designers have guidelines and, in some cases, limited access to the platform's configuration tools, but in general we can recommend without being able to iterate the prototype ourselves.
Design Systems as Frozen Representation
Building a design system matters precisely because of this, and because it needs to be done deliberately rather than in the FDE style.
A provocotype in front of users can generate feedback, but the point is that it is a prototype - a representation that exists to be examined, critiqued, and revised, and tested at increasing scale before the product is launched or made generally available.
Without representation - without diagrams, prototypes, specifications - those contests happen implicitly, in code, where they're invisible to anyone who can't read TypeScript. A vendor with a dogmatic preoccupation with speed can build overnight, but without the conversation about what you're building, why, and how it might be wrong, you're just building faster without necessarily building better.
A design system is an attempt to create artefacts that exist between "nothing" and "shipped software" - to force the conversation that the FDE model assumes is unnecessary. It enables faster iteration by reusing proven components that themselves have been designed and tested and will become familiar to users, whilst still allowing enough flexibility to iterate anew when a task doesn't fit existing patterns. It's a way of freezing representation in a form that can be examined, critiqued, and revised, but that also runs, so it can be tested and iterated in the browser in production-quality code.
The Politics of Speed
The political economy of speed is worth examining directly. Karp and Zamiska (2025) frame velocity as a virtue; soldiers were dying while the procurement process deliberated, and the moral case for speed in that context is straightforward. British healthcare is not warfare in Afghanistan, however, and the claim that urgency justifies skipping sensemaking does not transfer cleanly. Clinical users are under pressure, not under fire, and much of what the current platform supports - an additional tab in an existing workflow, a new operational dashboard for managers - does not carry the existential stakes the FDE model's origin story invokes to justify its approach.
The distribution of benefit and cost when the vendor builds overnight is not neutral. The vendor demonstrates capability; the client sponsor sees rapid progress; the one or two end users who directly specified what got built receive working software quickly tailored to their expressed demands. End users who were not in the room get the wrong software faster; designers who never got to contribute will later remediate alongside accessibility specialists; product and delivery managers lose visibility into what is being built and when; and the organisation accumulates technical and design debt as features built in response to one user's feedback get reworked in response to another's, while products built to one provider's specification struggle to scale to system-wide design patterns or data infrastructures.
The FDE model works when the problem is clear, when data sources are clean, and when iteration can be genuinely informed by user feedback. It fails when the problem is contested, when users cannot articulate what they need, or when the systemic challenges the software is intended to address extend to data pipelines and unreliable source systems that no amount of quickly iterated, drag-and-drop-built applications can resolve. In NHS contexts - where legacy data infrastructure and analogue processes mean the front-end application is only ever as good as the data and workflows feeding it - optimising for speed alone is insufficient; what matters is building the right thing at a pace that accounts for the wider human systems the product sits within.
What This Means for the Scoping Work
The scoping document itself is a form of representation - an argument for a particular team, timeline, and approach that exists to be examined before resources are committed.
The FDE approach would be different: start building, see what works, iterate, with the software as the representation. The appeal is genuine; scoping documents can become bureaucratic cover for inaction, and a good developer could build something real in the time it takes to write, review, and approve a specification.
The pattern when this step gets skipped is consistent, however. Each product develops its own design conventions and its own technical debt; patterns propagate across a platform before anyone has asked whether they are the right patterns; and the cumulative user experience is a patchwork of inconsistent interactions that frustrate users and slow down workflows - before even accounting for the data pipeline challenges that also affect product viability.
References
Bailey, J. A. (2021). Governmentality and power in 'design for government' in the UK, 2008-2017: an ethnographic study [Doctoral thesis]. Lancaster University.
Frost, B. (2016). Atomic design. Brad Frost. https://atomicdesign.bradfrost.com/
Herbert, J. (2023). Lessons learnt from government digital transformation. [Working paper].
Hobson, T. (2023). Sociotechnical imaginaries, the future and the Third Offset Strategy [Doctoral thesis]. Lancaster University.
Holliday, B. (2022). Multiplied: How the best companies create breakthrough products through collaborative multidisciplinary design. FutureGov.
Jackson, A. P. (2019). A brief history of military design thinking. Journal of Military and Strategic Studies, 19(3), 1-25.
Karp, A., & Zamiska, N. (2025). The technological republic. Crown.
Kimbell, L. (2015). Applying design approaches to policy making: Discovering policy lab. [Report]. University of Brighton.
Palantir. (2022, June 6). A day in the life of a Palantir Forward Deployed Software Engineer. Palantir Blog. https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
Palantir. (2024, January 23). Ontology-oriented software development. Palantir Blog. https://blog.palantir.com/ontology-oriented-software-development-68d7353fdb12
Scaman, Z. (2025, December). The Palantir model. Substack. https://zoescaman.substack.com/p/the-palantir-model
Wrigley, C., Mosely, G., & Mosely, M. (2021). Defining military design thinking: An extensive, critical literature review. She Ji: The Journal of Design, Economics, and Innovation, 7(1), 104-143.
Zweibelson, B. (2023). Beyond the pale: Designing military decision-making anew. Palgrave Macmillan.