The problem with asking AI to design
There is a serious conversation happening in the design community about whether AI will replace designers. A lot of the answers I've read focus on what humans can supposedly do that AI cannot: understand human experience, empathise, exercise judgement, be creative. I don't find those arguments particularly convincing because they are too abstract. They don't give a designer anything concrete to hold on to, and they don't explain what part of the designer's work actually remains valuable when AI can produce a polished interface in minutes.
I think there is a much more tangible distinction. It comes from something I have been thinking about for years: solve for verbs, not nouns.
A noun is often the solution someone has already decided they want. A dashboard. A website. An app. A chatbot. A messaging system. A redesign.
A verb describes what somebody actually needs to accomplish: communicate, coordinate, discover, decide, prioritise, respond, complete. The difference matters because once you accept the noun, you have already constrained the solution.
A noun locks you in. A verb opens you up.
This is where I see an important difference between how AI is typically used and how an experienced designer approaches a problem. If I ask an AI to create a dashboard, it can ask me excellent questions. Who is going to use it? What information do they need? What decisions are they making? What are their pain points? What data is available? Those questions can produce a much better dashboard. But they are still questions being asked in service of the dashboard. The starting point remains the noun.
A designer has another question available: Why do we need a dashboard? That question takes us backwards. What are people actually trying to do? What is preventing them from doing it? What outcome are we trying to create? What behaviour needs to change? Perhaps the answer is a dashboard. But perhaps it is an alert, a workflow, a better process, a change in responsibilities, better information, or something else entirely. The point is not to reject the noun. The point is to avoid committing to it before understanding the verb.
The Mental Muscle Memory That Becomes Design Common Sense
I saw this distinction quite clearly while working with a client who was building an AI-enabled ALM product. The product combined task and project management capabilities with functionality for creating documents, spreadsheets and presentations. Early in the product discussion, the client told me they wanted chat. It was a perfectly reasonable request. In a collaborative product, people need to communicate with one another, and chat is an obvious way to support that.
What caught my attention was how early chat appeared in the requirements. So I started asking questions. Why do people need to chat? What are the situations in which they need to communicate? What is happening today? What do people need to know, and when do they need to know it? As we talked through actual situations, it became clear that the underlying need was not really one-to-one conversation. They wanted communication to be reliable. When something happened, the right person needed to know about it. There needed to be an expectation that the person would see it, acknowledge it and respond within an appropriate timeframe. The real problem was much closer to notification, acknowledgement, response and coordination.
That changed how we thought about the ALM product. Chat still made it into the application because it was a reasonable capability to have, but it was no longer confused with the purpose of communication. More importantly, the questioning helped us make the core product stronger because we understood what the client was actually trying to accomplish. The noun was chat. The verbs were much closer to notify, acknowledge, respond and coordinate.
The noun is not necessarily wrong. It is simply not the problem.
This is what I mean by design common sense. After enough years of doing this, you develop a kind of mental muscle memory. You hear somebody say, “We need a chat,” or “We need a dashboard,” and something in you wants to ask why before you start designing. It isn't necessarily a formal methodology running in your head. It becomes instinctive. It is a little like buttoning your shirt: you do it without remembering yourself making the individual decisions involved.
Remove the Friction That Slows Execution, Preserve the Friction That Enables Thinking
That instinct is also why I think the discussion about AI and designers needs a different framing. AI is extraordinarily good at removing friction from making things. Give it a requirement and it can produce something almost immediately. That is a tremendous advantage. We should absolutely use it to eliminate the friction involved in execution. But not all friction is bad. There is another kind of friction that is valuable: the friction that makes us stop before we commit to a solution.
When a designer asks, “Why do you need chat?”, that question can feel like resistance. It slows things down. It may even be frustrating to someone who has already decided what they want. But that resistance is productive when it prevents the team from confusing a proposed solution with the problem itself. The designer is not slowing down execution because designers enjoy process. The designer is slowing down commitment until there is enough understanding to know what should actually be executed.
This distinction becomes much more important when AI makes execution almost frictionless. In the past, deciding to build something carried a certain amount of natural resistance. A new product feature required time, people, money, coordination and organisational attention. Those costs created opportunities to reconsider the decision. If a team can now generate a convincing product, interface or feature in an afternoon, it becomes incredibly easy to turn an untested idea into something that looks real. And once something looks real, people begin to treat the original decision as validated.
Execution friction — delays, unnecessary process, manual work, coordination overhead. AI should remove this.
Thinking friction — the pause that makes us question assumptions, examine the problem, and reconsider the solution. We should preserve this.
AI makes it incredibly fast to make bad decisions permanent.
That, to me, is a much more serious design problem than whether AI can draw a screen. We have always been capable of making the wrong thing. What changes with AI is the speed at which we can move from a loosely formed idea to a functioning artefact, and then from that artefact to organisational commitment. The danger is not simply that AI will make bad design. It is that AI will make it extraordinarily efficient to execute a decision nobody examined carefully enough.
What happens when the noun becomes the starting point
There is a subtle difference between asking AI to improve a solution and asking a designer to determine the solution. If the starting point is “build a dashboard,” AI can reason about users, information architecture, interactions, visual hierarchy, components and workflows. It can become increasingly sophisticated as it works through the problem. But the direction of travel is still from the noun towards a better version of the noun.
Design thinking often requires a different movement. You start with the noun, then deliberately move backwards. Why a dashboard? What are we trying to make happen? What does success look like? What behaviour are we trying to enable? What is the underlying verb? Only after that do we move forward again and decide whether the noun should be a dashboard, a notification, a workflow, a process change or something else.
That backward movement is easy to underestimate because, once it becomes part of your professional practice, it stops feeling like a special skill. Experienced designers can become blind to how much of this thinking they do automatically. But it is precisely this apparently ordinary behaviour that can create enormous value. The designer is not simply adding another layer of polish to the proposed solution. The designer is questioning the direction of travel.
Two Steps Forward, One Step Back: The Tango of Creation
Sometimes a step back is exactly what is needed. For experienced designers, that step back can become almost instinctive. When presented with a solution, they naturally question the problem behind it before moving forward. AI, when given a noun as its starting point, tends to work forward from that starting point—to understand it, refine it and optimise it.
I am not making the argument that AI cannot question assumptions. It already can, and it will become better at it. Nor am I claimimg that only designers can find the underlying problem. A good founder, product manager, researcher or engineer can do exactly the same thing. The more durable argument is about a particular habit that good design practice develops: don't accept the noun as the problem simply because somebody presented it as a requirement.
That is also why I don't think the future of design should be framed as a competition between humans and AI. AI is extraordinarily useful once the problem has been understood. If the verb is “prioritise”, for example, AI can help explore dozens of possible ways of helping someone prioritise. It can prototype them, compare them, refine them and perhaps even evaluate them. That is an extraordinary amplification of design capability.
The danger comes when we hand AI the noun too early. Once we say “build a dashboard,” we have already made a decision about the solution. AI can help us make that decision work. The designer's responsibility is to ask whether we should have made that decision at all.
So, Is There Still Hope for Designers?
I don't think the useful question is whether AI will replace designers. The more useful question is: what do we mean when we say designer? If being a designer means taking an already-defined requirement and turning it into an attractive interface, then yes, that part of design is under serious pressure. AI is exceptionally good at producing visual treatments, layouts, components and polished interfaces, and it will continue to get better.
But if being a designer means understanding a requirement, questioning the assumptions inside it, finding the underlying problem, identifying the behaviour or outcome that needs to change, and then determining what solution will best address it, we are talking about a very different kind of work. That work does not become less important because AI can execute faster. In many ways, it becomes more important, because there is now less friction between deciding what to make and actually making it.
The future therefore isn't about protecting designers from AI. It is about being honest about which parts of design are valuable. We should let AI remove the friction of execution. We should use it to explore possibilities that would previously have taken weeks. But we should be careful about removing the friction that forces us to ask whether we are solving the right problem.
That is why I keep coming back to verbs and nouns. The noun is the thing we can increasingly ask AI to make. The verb is the thing we need to understand before we decide what to make. And perhaps the most important skill for designers in an AI-assisted world is not learning how to produce better nouns faster, but developing the instinct to stop, move backwards, and ask what verb is hiding underneath.
AI may replace designers who think their job is to make the noun. It will make the designers who can find the verb even more valuable.
