Design has been too settled for too long

Most digital product teams have been running some version of the same process for years. A problem gets shaped somewhere between product, design and leadership. Research may or may not happen. Designers explore a few flows, tidy them into something presentable, turn them into a Figma prototype, run them through critique, package them up for engineering and then spend the next few weeks explaining the details in Slack, Jira and standups.

The quality varies wildly. Some teams do this with real thought and care. Others do a kind of product-development theatre, where everyone knows the big decisions were made before the kickoff. But the choreography is familiar.

Figma sits at the centre of this world. It became the shared room where product ideas were made visible. That was a big step forward. It pulled design out of static files and into a place where teams could comment, collaborate and maintain something resembling a shared source of truth.

But it also had a flattening effect. After a while, every team started to look like it was doing design in roughly the same way. The same boards. The same sticky-note clusters. The same components. The same slightly over-polished prototypes. The same awkward handoff ritual where design pretends the work is finished and engineering gently reveals that it is not.

For a discipline that talks so much about change, design has been running on a surprisingly settled operating model.

AI is starting to break that model.

Designer Fund’s latest AI in Design 2026 report gives some numbers to what has been obvious in the hallways, group chats and demo calls for the past year. AI use among designers is no longer a side experiment. Weekly AI usage for design tasks has jumped from 54% to 91% in a year, with 75% of designers now using AI daily.

That alone would be enough to make the report worth reading. But the more interesting story is not that designers are using AI tools more often. It is that the shape of design work is changing.

One of the report’s more striking findings is that half of the designers surveyed say they have shipped AI-generated code to production. Not just design engineers. Not just technical specialists. Designers across product and brand roles.

That feels like a line being crossed.

For years, the “should designers code?” debate had a faintly religious quality. Some people believed coding was an essential part of the craft. Others argued that designers should focus on understanding people, systems, behaviour and interaction, rather than pretending to be second-rate engineers. Most teams found a practical middle ground. Designers learned enough to understand constraints, engineers learned enough design to care about the details, and everyone carried on.

AI makes that debate feel strangely dated.

The more relevant question is no longer whether designers should become engineers. It is what happens when designers can make working software without becoming engineers in the traditional sense. What happens when they can test a flow in a real browser instead of faking it in a prototype? What happens when they can spin up variants, wire together data, simulate edge cases, or build something small enough to put in front of users?

And, just as importantly, what happens when everyone else can do the same?

Product managers can now create credible prototypes without waiting for design. Engineers can generate interfaces that no longer look like internal tooling from a decade ago. Founders can describe a product idea and have something clickable before the meeting ends. None of this means the work is good. A lot of it will be mediocre. Some of it will be actively misleading. But it will look finished enough to travel around an organisation.

That changes the politics of design.

For a long time, one of design’s sources of power was that designers could make ideas visible. They could take an abstract strategy, a customer problem, a messy product requirement or a founder’s half-formed thought and turn it into something people could react to. That still matters. But it is no longer the preserve of the design team.

When visualisation becomes cheap, the value shifts elsewhere. Taste matters more. Judgment matters more. The ability to spot a shallow answer dressed up as a polished interface matters more. So does the ability to understand whether the thing being made is worth making in the first place.

This is where the Designer Fund report gets especially interesting. It isn’t saying designers are being squeezed out. It suggests almost the opposite. Designers are owning more and shipping more. But they are also moving up a level of abstraction. They are not just producing deliverables. They are building tools, workflows and systems that change how design gets done.

That is a very different story from the lazy “AI replaces designers” narrative. It suggests the role is stretching rather than simply shrinking.

The report found that 65% of designers are taking on more product or engineering responsibilities, while 40% say PMs and engineers are contributing more to design work. Traditional role boundaries are blurring, not because somebody ran a reorg and updated a competency framework, but because the tools are making old handoffs feel slower and less necessary.

That sounds exciting if you are the sort of designer who has always wanted more agency. It sounds threatening if your sense of value is tied too closely to ownership of the mockup.

Both reactions are understandable.

There is a real opportunity here. Designers have spent years complaining that they are brought in too late, asked to decorate decisions, blocked by engineering capacity, or reduced to producing artefacts for someone else’s roadmap. AI gives designers a chance to get closer to the material of the product. Not just to imagine, but to make. Not just to propose, but to test. Not just to hand over, but to learn from what happens next.

But that opportunity will not distribute itself evenly. The designers who wait for a settled best practice to emerge may find that the practice has already moved on without them.

This is the uncomfortable bit. The tool stack is no longer obvious.

For the last decade, a design leader could make one fairly safe assumption: the team would probably use Figma. There would be other tools around it, of course. Research repositories, whiteboarding tools, analytics platforms, prototyping tools, design system documentation, ticketing systems. But Figma was the centre of gravity.

Now the centre is moving.

The Designer Fund report says the average designer now uses seven off-the-shelf AI tools regularly, more than double last year’s average of three. That does not include the internal tools many teams are building themselves.

This is the bit I think a lot of leaders are underestimating. We are not seeing one new design tool replacing the old one. We are seeing the stack fragment.

Some designers are working in Figma with AI features layered on top. Some are moving into code-first tools. Some are using AI-assisted prototyping environments. Some are building internal workflows with Claude, ChatGPT, Cursor, v0, Framer, Lovable, Replit or whatever tool appeared last Tuesday and suddenly seems to be in every group chat. Some are stitching together messy little workflows that would horrify an operations team but let them learn three times faster.

A lot of this will shake out. Some tools will disappear. Some will get bought. Some will become features inside bigger platforms. Some will turn out to be demo candy. But waiting for the dust to settle is not much of a strategy when the dust is the thing you need to understand.

Designers now have to become much more intentional about their stack. Not in a breathless “ten tools that will change your life” way. More practically: what do we use for exploration? What do we use for prototyping? What do we use when we need real code? Where does our design system live? How do we stop people generating off-brand mush? Which tools help us think, and which ones simply produce more stuff?

That last question matters more than most teams want to admit.

AI is very good at increasing the volume of plausible output. More screens. More variants. More concepts. More copy. More prototypes. More things to review, compare, tidy, rationalise and explain. For teams already drowning in product surface area, this is not an obvious win. It may simply create more design-shaped debt.

The danger is not that AI makes everything terrible. The danger is that it makes mediocrity faster and more convincing.

This is why execution quality does not become less important in an AI-heavy design process. If anything, the bar goes up. When anyone can generate something that looks good enough in a screenshot, the designer’s job shifts towards knowing what is actually good. Where the interaction is wrong. Where the flow hides a business problem. Where the visual polish is masking a weak product decision. Because AI is great at copying. But what it can't do yet is sit inside of the mind of an average user and experience an interface for the first time. 

That kind of judgment is (currently) hard to outsource.

The best designers I know were never just screen producers anyway. They were pattern spotters, translators, editors, product thinkers, quality filters and organisational irritants in the best sense of the word. They noticed when the team was solving the wrong problem. They spotted when a roadmap item was really a customer support issue, or when a requested feature was compensating for a broken onboarding flow. They knew when to make something, when to question it, and when to leave it alone.

AI does not make that less useful. It makes it easier to see who had it in the first place.

The problem is that many companies are still managing design as if the old model were intact.

The report suggests designers are already feeling rising expectations around speed, quality and output, while relatively few companies have updated evaluation, compensation, hiring or performance metrics to match. In plain English: people are being asked to work in a new way while still being judged by the old rules.

That rarely ends well.

It creates a familiar kind of organisational nonsense. Designers are expected to use AI to move faster, but there is no shared view of what “better” looks like. Leaders want more output, but have not decided how to measure quality. Teams encourage experimentation, but treat every mistake as evidence that the new tools are risky. Hiring managers say they want AI fluency, but are not sure whether that means prompting, prototyping, coding, systems thinking, taste, or simply having used whatever tool is currently trending.

So the learning is happening sideways.

One of the most telling findings in the report is that peer learning has more than tripled year over year, while designers taking recommendations from leadership has dropped sharply. That rings true. Most of the useful learning I see is happening in small groups, private Slacks, shared demos, messy experiments, whispered tool recommendations, internal hack days and “you need to see what I made this morning” conversations.

People are not waiting for an official playbook. They are trying to work it out from each other.

That is healthy, up to a point. Bottom-up experimentation is often where the best practice starts. But if leadership does not catch up, you end up with pockets of invention rather than organisational learning. One team quietly transforms how it works while another carries on producing static mockups and wondering why it feels slow. One designer builds internal tools that save days of effort while another is still asking permission to try Cursor. One manager encourages tinkering while another mistakes it for distraction. Like a flock of starlings, this can look like co-ordination from a distance, but up close it's just lots of people bashing into other people in slightly annoying ways. 

This is a big part of why I’m helping curate the new Design + AI summit. 

Not because I think the design industry needs another round of abstract predictions. Most designers have heard enough about AI being “the future” to last them several futures. What feels more useful now is a room full of practitioners, design leaders, product people and technologists comparing notes on what is actually changing.

How are teams using AI in real product development? What happens to the design process when prototypes become cheaper than decks? How do you critique work that came out of a prompt chain? How do you stop non-designers creating plausible but incoherent interfaces? What should sit in the design stack, and what should stay as an occasional experiment? How should design leaders hire, train and manage teams when expectations around speed and output have shifted but company processes have not?

These are not theoretical questions. They are showing up in product teams right now.

A PM generates a prototype before design has framed the problem. An engineer ships an interface that looks acceptable but quietly breaks the design system. A designer builds a working tool that changes the conversation with leadership because it feels less like a proposal and more like a product. A team suddenly has ten times more output and no better way to decide what deserves attention. A design leader is asked whether AI should make the team smaller, faster, more technical, more strategic, or all of the above.

Those are the conversations I want to have in the room.

Some design teams will respond to this moment by trying to protect the old boundaries. They will argue that design should remain the owner of design work, that PMs and engineers should stay in their lanes, that quality will suffer if everyone starts generating interfaces. They will be partly right. Quality probably will suffer in many places.

But “please stop using the new tools” is not going to be a durable position.

A better response is to become more fluent than the people moving into your territory. To understand the tools well enough to critique them. To use them well enough to know where they break. To develop new rituals around review, taste, prototyping, research and production. To help your organisation move faster without filling the product with plausible junk.

This is not about designers becoming prompt jockeys or junior full-stack developers. It is about design becoming less dependent on a narrow set of artefacts and more involved in the full act of making. That should be good news. It returns design to something closer to its real purpose: shaping what gets built, how it behaves and whether it deserves to exist.

But it does mean the comfortable version of the job is going away.

If your value as a designer is mainly that you can produce neat Figma files, the next few years may be rough. If your value is that you can understand people, frame problems, make judgment calls, explore possibilities, build enough to learn, and protect the quality of the experience as the organisation speeds up, this could be a very good moment.

The hard part is that nobody has the new playbook yet.

That is what makes this moment interesting. Also irritating. Also slightly exhausting. The tools are changing too quickly, the case studies are uneven, the incentives are confused, and the best examples are often hidden inside teams who are making it up as they go along.

So the choice is fairly simple. You can watch this happen through LinkedIn posts, product launches and second-hand takes. Or you can get in a room with people wrestling with the same questions and start forming your own view.

Design has been too settled for too long. The process is breaking open again.

I’d rather be part of the conversation while it is still being shaped.