Guide

How do you upskill a UX team on AI?

To upskill a UX team on AI, treat AI like a keen junior designer. Give it the boring, well-defined jobs, check everything it hands back, and train your team on judgement before tools. The tools change every few months, but spotting bad output is a skill that lasts.

When my Faster Horses co-host Mark Sutcliffe and I brought the show back after a year off, AI was the first thing we wanted to talk about. LinkedIn couldn't shut up about it, and half the industry was quietly terrified of it. Mark had just counted nearly 8,000 tools on one AI directory, up from about 3,000 a couple of months earlier.

Since that episode I've built a fair bit with AI. There's an MCP server that feeds design system tokens to AI coding tools, and Claude skills that check live pages against Figma. I also built a pixel-art game for my own website in two and a half weeks. So this is what we said on the show, plus what I've learned since about getting a design team comfortable with it.

Why is AI really a UX problem?

Mark made the point that stuck with me most. Most of those thousands of AI tools are the same handful of large language models with a different interface on top. On its own, a raw model is so general that most people can't get anything useful out of it. Someone has to design the path through it.

I saw this first-hand with GhostPosts.ai, the start-up I co-founded. A friend showed me a rough prototype for writing better social posts. His problem with ChatGPT was that you already need to know the answer to get the answer. You generate something, rewrite it, rewrite it again, and eventually realise you could have written it yourself in less time. So we put it on rails. You pick your industry, your audience and what you want to achieve, add a couple of keywords, and the tool handles the blank page.

Designing that path is UX work. Once your team sees it that way, AI stops looking like a threat and starts looking like material to work with.

What should your team hand over to AI?

The jobs that are repetitive, well defined and easy to check:

First drafts of layouts, copy variations or the structure of a research report. A starting point, never the finished thing.
Diagrams nobody has time to draw. I've seen researchers use AI to sketch service blueprints that would otherwise take them three hours by hand.
Repetitive checking. In my own work, a Claude skill compares a live page against its Figma design at each screen size and writes up what's different. A person still reviews and signs off the report.
Busy work. Mark works in automation, and his view is that the real near-term win is taking menial tasks off people so they can spend their time on work that needs a human brain.

What should stay human?

The final read. Mark told us about one of the first students caught using AI at a UK university. They'd handed in an essay on leadership that cited a book of wizardry, and they clearly hadn't read it before submitting. Every bit of AI output needs a person who reads it properly before it goes anywhere.

Whatever makes you different. AI tends to produce the average of everything it's seen. I've always pushed back on teams using Material Design or IBM Carbon untouched, for the same reason. If every product used the same off-the-shelf look, we'd all be driving a Ford Focus.

Bias checks. Someone showed me an AI image generated from "hipster people pitching at Cannes". It got laughs for the extra fingers and the man with a woman's leg growing out of him. The bit that wasn't funny was that every person in it was white. Your team needs to be the ones who notice that, every time.

New ideas. AI is good at pulling existing pieces together. It's much weaker at looking at an old problem from a completely different angle, and that's most of what good design is.

How do you actually train the team?

This is the approach I use when I run AI sessions for design and product teams:

Start with judgement. Give the team some AI output and ask them to critique it against your design system and your research. That builds the habit of checking before trusting.
Write down the rules for the AI. I give it one task at a time, with a written brief it has to follow. For code, that means connecting AI tools to your real tokens and components so they stop inventing new ones.
Pair people up. Put someone confident with AI next to someone nervous about it, on a live piece of work. People learn far more from that than from a slide deck.
Agree what never goes into a public AI tool. Customer data and unreleased designs are the obvious two. Write the list down so nobody has to guess.
Review it every month. Tools change constantly, so keep a shared page of what worked and what didn't, and prune it as you go.

Will AI replace UX designers?

Not the ones who can design a way through it. Mark compared AI to a hammer: when you first get one, everything looks like a nail. Right now there isn't much nuance in how AI gets used beyond a bit of automation. The designers who'll do well can work out where it fits and where it doesn't, and explain that to the rest of the business.

Hollywood hasn't helped. Between Terminator and I, Robot, people expect either a robot uprising or nothing at all. The reality is far more ordinary: a useful, slightly daft tool that needs someone sensible in charge. Training people to be that someone is a leadership job, which I've written about in what good creative leadership looks like.

Want help getting your team there?

At Designed for Humans I run AI training and coaching for design and product teams, built around your own product rather than generic examples. If your problem is AI coding tools ignoring your design system, Design Systems for Humans has an MCP server that gives Cursor, Claude and VS Code your real tokens and components.

See how we can work together, or listen to the full episode, S5E1 of Faster Horses, on Spotify or Apple Podcasts.