AI for product designers
Twelve short lessons, in order. Each is a few minutes and links to the workflow, prompt or check that puts it into practice.
What AI is actually useful for
Exhaustive, structured, checkable work. Not judgement.
- It is good at going through a list without getting bored: every step, every state, every rule.
- It is good at restructuring what you give it: notes into themes, decisions into a spec.
- It is weak at knowing your users, your constraints and what matters.
- It is confidently wrong about facts it cannot see, such as exact contrast or what a standard says.
Giving AI better context
Most weak answers come from a missing product, user or constraint.
- Say the product type, the user, the task, the platform and the design system.
- Paste the real thing: the actual steps, rules, tokens or notes.
- State what cannot change.
- Say what you want back, and in what shape.
Writing better design prompts
Ask for critique before solutions, and give it somewhere to put uncertainty.
- "Do not redesign yet" gets you analysis instead of a generic alternative.
- Ask it to type each finding: standard, system, convention, craft or preference.
- Give it an "open questions" or "verify" bucket, or it will fill gaps with invention.
- Skip "act as an expert". Specific context does more than a job title.
AI for UX research
Use it to organise what people said, never to say it for them.
- Good: critiquing a discussion guide, grouping notes, drafting a synthesis structure.
- Demand participant IDs and exact quotes for every theme.
- Check quotes against the source; paraphrase gets presented as quotation.
- Check your organisation's rules before uploading participant data.
AI for user flows
Draw the happy path yourself. Let AI find what breaks it.
- Ask for edge cases per step, by type: input, network, permissions, data size, going back.
- Ask for alternatives that are structurally different, with the trade-off of each.
- You set the priorities; its sense of "rare" is a guess.
AI for UI critique
Useful as a first reader, if you make it say what kind of claim each finding is.
- Give product type, user, task, viewport and design system.
- Have every finding typed, so opinion is not dressed as a rule.
- It cannot measure from a screenshot. Have it list what to measure.
- Look up any standard it cites before repeating it.
AI-assisted prototyping
Prototype to learn one thing. Say what it is before you start.
- Build one interaction or one task, not the product.
- Supply your tokens and components, or it will invent its own.
- Test by keyboard and at small widths; generated code often fails both.
- Label it a prototype. Working code gets mistaken for finished code.
AI and design systems
AI should follow the design system, not quietly create a second one.
- Good uses: mapping raw values to tokens, finding one-off styles, documenting component behaviour, generating variants from existing components.
- Common failures: new colours, random radii, duplicate components, arbitrary spacing, ignored type styles.
- Paste the tokens and component list into the prompt.
- Ask for a list of every token and component used. Anything unlisted is a deviation.
Generate UI that follows my systemSGDS token architectureDesign Tokens cheat sheet
Reviewing AI-generated UI
Generated UI fails in predictable ways. Check for those first.
- Too many containers: cards inside cards, everything boxed.
- No hierarchy: every block the same weight.
- Decoration standing in for content: gradients, badges, charts with no question to answer.
- Off-system values. Compare against your tokens.
AI accessibility limitations
It can explain the standard and spot the obvious. It cannot test.
- It cannot use a screen reader, a keyboard or a switch.
- It estimates contrast from images, often wrongly. Measure it.
- It sometimes cites criteria that do not exist or do not say what it claims.
- Use it to prepare for a real test, not to replace one.
Working with developers using AI
A coded prototype is a conversation starter with engineering, not a pull request.
- Ask what they would keep and what they would rewrite.
- Hand over documented behaviour and acceptance criteria, not only the prototype.
- Use their tool when the change belongs in their codebase.
- Agree what AI-generated design output needs reviewing before it is built.
Building your own AI-assisted workflow
Pick two stages where you lose time to tedium. Start there.
- Good first candidates: edge cases, missing states, error copy, behaviour documentation.
- Keep the prompts that worked, with what you had to correct.
- For every use, write down what you still check by hand.
- Review it every few months. The tools change faster than habits do.