Why designers need to lead AI transformation — not follow it
Over the past year, in monthly conversations with a group of design leaders working across sectors, two things have come up consistently:
- In organization after organization, AI adoption is being driven by techno-optimists — technology leaders and vendors moving fast, making consequential decisions, and bringing designers in after the architecture is set.
- Those same design leaders are genuinely excited. Not despite AI, but because of what it makes possible — the prospect of seeing their design vision realized deeper into implementation than the traditional design-to-handoff model ever allowed.
Both observations point to the same underlying reality. Organizations are making consequential decisions about AI without the people best equipped to make them well. Not decisions about the technology — those are being made carefully, with appropriate expertise. Decisions about the humans the technology will affect: who the system is actually for, what it will do to people navigating it under pressure, and whether it will work for the person at the edge of the use case, not just the person at its centre.
Those are design decisions. And in most AI implementations, they're being made by default — embedded in architecture choices, vendor selections, and system logic — before a designer has entered the room. Designers are the people trained to make those decisions well. The question isn't whether to include them. It's whether you bring them in before the consequential choices are made, or after.
What Designers Bring to AI
Design is not aesthetics. It is not the layer applied to technology to make it approachable. At its core, design is a set of structured practices for understanding how systems land on real people — and for building that understanding into what gets made, before it gets made.
- User-centred: User-centred design means something specific - methods for surfacing how a service or system is actually experienced, across the full range of people who will use it, including those whose needs sit furthest from the assumed default. It is not sufficient to design for the majority case and assume the edges will follow. The edges are where systems fail, where trust erodes, and where the gap between design intent and lived reality becomes visible. Designers are trained to find those gaps before they become infrastructure.
- Systems-thinking: Systems thinking in design means something equally specific - the ability to map a service or system as it is actually experienced — not as it was intended — and to hold the complexity of multiple stakeholder needs without flattening it into a single optimization target. It means tracing feedback loops, identifying where interventions produce unintended consequences, and keeping the impact on human actors as the primary concern even as the system grows in complexity.
- Iterative design: Iterative design is not simply a process preference. It is a mechanism for correction — specifically, for testing how a system performs for people at the margins before the architecture hardens. The value of iteration is not speed. It is the structured opportunity to discover what you got wrong, including for the users furthest from the centre of your assumptions, before getting it wrong becomes expensive to undo.
These three capabilities — user-centricity as method, systems thinking as practice, iteration as correction — are not soft skills. In an AI transformation context, they are the difference between a system that learns from the right inputs and one that optimizes toward the wrong ones.
Agentic AI Changes the Stakes
Most of this has always been true of technology implementation. What AI changes — and what agentic AI changes specifically — is the scale and irreversibility of getting it wrong.
Agentic AI systems do not wait for user instructions. They anticipate needs, plan actions, negotiate constraints, and intervene on behalf of users — or on behalf of the organization — without continuous human oversight. A chatbot that answers questions is a tool. An agentic AI system that triages a social care referral, adjusts a benefits calculation, or escalates a safeguarding concern is something fundamentally different. It is a participant in the service system: an actor with its own logic, its own data inputs, its own emergent behaviours, and — critically — its own potential for bias.
John Maeda, tracking the intersection of design and technology in his annual Design in Tech Report, described this shift in 2025 as AI placing design processes on a "perpetual, self-sustaining cycle" — one that doesn't end at delivery but continues to learn, adapt, and evolve. For agentic systems, that cycle runs without waiting for human instruction. The design challenge doesn't conclude when the system ships. It begins there.
This distinction matters for how we think about design's role. Designing for a tool means designing the interface through which humans use it. Designing for a participant means something harder and more consequential: mapping how that participant behaves across the full range of scenarios it will encounter, understanding how its dynamics interact with human actors in the system, and ensuring that its interventions serve the people most affected — including, especially, those with the least power to push back when the system gets it wrong.
Systemic designers are trained for exactly this. The Design Council's Systemic Design Framework explicitly addresses challenges that involve multiple actors, emergent dynamics, and consequences that cannot be fully predicted in advance. Treating agentic AI as a participant in that framework — not a tool within it — is not a conceptual abstraction. It is a practical requirement for implementation that doesn't produce harm at scale.
The gap is significant: practical frameworks for how designers should work with agentic AI are still nascent. But the methods are not. User-centred research, systems mapping, iterative testing at the edges — these apply directly. What's missing is design at the table early enough to apply them.
Algo-r-(h)-i-(y)-thms, 2018. Installation view at ON AIR, Tomás Saraceno's solo exhibition at Palais de Tokyo, Paris, 2018.
A Familiar Failure Pattern, Amplified by AI
None of this failure mode is new. Anyone who has watched a public sector modernization project lose the thread between research and implementation — the insights from service design evaporating somewhere in the handoff to the technical build — recognizes the pattern immediately.
A problem is identified. A technology solution is scoped. A vendor is selected. Somewhere in that sequence, the structured understanding of human need that should be driving the architecture gets translated into requirements, and something is lost in translation. By the time designers are engaged, the consequential decisions have already been made. What remains is interface work — valuable, but insufficient.
What's different now is that the stakes are higher — and so is the opportunity. The design leaders I speak to aren't resigned to this pattern. They see agentic AI and deeper access to architecture and implementation as precisely the opening they've been waiting for: the chance to close the gap between design intent and what actually gets built. That potential is real. But it depends on designers being present before the system's logic is set, not after. The excitement is warranted. The sequencing still matters.
Lou Downe, former Director of Design for the UK Government, makes the specific risk precise: AI optimizes within existing service architectures. It does not question whether those architectures are correct. If the underlying service excludes certain users, creates friction at the wrong moments, or was designed around organizational convenience rather than user need, AI will automate and accelerate that brokenness. At scale, without pause, and without the visibility that might prompt correction.
Good service design is a prerequisite for AI implementation, not a byproduct of it.
Trust in AI Is a Design Problem
Nesta's research on public attitudes toward AI-enabled government services found that fewer than half of the UK public trust the public sector to use AI responsibly. This is not a communications failure. It is the predictable consequence of systems being built without the disciplines that generate trust being present at the design stage.
Trust in services is built through consistency, clarity, and the felt sense that the system was designed with the user's interests — not the organization's convenience — as the primary concern. Transparency and accountability in AI systems are not values that emerge naturally from good engineering. They are design decisions: about what the system explains and what it conceals, about where human judgment is preserved and where it is delegated to an algorithm, about how errors surface and what recourse looks like.
When those decisions are made without design, they are still made. They are made by default, embedded in technical choices, reflecting the assumptions of whoever was in the room.
The Questions Worth Asking
If you are leading or commissioning an AI implementation, these questions surface whether design thinking is genuinely embedded in the process — or scheduled for later.
- Was a service designer involved before the technology was selected? If design engagement began at the interface stage, the sequencing error has already occurred.
- Who defined the problem this system is solving, and what methods did they use? If it was defined by technology capability or procurement requirement rather than structured inquiry into user need, the foundation is weak regardless of the technology's sophistication.
- How was the full range of people this system will affect — including those at the margins — represented before the architecture was set? AI systems that work for the majority and fail the minority don't usually fail visibly. The failure is distributed, quiet, and hard to attribute.
- If this system includes agentic AI — if it will act without continuous human instruction — who is mapping its behaviour as a participant in your service, not just a component of it? Who is responsible for understanding what it does when it encounters edge cases its training didn't anticipate?
- What happens when the system is wrong? Recourse is a design problem. If no one has designed the failure mode, the failure mode will design itself.
What This Asks of Leaders
The question for any leader commissioning AI transformation is not whether to invest in the technology. It is whether the people who understand systems from the inside — from the perspective of the humans navigating them — are shaping what gets built before the architecture makes that shaping impossible.
Designers are those people. Their methods are not supplementary to AI transformation. For any system that will touch real users, in real circumstances, with real consequences for getting it wrong — they are the prerequisite.
The only variable is when you decide to bring them in.
Mark Kuznicki
Mark is the kind of person you want around when things feel messy. He has a knack for bringing clarity to complexity, helping teams, leaders, and organizations navigate change in a way that makes them more sustainable and ready for the future.