AI Is Speeding Up Design Teams. Is the Work Getting Better?

91% of designers report that their work moves faster in AI-enabled environments, yet only 15% feel much more confident in what they ship. (UserTesting, 183 designers)

I have noticed a growing preoccupation with ways of working and efficiency since AI entered the design process. My concern is that we are neglecting the quality of the output, and the progress of that output, in favour of shipping as much as possible, as quickly as possible, rather than improving the UX and UI.

The tendency has built gradually, but a recent request from management made me ask whether it is becoming the norm. We were asked to review our ways of working, our Figma file structure and our team rituals. All of this is worth examining. My view is that it has been given too much weight, and that it should follow a prior set of questions: is what we create good enough, are we improving the product, and are we improving our skills?

How it shows up on my team

I see it in my own team and across the industry. It appears in project work, but more so in design operations and the side-of-desk work around it. Attention goes to accelerating a given step in the process rather than to critiquing the work or improving the product UI.

A current example is the push for designers to ship to code through GitHub or code layers in Figma. I find it useful, and I think it is a good idea. But the more important question is what we want to ship, not how we get it into code.

We have not adopted it yet, but considerable side-of-desk time is going into learning it, and it is presented as the ultimate goal: the assumption that if we can ship to code, our problems are solved. That may be true of some problems. Our job, however, is to solve the customer's problems. Given the choice, I would spend that learning time on critique and iteration of current work, conversations with customers and users, and review of the live product.

What designers themselves report

I am not the only one asking the question. The opening figures come from a UserTesting survey of 183 designers across the US, UK, France and Germany (see also the full report). Designlab's 2026 survey of over 200 UX and product designers found that more than half are concerned about the impact of AI on design quality.

The gap between speed and confidence names a feeling I had struggled to articulate. The Designlab result surprised me for a different reason: so many designers share the concern, yet nobody says it aloud at work. Speed is the dominant message from above, raising a quality concern can read as resistance to AI, and quality is harder to measure than speed, so it loses the argument. In my experience the concern is acknowledged politely and the plan proceeds unchanged.

What it costs a mid or senior designer

The first cost is that craft stops improving. Four things sustain it: critique, iteration time, time with the live product, and learning from one another. Each is being squeezed. The second cost is burnout and disengagement, which arrives as constant pressure to move faster.

The two I miss most are iteration time and learning from peers. Iteration time gave me room to examine what we create, to study other industries and learn from them, and to break the mould rather than produce what everyone else produces. Peer feedback stretched me. Early in my career I would arrive at one to three concepts and assume that was the limit of what I could think of for the work. A peer would ask a question or offer an idea, and it would open up another one to three concepts, and so on.

I also believe AI outputs converge, which is the opposite of breaking the mould. Products follow the same trends, portfolios resemble one another, and every product now has a chatbot, whether or not it helps.

My position on AI

I am not against AI. It is a useful tool pointed at the wrong goal. Speed is acceptable if it produces better work. Done well, it means more rounds of iteration, faster learning from real users, and less time on routine tasks, which leaves more time for craft.

Claude is excellent for building interactive prototypes of my ideas. Given full context, it prepares decks and clarifies questions well. It is a good assistant. The judgements I would not hand over are whether the work is good enough, what the customer needs, and which direction to take.

What to do on Monday morning

Ask "what are we shipping?" before discussing how it is built or shipped. Use the time that speed gains free up to buy iteration time, so that whatever a tool saves goes back into improving the work.

Good enough, to me, means three things: it solves the customer's problem, it feels considered in the live product, and it is something we have not seen before. When the conversation is dominated by how something ships, the question to ask is: "What are we shipping, and is it good enough?"

What I would ask of design leaders

Measure quality, not only throughput. Fund craft time explicitly. Stop treating process as the goal.

Faster is only worth it if the work gets better.