Skip to content
Training course
Beginner to Intermediate Tailored to your team

Claude for Designers Training

A course for product and UX designers: using Claude for the parts of design work it genuinely helps with, from research synthesis through to engineering handoff, without letting it flatten your judgement.

Level
Beginner to Intermediate
Length
1 or 2 days
Delivery
On site, Remote, Hybrid
Group size
5 to 20 participants
See all courses

Booked privately for your team. Dates and length are agreed when you book.

What your team will be able to do

Every module ends with something participants can repeat on Monday morning, in your codebase and against your conventions.

Synthesise research faster

Get from forty interview transcripts to themes you can defend in an afternoon, with the quotes still attached to them.

Write the interface copy

Draft and iterate the words inside the product, which are usually the last thing anybody gets time for.

Explore more options

Produce five directions where there was time for two, and tell which of them are worth putting in front of anyone.

Keep the system honest

Work it against your design system rather than around it, so the output does not quietly fork your components.

Hand off cleanly

Turn a design into something an engineer can build from, including the states nobody remembered to draw.

Keep your own taste

Recognise the competent, average, forgettable answer, which is reliably the first one it will offer you.

Curriculum

Built around hands-on work rather than slides. The running order and the depth of each module are adjusted to the group before delivery.

75% hands-on
1

What it does for design work

From 1 day
  • Where it helps, where it wastes an afternoon, and how to tell which early
  • Giving it your product context once instead of re-explaining it every time
  • Working from research documents, specifications and screenshots
  • What it cannot see about your product, and what that does to the output
2

The design work itself

From 1 day
  • Interviews and survey data into themes you can defend to a stakeholder
  • Labels, empty states, errors, and the sentences nobody has time to write
  • Generating directions worth reviewing rather than twelve near-identical ones
  • Working inside your own components and tokens instead of inventing new ones
3

Getting it built

From 2 days
  • Standing up something clickable to test an interaction rather than describe it
  • Specifications that answer the questions engineers actually come back with
  • Design tokens, and the awkward gap between your file and the codebase
  • Asking what a change would cost to build before the review rather than after it
4

Judgement and critique

From 2 days
  • Reviewing generated work with the same eye you would use on a junior's
  • Why the first answer is always the average one, and what to do about that
  • Contrast, focus order, and the accessibility claims worth checking yourself
  • The parts of the work to keep entirely, and being able to say why

How long you book it for

Every length is drawn from the same modules. A longer booking is more of the course, not a different one.

Essentials

Beginner

1 day

A day on the design work Claude is genuinely good at, run against a project of your own rather than a tidy sample one.

Modules covered

  • What it does for design work
  • The design work itself

Core

Intermediate

2 days

Adds the handoff to engineering and the critical half of the job: what to reject, and how to keep the output looking like your product rather than everybody's.

Modules covered

  • What it does for design work
  • The design work itself
  • Getting it built
  • Judgement and critique

Not sure which one fits? The intake call settles it, and the length can still change afterwards.

Built around your team

No two runs of this course are the same

The curriculum above is a starting point, not a syllabus. Before anything is booked I find out where your team actually stands, then rebuild the course around that. A team already running agents daily spends its two days somewhere completely different from one that installed the tool last week.

  1. Step 1

    Intake call

    A call before anything is agreed: what your team already uses, what has gone wrong so far, and what you need them doing differently afterwards.

  2. Step 2

    Stack review

    Language, framework, review process, CI. Exercises are rebuilt against your repository so nothing in the room is hypothetical.

  3. Step 3

    Curriculum reshaped

    Modules get dropped, deepened or added. You see the adjusted outline and sign it off before the date is fixed.

  4. Step 4

    Delivery and follow-up

    We run the course, then check in once the team has applied it to real work and the awkward questions have surfaced.

What gets adjusted

  • Depth of each module
  • Your stack and repository
  • Group size and seniority mix
  • Length and how days are split
  • English or German
  • On site, remote or hybrid

Is this course right for your team?

Who it is for

Product and UX designers who suspect they should be using this and have been unconvinced by what they have seen so far.
User researchers sitting on more interview material than they will ever have time to read.
Design leads who need one shared answer for how their team uses AI, including where it does not.

What participants need beforehand

  • Daily work in a design tool; which one it is does not matter.
  • A laptop with your usual design setup already on it.
  • A real project in flight, ideally one with messy research sitting behind it.

How the training is delivered

Same material either way. The format changes how much of it lands in the first week.

On site

I come to your office and work with the team in the room. Usually the most effective option for a first rollout, because the sideways questions get answered as they come up.

Remote

Delivered live over video in focused blocks rather than one long day, with shared screens and hands-on exercises on your own work.

Hybrid

A day on site to get everyone moving, followed by shorter remote sessions once the team is applying it to real work and hitting real friction.

Optional add-ons Certificate of participation

There is no public schedule. Every course is booked privately for a single team, and we agree the dates together.

Luka Breitig, software engineer and AI coding trainer
Your trainer

Luka Breitig

Software engineer and AI coding trainer

I train engineering teams to work with AI coding tools, and I use the same tools to ship production software every week. The material comes out of building things, not out of a slide deck.

Before going freelance I spent six years as technical co-founder of a marketing agency, responsible for everything technical from automation infrastructure to coordinating a freelancer network. That is why the courses spend as much time on review, guardrails and rollout as they do on prompting.

  • Ships production software every week
  • Delivers in English and German
  • On site across Europe, or remote
  • Speaker at Nomad Summit, Chiang Mai

Trusted by teams & training providers

I deliver AI training for some of Europe's leading organisations and L&D platforms.

Cegos Integrata

Cegos Integrata

Commissioned trainer via leading European L&D provider

NobleProg

NobleProg

AI coding workshops via one of the world's largest IT training marketplaces

Innomotics

Innomotics

In-house AI training for engineering teams

Bots & People

Bots & People

Commissioned trainer for developer workshops

Code First Girls

Code First Girls

Course creator — 3-month AI & agentic tools curriculum

Nomad Summit

Nomad Summit

Conference speaker on AI tools, agentic development, and developer workflows (2025)

Vertiv

Vertiv

In-house AI-assisted coding training for engineering teams

Questions about this course

The things teams ask before booking. If yours is not here, ask me directly.

No. Most designers booking this have tried a chat window, been unimpressed and stopped. The day starts by showing why that experience is the normal one, and what changes once the tool has your actual project context in front of it.

Yes, as far as they genuinely work today, which is further than a year ago and not as far as the demonstrations suggest. The handoff module covers what really moves between a design file and a codebase and what still needs a person. Tell me your setup and I will tailor that part to it.

No, and I would not run it if it were. What it does is move the tedious half of the work, the transcripts and the empty-state copy, so that the judgement half gets more of the week. The critique module exists precisely because the tool has no taste and your team does.

It makes the course more useful rather than less. A design system gives the tool something concrete to work inside, which is the whole difference between output that fits your product and output that looks like a template. Send it over beforehand and the exercises get built around it.

Five to twenty. Design critique needs a room small enough that everybody's work gets looked at, and the second day is largely critique.

Yes, in German or English. This one is worth flagging separately: the interface copy exercises should be in whichever language your product ships in, so tell me which that is and we work in it regardless of the language the day itself is taught in.

Still not sure whether this is the right fit for your team?

Book this training for your team

Tell me the size of the group, the codebase they work in, and roughly when you want to run it. I will come back with a proposal.

Download trainer profile

Delivered in English or German, on site across Europe or remotely.