Users, stakeholders and the landscape around your design

In UK government the stakeholder landscape is uniquely complex. You're not working for a single product owner with clear authority. You're navigating policy teams, operational teams, security teams, commercial teams, GDS assessors, ministerial private offices, and sometimes other departments entirely. Each one has legitimate interests, different priorities, and varying levels of influence. The architect who can map that landscape, understand the dynamics, and move through it skilfully will deliver better outcomes than the architect who only focuses on the technology.

Why stakeholder understanding is an architecture skill

Architecture fails when the people side of the problem gets treated as someone else's job.

Many architects treat stakeholder engagement as a soft skill, something that delivery managers or business analysts handle while the architect focuses on the "real" technical work. This is a fundamental misunderstanding of what architecture is. Architecture is the set of decisions that are expensive to change. Many of those decisions are shaped, constrained, or blocked by people, not by technology. A design that ignores organisational politics, funding dynamics, or operational capacity is not a design that exists in the real world. It's a fantasy.

In government, this is amplified. Your architecture will be assessed by GDS. It will be scrutinised by security teams. It will need sign-off from senior responsible owners who may not understand the technology but absolutely understand the risk. It will be built by teams you may not control, operated by people you may never meet, and used by citizens who have no choice but to interact with it. If you don't understand that landscape, you can't design for it. And if you can't design for it, your architecture will fail, not because it was technically wrong, but because it was organisationally impossible.

Stakeholder understanding is part of architecture, not an optional extra. A design that ignores stakeholder reality is not fit for purpose.

Stakeholder mapping for government architecture

In government the stakeholder landscape is wider and stranger than most private sector contexts. Mapping it properly is the foundation of everything else.

Government stakeholder landscapes are unusually complex. In the private sector you typically have a product owner, a leadership team, and customers. In government you have policy teams who define what the service should achieve, operational teams who run it day to day, security and assurance teams who must approve it, commercial teams who manage suppliers, GDS assessors who evaluate it against the Service Standard, finance teams who control the budget, ministerial private offices who manage political risk, and sometimes other government departments who depend on or feed into your service.

Mapping this landscape is not a one-off exercise you do at the start of a project and then file away. It's a living model that you update as the programme evolves. People move roles. Priorities shift. New stakeholders emerge as the service takes shape. The practical approach is to identify everyone who can influence, block, or be affected by your architecture decisions, then understand what they care about, what power they have, and how engaged they currently are. This gives you the foundation for every engagement decision you'll make.

Map the landscape early, keep it current, and use it to drive better engagement and better decisions.

The power/interest grid in practice

A simple two by two that helps you decide where to spend your engagement effort.

The power/interest grid is one of the most widely taught stakeholder tools, and for good reason. It's simple: plot stakeholders on two axes (how much power they have over your work, and how interested they are in it) and you get four quadrants that suggest different engagement strategies. High power, high interest: manage closely. High power, low interest: keep satisfied. Low power, high interest: keep informed. Low power, low interest: monitor.

The danger is treating it as a fixed map rather than a dynamic model. In government, power and interest shift constantly. A stakeholder who was low interest last month becomes high interest when a ministerial question lands on their desk. A team with no formal power suddenly becomes critical when they control a dependency you hadn't identified. The grid is useful as a thinking tool, not as a permanent classification. Use it to decide where to focus your engagement effort this week, this sprint, this phase. But revisit it regularly, and be prepared for the landscape to shift beneath you.

Use the grid to focus your effort. Stay alert enough to update it when the world shifts.

User needs versus stakeholder wants

The GDS Service Standard tells you to start with user needs. In practice that creates one of the hardest dynamics you'll face.

The first principle of the GDS Service Standard is "start with user needs." This sounds straightforward until you're in a room where a senior stakeholder wants something that conflicts with what users actually need. A policy team wants complex eligibility rules that create a terrible user experience. An operations team wants detailed audit trails that slow the service down. A security team wants authentication requirements that exclude the most vulnerable users. These aren't bad people making bad decisions. They're people with legitimate concerns that happen to conflict with user needs.

The architect's role is not to pick a side. It's to make the trade-offs visible and help the organisation make an informed choice. Sometimes user needs win. Sometimes operational or security requirements take priority. The important thing is that the decision is made consciously, with full understanding of the consequences, rather than by accident because nobody surfaced the conflict. Your job is to design the options, articulate the trade-offs, and support the decision-makers in choosing well.

Start with user needs, understand stakeholder intent, and make the trade offs explicit.

GDS user research principles and what they mean for architecture

The user research principles aren't just for researchers and designers. They have direct consequences for how you design the service.

GDS user research principles state that research should be inclusive, ethical, and continuous. For architects, these principles translate directly into design constraints. Inclusive research means your architecture must support accessibility from the ground up, not as an afterthought. It means designing for assisted digital users, for people with low digital confidence, for people using older devices or slower connections. Ethical research means your data architecture must respect privacy, minimise data collection, and give users control where possible.

Continuous research means your architecture must support iteration. If the service will be tested and improved based on ongoing user feedback, you need to design for changeability. Monolithic systems that require months of work to modify are incompatible with continuous improvement. The architecture needs to allow the service to evolve as understanding of user needs deepens. This isn't about following a methodology for its own sake. It's about recognising that user research findings will shape your architecture, and designing in a way that can respond to what research reveals.

Good architecture supports good service design. If the architecture undermines user needs, accessibility, or iteration, it isn't fit for purpose.

Managing competing demands

In government, competing demands are normal. Pretending you can satisfy everyone is the fastest route to a service that satisfies nobody.

Every architecture decision involves trade-offs. In government, those trade-offs are amplified because you have more stakeholders with more competing interests than in most private sector contexts. The security team wants defence in depth; the delivery team wants speed. The policy team wants flexibility; the operations team wants stability. The finance team wants cost reduction; the users want a better experience. You cannot satisfy all of these simultaneously, and pretending you can leads to compromised designs that serve nobody well.

The skill is not in finding a magical solution that makes everyone happy. It's in making the competing demands explicit, helping stakeholders understand the consequences of each option, and supporting a clear decision. Document the trade-offs. Present the options honestly. Recommend where you have a professional view, but be transparent about what you're trading away. The worst outcome is a design that tries to please everyone and ends up as an incoherent mess of compromises. The best outcome is a design where the trade-offs were made consciously and the rationale is clear to everyone involved.

Good architecture negotiation isn't about winning an argument. It's about making difficult choices explicit, defensible, and fit for the whole service.

Understanding the political landscape

Government architecture operates inside a political environment that shapes scope, timelines, funding, and scrutiny in ways that have no real parallel in the private sector.

Government technology does not exist in a purely rational space. It operates within a political environment where ministerial priorities, spending reviews, election cycles, media scrutiny, and cross-departmental dynamics all shape what gets built, when, and how. An architect who ignores this reality will repeatedly find their designs derailed by forces they didn't anticipate. A project gets accelerated because a minister made a public commitment. A programme gets cut because the spending review changed priorities. A technical decision gets overruled because of reputational risk that has nothing to do with technology.

Political awareness doesn't mean becoming a political operator. It means understanding the environment well enough to design within it successfully. It means knowing when a decision is really a technical decision and when it's a political one wearing technical clothes. It means understanding why certain stakeholders behave the way they do, and what pressures they're responding to. It means designing architectures that can survive political shifts, not because they're politically neutral, but because they're resilient to the kinds of changes that political environments produce.

Good architecture in government combines technical excellence with political literacy. The aim is not to play politics. It is to design successfully within reality.

Building your stakeholder engagement practice

Engagement isn't a one off task. It's a habit you build through delivery and across your career.

Stakeholder engagement is not something you do once at the start of a project and then forget about. It's a continuous practice that you develop over time. The best architects build relationships before they need them. They invest in understanding people's concerns before those concerns become blockers. They communicate proactively, sharing progress and surfacing risks early rather than waiting until problems become crises. They build trust by being honest about trade-offs, reliable in their commitments, and transparent about uncertainty.

As you progress in your career, your stakeholder landscape gets wider and more complex. You move from engaging with a single delivery team to navigating department-wide governance. You move from explaining technical decisions to one product owner to influencing strategy across multiple programmes. The fundamentals stay the same: understand what people care about, communicate clearly, surface trade-offs early, and build trust through consistent, honest engagement. The scale changes, but the practice doesn't. Start building it now, and it will serve you throughout your career.

Good stakeholder engagement is an architecture practice. It builds trust, surfaces trade offs early, and produces decisions that can be supported as well as implemented.