One of the biggest changes AI has brought is that far more people can make their ideas tangible. A thought can move very quickly into something people can react to.
The expertise barrier has lowered so far that you no longer need the same role, tool access or technical capability to make an idea visible. That is why people are talking about solo SaaS creators and one-person companies. The distance between idea and execution has collapsed.
Inside software development teams, the same thing is happening. More people can explore and express ideas without waiting for the usual handoffs.
That creates enormous possibility, but it also puts more pressure on judgement: which ideas are worth pursuing, what evidence is needed, and when something that looks convincing is still only an exploration.
I wanted to unpack what that means for design with Tom Wall, Principal Consultant in Experience Design at DiUS.
What emerged was that design is not separate from what is happening across product and engineering. The same pattern is showing up everywhere: as work becomes faster and more autonomous, fundamentals matter more. Teams need the judgement to steer the work, test assumptions and know how much review is needed.
There are many ways AI is changing design work. We did not try to cover all of them. What Tom and I kept coming back to was the artefacts themselves: more are entering the room faster, created by more people, with different levels of evidence behind them.
“The fact that everyone can prototype so easily and quickly now has thrown a rock into the water,” Tom said.
That disruption is useful, but only if teams stay clear about what the prototype is there to do. A screen can help test an assumption, compare options or align stakeholders. It can also start shaping scope, sequencing or budget before the team has agreed what it proves.
As Tom put it, teams can now bring something to life quickly. That does not mean it is “the right shape or format or way to deliver it”.
This is where design is, in many ways, same as it ever was. The artefacts are moving faster, and more people can create them, but teams still need to understand the user, the workflow, the service context, the trade-offs and the evidence behind the decision.
Use the tools, move faster and explore more ideas, but take a breath before an idea becomes scope, and before design intent turns into build decisions.
Keep exploration from becoming accidental direction
That’s where a design challenge sits: keeping cheap exploration from becoming accidental direction.
Tom’s advice is to work with the new energy around prototyping, but give it enough structure to be useful. “You have to bring that exploration and energy into the process and harness it to deliver better results,” he said.
That starts with being clear about what the prototype is there to do. Is it testing an assumption? Comparing two options? Helping stakeholders align? Exploring whether something is technically possible? Supporting a delivery decision?
Those are different jobs and they need different levels of evidence.
A clickable sketch used to provoke discussion does not need the same evidence as a prototype being used to approve scope. A technical spike testing feasibility is doing different work again. A screen generated by a stakeholder might be a useful starting point, but it should not become product direction just because it looks resolved.
Service design matters here too. When it is easy to generate a screen, teams can jump too quickly to one interaction before they understand the system around it. Who does the work today? What judgement are they applying? Where are the handoffs? What support is needed? What changes for users when the workflow is redesigned?
That surrounding context is often where the real design problem sits.
AI also changes what a prototype can contain. It might include working code, generated UI, sample data, mocked integrations or a rough version of the workflow. That is useful, but it also makes the line between learning and delivery easier to blur.
“Prototyping code and delivery code are doing different jobs,” Tom said. “One is there to learn quickly creating function. The other has to earn its place in the whole product.”
That’s an important distinction. A prototype can help prove that an idea is worth exploring. It does not prove that the thing is ready to run.
Design intent has to travel much further
Design has usually had to work a little ahead of delivery. In many teams, one designer supports several engineers, so the work has to be clear enough for build to continue without pretending every detail is fixed.
AI-assisted engineering changes that rhythm. “The speed at which devs can go is exponentially faster now,” Tom said. “So designers have to work faster.”
But producing more screens is only part of the answer. Design intent has to travel further than it used to. As delivery accelerates, more of the thinking behind the experience needs to become explicit. Journeys, behaviours, states, edge cases, accessibility requirements, content intent and failure modes all need to be clear enough for the rest of the team to use.
That intent cannot live only in a Figma file or in the designer’s head. Increasingly, it also becomes part of the specification itself. Annotated flows, interaction rules, state models, content patterns and acceptance criteria help engineers, AI coding assistants and test harnesses understand what the experience is trying to achieve, not just what it should look like.
That changes the role of design. More of the judgement has to be captured in a way other people, and increasingly AI systems, can apply consistently.
Design systems carry more of that load too. They need to hold more than components. They need usage guidance, interaction rules, accessibility notes, content patterns, examples and review criteria that help teams build and test consistently.
Designers do not need to become engineers. But their thinking needs to become easier for the rest of the delivery system to consume. As software delivery becomes more autonomous, design becomes less about producing artefacts and more about making intent explicit.
AI has to fit the workflow
Experience designers are also shaping how AI appears inside the product experience itself. Sometimes that starts with a clear workflow problem: a user is spending too much time searching, interpreting, summarising, matching or deciding between options. Sometimes it starts with broader pressure to show visible AI adoption.
That second starting point is risky. When the question is “where does AI fit?”, teams can jump to an interface pattern before they have understood the workflow, the cost, or who will be accountable for the output.
Tom described the shortcut simply: “We’ll put a box here, someone can type or paste something in, and the system will return an output.”
That can feel like progress because something new is visible in the interface. But it can also mean the team has assumed the solution before understanding the human context of the work.
The point is not simply to make the task faster. It is to understand the work well enough to know where AI should help, where people need control, and what would actually make the experience better.
This is where design helps define what AI should do, and what people still need to control.
For one client, Tom described a situation where the business opportunity looked like automation. The organisation wanted to move faster and reduce manual work in a complex process.
Research showed something more complicated. The people doing the work were interpreting context, making trade-offs and applying experience that was not visible in the workflow diagram. They saw craft in the work.
That changed the design problem. The team needed to work out where the system should assist, where the user should stay in control, and how to introduce the change in a way people understood and trusted.
“The role of the UX designer, UX researcher, championing the user and the customer, is even more relevant and needed right now when we can go down a hundred different rabbit holes,” Tom said.
This is where design helps make the tension workable: what job is AI doing, where does human judgement sit, what does the user need to understand, check or override, who reviews the output, what happens when it is wrong, and whether the value justifies the build, running cost and change effort.
Without that work, teams risk adding an AI feature when the better answer is a clearer workflow, better decision support, or a smaller change to the existing process.
Design judgement has to show up in more places
Clients are always asking what does AI mean for design. How is the role changing? How can design be used more effectively in AI-assisted engineering? What happens when AI-generated prototypes get thrown over the fence?
Tom sees the role stretching in two directions: earlier into problem framing, workflow and automation choices, and deeper into delivery through specifications, design systems, acceptance criteria and quality checks.
That makes sense. When more ideas can be made visible, design has to help teams understand which ones deserve attention. When delivery moves faster, design intent has to be clear enough for the whole system to use.
Screens, prototypes, research and design systems still shape what teams believe and what they build. But the evidence, assumptions and intent behind those artefacts need to be easier for others to understand and apply.
That is where Tom sees the role going. The fundamentals are still the fundamentals, but they need to be more visible, more usable and more explicit across the work.
