AI Generates. UX Decides.

Field notes from two things I run: a community of designers, and AI workshops with the expert users we build for

Everyone on my team was already using AI. Quietly, ad hoc, each in their own way, with their own prompts and their own workarounds. The problem was that everyone was learning in isolation. We were all solving the same problems twice, and nobody’s hard-won trick ever travelled past their own screen. So I started a community. Every two weeks the designers get together and share what they are actually trying, what worked, and what broke.

Around the same time I was running a very different set of sessions: workshops where the actual expert users of one of our internal tools, people who live in that software all day, sat down to redesign its future with AI in the room, not as a bolt-on feature but as the product itself.

Two rooms, two very different groups, and the same thing kept surfacing in both. AI can generate more and more of the work, and yet the value keeps collapsing back onto the human: their judgement, and their skill in actually wielding the tool. AI generates, UX decides, and we are not there yet. Here is what each room taught me about where the craft is going.

Inside the studio: what changes for designers

The clearest change is that a designer can now go from an idea to working, production-quality UI without the traditional handover. An engineer on our team reused an AI-built component in under an hour, where the same handoff used to take three to five days. And these are not the flimsy click-throughs we are used to. The strongest prototypes run on real data and behave like an actual web app in testing. Not a dumb prototype, a real web app.

But here is the caveat I keep coming back to. This gets dramatically better if the designer can read code, and it stays shaky if they cannot. The AI does not write perfect code yet, so someone with a front-end background still has to verify what comes out. The subtle trap is the design system. Sometimes the AI genuinely wires up the real components, and sometimes it just makes the output look like them, and the only way to tell the difference is to read the code. That is why the designers with a coding background have had the smoothest handovers by far. They do not need a separate front-end engineer to check the work, so a vibe-coded interface becomes 70 to 90 per cent likely to survive into production. Maybe one day the AI is accurate enough that a designer just opens a merge request straight from a prototype. We are not there yet. For now the handover collapses fastest for the people who can check the machine’s work.

The flip side of designers doing more is that non-designers are doing more too. One designer described a pattern spreading through the industry: someone without design training builds a whole flow with AI, then asks a designer to “just tell us what’s wrong with this one screen,” with broader craft input ruled out of scope. The work then ships with an implied “design approved” stamp that no designer actually earned.

I think this is worth trying, and it is good that more people can make things. But experience has taught me something. Business stakeholders, and even some product owners, often do not fully understand the problem, and they underrate how much craft goes into UX. AI does not change that. It lets someone produce something that looks polished, and polished is not the same as usable, especially in B2B and enterprise tools where the context is deeply specialised and usable is the entire job. So the answer is not to gatekeep, it is to shape it together, with shared principles for everyone who now touches UX. And it cuts both ways. Designers are writing code now, so if we do not want developers stopping us from touching the front end, we should think twice before policing non-designers who touch UX. The honest position is collaboration, not territory.

Two smaller things the community keeps proving. First, speed is real but trust is the bottleneck. There is no agreed QA process for AI output, and accessibility gets ignored unless you explicitly ask for it, so you validate against a manual benchmark before you rely on it. Second, the people getting consistent results have stopped hoarding clever prompts and started saving them as small, documented skills for a specific job: kicking off a project, analysing a survey, drafting a handover. A one-off prompt helps you once. A shared skill helps the whole team every time.

Out in the wild: bringing users into the room

The second room was where I saw the craft change most, and not in the way I expected.

These were expert users of a dense internal tool. They know exactly what is wrong with the software they use all day, but they have almost never been able to show it. Somewhere between childhood and now, most people stop drawing. Ask them to sketch even a rough wireframe of what they want and they freeze, because they are sure they cannot express an idea visually. So for years the people who understand the real problem best have been the ones least able to put their idea in front of a designer. Their needs arrive second-hand, filtered through what business and tech assume they want.

Vibe coding broke that open. When a user can describe what they want in plain words and watch a rough, working version appear on the screen, the drawing barrier disappears. Suddenly the person who could never sketch is building, and pointing, and saying “no, not that, this.” It pulls them into the product development cycle at exactly the point they were always shut out of. And what comes out is the real signal: the handful of features they genuinely need, without the fluff that gets bolted on because someone upstream guessed. There is no better way to learn what matters to a user than to watch them build a crude version of it with their own hands.

I want to be honest about how uneven it was, because that unevenness turned out to be the lesson. We ran a handful of these workshops, thirty-six people in total, and their comfort with AI ranged enormously. Some were expert users who had never really used AI at all. One of them said, almost as a revelation, that they had not known you could ask AI to write a prompt that you then use with AI to do your work. By a later session, a different user was building their own small skills for the various things they do day to day. Same tool, same kind of room, wildly different distances travelled.

That gap is the point. Handing people AI does not do much on its own. The value only showed up once people were brought up to a level where they could actually wield it, and the distance between someone who has never asked AI for a prompt and someone authoring their own skills is enormous. Access is not adoption. If you want people to get anything real out of these tools, you have to close the skill gap, not just open the door.

What actually changed

Put the two rooms next to each other and the same shape appears. In the studio, AI can now generate a working interface, but it still takes a designer who can read the code to tell whether it is real or just looks real. In the workshops, AI can now help a user generate their idea, but it still takes judgement to know which of those ideas is worth building, and skill to get anything out of the tool in the first place. The generating is getting cheap. The deciding is not.

And I do not want to make it sound clean, because it is not. It is still a messy, human-run process. A real piece of work moves through a chain of tools, and a person has to carry it between them and tell each one what to do: analyse the research in one AI tool, wireframe from that by hand, prototype it in your design tool, hand it to a coding assistant to build, then push a branch to your repository. The tools change every few weeks, none of it is robust yet, and there is no single button that does the whole thing.

Which is the real point, and the reason I am not worried about the craft disappearing. The human is not being removed. The human is the one deciding what is worth building, whether to trust what the tool hands back, and which tool to reach for at which step. That takes judgement, and it takes skill, and right now the work only goes as well as the person driving it. AI generates. UX decides. We are not there yet, and the part that is not there yet is exactly the part that is ours.

AI Generates. UX Decides. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.