From Figma Designer to AI-Native Design Lead

A complete, practical, self-paced course

Version: October 2026. Tool features change fast. Concepts in this course are chosen because they are durable; tool-specific steps are flagged with 🔧 and should be re-checked against current docs.

Who this course is for

You are a UX/UI designer who is fluent in Figma. You are about to become (or have just become) a lead designer, and you will be expected to:

1. Lead the design practice: quality, critique, process, mentoring.
2. Lead AI tooling adoption for the design team, and influence how product and engineering use AI to make UI.
3. Build and run a design system that works for people and for AI agents.

You do not need to know how to code. You will touch code in this course, gently and with an AI agent doing the typing, because a modern design lead needs to understand the material that their designs become.

What you'll be able to do at the end

Course map

Total: about 80 hours. At 6–7 hours a week, that's 12 weeks. A suggested schedule is below.

Supporting material:

• 📁 templates/: ready-to-use files (context files, rules, policy, contract, checklists, logs).
• 📖 Glossary: every term used in the course, in plain language.
• 🔗 Resources: verified links, free and paid, used throughout.

How each module is built

Every module follows the same structure so you can study efficiently:

1. Learning objectives: what you'll be able to do afterwards.
2. Why this matters for a lead: the leadership angle, not just the craft angle.
3. Core concepts: explanations, with examples.
4. In practice: workflows, prompts and patterns you can copy.
5. Common mistakes: what goes wrong and how to avoid it.
6. Lab: hands-on exercises on your capstone project.
7. Deliverable: a concrete artifact that goes in your portfolio.
8. Self-check: questions with answers, to test your understanding.
9. Go deeper: curated reading and viewing.

The capstone project (runs through the whole course)

Learning sticks when it is applied to something real. Before you start Module 01, choose one product area to carry through every module.

Good capstone candidates

• A real feature area at your (future) company: settings, onboarding, a dashboard, search and filters, a checkout.
• A past portfolio project you'd like to redo properly.
• A small product idea of your own, ideally one with a complex interaction such as filters, a multi-step flow, or a data table.

Avoid anything with confidential data you're not allowed to put into AI tools. If it's a company project, use sanitised data. Module 13 covers data rules in detail.

By the end you will have:

1. A research-informed brief.
2. A tokenised, documented mini design system in Figma.
3. Machine-readable context: DESIGN.md, UX.md and agent rules.
4. A tested, interactive AI prototype.
5. A coded screen built by an agent from your Figma file, plus a drift log.
6. A designer–developer collaboration contract.
7. An AI policy and adoption playbook for a design team.
8. A 90-day plan and a leadership presentation.

That's a complete, very strong portfolio case study for a lead role.

Tool setup (do this in week 1)

Free tiers are enough for almost everything. You need one tool from each row.

🔧 For Module 10 you'll connect the Figma MCP server to your coding agent. The remote server is at https://mcp.figma.com/mcp, and setup instructions are in Figma's MCP docs. Writing to the canvas requires the remote server and a Full seat for files outside your drafts.

Data rule from day one: never paste confidential customer data, unreleased financials, credentials or personal data into an AI tool your company hasn't approved. When in doubt, sanitise or invent realistic fake data.

Suggested 12-week schedule

Weekly rhythm

• Monday: read the module (1–2 h).
• Tuesday to Thursday: labs (3–4 h).
• Friday: update your AI log, write a 5-line reflection, and share one learning with a colleague or publicly. Teaching is the fastest way to consolidate what you've learned, and it builds your reputation as a lead.

How to assess yourself

At the end, score yourself 1–4 on each row. Aim for at least 3 everywhere before calling yourself AI-native.

A note on "best practice" in a fast-moving field

You asked to learn only what is actually best practice and likely to stay. This course separates the two kinds of knowledge:

• Durable (learn deeply): how LLMs behave, verification habits, context engineering, design tokens and systems, real-user research, design–dev contracts, change leadership. These were true in 2024, are true now, and will very likely be true in 2028.
• Volatile (learn just in time): specific tool UIs, menu names, pricing, which model is best this month. These are marked 🔧. Learn them when you need them, from the official docs.

When a tool changes, you'll still know why you're doing what you're doing. That understanding is what separates a lead from a tool operator.

Start here → Module 01: The Shift

Module 01: The Shift, what changed and what will last

Time: about 3 hours · Output: your personal AI baseline and a capstone choice

Learning objectives

By the end of this module you will be able to:

• Describe, with evidence, how UX practitioners actually use AI today, not how marketing says they do.
• Separate durable changes in design work from hype and churn.
• Explain the new shape of the designer's role and of the lead designer's role.
• Start an AI log, the habit that powers the rest of the course.

Why this matters for a lead

Your team, your PMs and your executives will all have strong opinions about AI. Some will push mandates ("use AI for everything"), others will resist ("it's all slop"). A lead's first job is to replace opinions with evidence: what AI actually does well in your context, what it costs, and what it risks. This module gives you the baseline.

1. What the evidence says (2026)

In October 2026, Nielsen Norman Group published a survey of 521 UX practitioners about AI at work (source). Key findings:

Also from the survey:

• AI is used most for desk work (writing, coding, desk research) and least when real users are involved.
• Designers and researchers felt less job-secure than PMs.
• Leadership pressure was common. Lack of executive buy-in was the least chosen barrier (6%). The problem is often too much push, not too little.

What this means for you:

1. AI is already normal. You're not early, and you're not late either, because quality and integration are still unsolved.
2. Output quality and data privacy are the real blockers. A lead who solves those (through context, systems, review gates and policy) creates real value.
3. Many people feel ambivalent. Change management (Module 13) is as important as tooling.

2. What changed, and what didn't

Things that have genuinely changed (durable)

1. Producing artifacts is cheap. Screens, copy, variations, prototypes and even working code can be generated in minutes. The bottleneck has moved from making to deciding, evaluating and integrating.
2. Interactive prototypes are cheap. Complex interactions that used to wait for engineering (filters, dashboards, conversational UI) can now be tested with real users early (NN/G).
3. Everyone can make UI. PMs generate mockups and engineers' coding agents choose button labels and error states. Design decisions are being made by AI on behalf of non-designers (NN/G: UX-context design).
4. The audience for design deliverables now includes machines. Personas and specs were written for humans. Now AI tools also "read" your design system, your rules and your research. Context has become a deliverable.
5. Design and code are converging. With the Figma MCP server, agents can read your design (components, variables, layout) to write code. They can also write back into Figma using your components, or capture live UI from a browser into Figma layers (Figma docs).
6. Design systems moved from nice to have to critical infrastructure. AI multiplies whatever system it's given. A clean system yields consistent output at speed, and a messy one yields inconsistent output at speed.

Things that have not changed (and matter more now)

1. You are not the user. Real users still surprise you, and AI-simulated users are narrower than real ones (more in Module 04).
2. Good design is judgment. Choosing which of 30 variants is right, and why, is the job.
3. Usability fundamentals. Heuristics, accessibility, information architecture and content clarity still apply.
4. Collaboration and trust. Products are still built by teams. Alignment, rationale and shared standards still decide success.
5. Accountability. Someone human signs off. "The AI did it" is not an answer to a broken checkout or an inaccessible form.

Hype to be sceptical of

3. The new shape of the role

The designer's work: from making to directing and judging

Think of a designer's time as split between four activities:

          BEFORE AI                         AI-NATIVE
  ┌───────────────────────┐       ┌───────────────────────┐
  │ Understanding  20%     │       │ Understanding  25%     │  ← research, framing
  │ Making         55%     │  →    │ Making         20%     │  ← AI drafts, you refine
  │ Evaluating     15%     │       │ Evaluating     30%     │  ← critique, testing, QA
  │ Systematising  10%     │       │ Systematising  25%     │  ← systems + context
  └───────────────────────┘       └───────────────────────┘

These proportions are illustrative, not measured, but the direction of the shift is consistent across sources.

The AI-native designer's core loop

 Frame → Generate → Evaluate → Refine → Validate (with users) → Systematise
   ↑                                                                │
   └──────────── what you learned goes back into context ───────────┘

The last step is the new one. What you learn becomes context (rules, components, research insights), so the next generation of output starts better.

The lead designer's expanded scope

As a lead in the AI era, you own (or co-own):

1. Quality bar: what "good" means, and the review gates that protect it.
2. Workflow: where AI fits in your team's process, and where it doesn't.
3. Design system: the shared infrastructure for humans and agents.
4. Context library: the research, standards and rules that steer every AI tool in the org.
5. Tooling and policy: approved tools, data rules, disclosure.
6. People: skills development, psychological safety, and fair expectations around speed.

4. The capability spectrum

You don't need to become an engineer. But you should know where you sit on this spectrum and where you want to be.

A design lead should aim for level 4 competence and level 5 ownership. You don't have to do level 4 work daily, but you must be able to do it, so that you can judge it and lead it.

Common mistakes at this stage

• Tool-hopping. Trying every new tool weekly. Pick one per category and go deep.
• Measuring nothing. "It feels faster" is not evidence. Start the AI log today.
• All or nothing. Either refusing AI or using it for everything. The skill is selective use.
• Skipping fundamentals. AI amplifies skill. Weak fundamentals plus AI gives confident bad work.

Lab 01

Exercise 1: Tool setup (30 min). Set up the tools from the Start Here table. Don't configure MCP yet.

Exercise 2: Your AI baseline (30 min). Answer honestly in a doc:

1. Which design tasks do I spend the most time on each week?
2. Which have I tried with AI? What happened?
3. Where on the capability spectrum am I today (0–5)?
4. What am I most sceptical about? What am I most excited about?

Exercise 3: Start your AI log (ongoing). Copy templates/ai-log.md. For every AI use over the next 12 weeks, log the task, tool, time spent, time saved or lost, quality (1–5) and what you'd do differently. It takes 30 seconds per entry and gives you the evidence base for Module 13.

Exercise 4: Choose your capstone (30 min). Use the criteria in Start Here. Write one paragraph: product area, users, why it's interesting, and any data constraints.

Exercise 5: Read and reflect (60 min). Read the full NN/G 2026 survey and browse its interactive comments dashboard. Write down three quotes that match your experience and one that surprises you.

Deliverable

A one-page "My AI baseline" document covering capability level, top tasks, hopes, fears and capstone choice, plus an AI log with your first entries.

Self-check

1. What were the two biggest barriers to AI adoption in the 2026 NN/G survey?
2. Name three durable changes and three things that haven't changed.
3. Why is "context engineering" considered more important than "prompt engineering"?
4. What's the new final step in the AI-native designer's loop?
5. What capability level should a lead aim for, and why?

Go deeper

• NN/G: AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings
• NN/G: UX-Context Design
• NN/G: AI topic hub

Next → Module 02: How AI actually works

Module 02: How AI actually works (for designers)

Time: about 4 hours · Output: a one-page "AI mental model" cheat sheet in your own words

Learning objectives

• Explain in plain language what a large language model (LLM) does, and why that explains both its strengths and its failures.
• Understand tokens, context windows, non-determinism, hallucination, sycophancy and mode collapse, and what each means for design work.
• Distinguish between a chatbot, an AI feature in a tool, an AI agent, and the plumbing that connects them (tools, MCP, skills).
• Predict before you try it whether a task is a good fit for AI.

Why this matters for a lead

You'll be asked "Can AI do X?" constantly. Without a mental model, you'll answer from hype or fear. With one, you can say "Yes for drafts, no for final decisions, and here's the review step." That's the difference between a tool enthusiast and a trusted lead.

1. The core idea: prediction from patterns

An LLM is trained on enormous amounts of text (and, for multimodal models, images, audio and code) to do one thing extremely well: predict a plausible continuation of what it has been given.

Everything else (answering questions, writing code, critiquing a design) is built on top of that ability, plus additional training to make it helpful, follow instructions and avoid harm.

Three consequences that matter to designers:

1. It produces the plausible, not the true. Usually plausible and true overlap. When they don't, you get confident errors. NN/G's explainer on how generative AI works is a good non-technical read.
2. It gravitates to the average. Ask for "a search screen" and you get the most typical search screen in its training data. NN/G puts it this way: "It knows what software generally looks like. It doesn't know your users" (source). Context is how you move it off the average, which is the subject of Module 09.
3. It has no memory of you by default. Each conversation starts fresh unless the product adds memory, files or connections. What it "knows" about your project is only what's in its current context.

2. Key concepts in plain language

Tokens

Models read and write in tokens, chunks of roughly ¾ of an English word. Pricing, speed and limits are measured in tokens. Images also consume tokens.

Design implication: long files, huge Figma frames and big screenshots can use up a lot of the model's capacity. That's why Figma's MCP rules suggest fetching a metadata map first, then only the nodes you need (Figma custom rules).

Context window

The context window is everything the model can "see" at once: your prompt, the conversation so far, attached files, tool results and system instructions. It's large in modern models (often hundreds of thousands of tokens) but not infinite, and quality can degrade when it's stuffed with irrelevant material.

Design implication: more context isn't always better. Relevant context is better. NN/G's lesson 4 on context libraries is to give agents only the context they need (source).

Non-determinism (temperature)

The same prompt can give different outputs, because models sample from probabilities. Some tools let you control randomness ("temperature"); most hide it.

Design implication:

• Good for ideation: run it again for more variety.
• Bad for consistency: two people asking for "a settings page" get two different settings pages. Systems and rules create consistency, not prompts.
• For testing AI features, you must test the range of outputs, not one happy path.

Hallucination

The model states something false with confidence, such as an invented statistic, a non-existent API or a fake citation. It happens because it generates plausible text, not verified facts. Hallucination has been reduced but not eliminated, and NN/G explains why it's hard to remove.

Design implication: verify facts, numbers, quotes, citations and accessibility claims. When AI says "this passes WCAG AA", check it with a real contrast tool.

Sycophancy

Models are trained to be helpful and liked, so they tend to agree with you and praise your work (NN/G).

Design implication: "What do you think of my design?" invites flattery. Ask instead: "List the five most serious usability problems, ranked by severity, with the heuristic each violates." Module 03 covers critique prompts.

Mode collapse (narrowness)

Generated outputs cluster around a narrow set of typical answers. NN/G compared 120 synthetic respondents with 604 humans. Both pointed to the same broad conclusion, but the synthetic answers used a much narrower range of responses (source).

Design implication: AI is a weak substitute for real user diversity and for genuine creative divergence. Push for variety explicitly and still test with real people.

Multimodality

Modern models can take images, screenshots, PDFs and sometimes audio or video as input, and generate images. They can "see" your screen and critique it.

Design implication: screenshot critique, layout-to-code and moodboard generation all work. Image understanding is good but can miss fine details like 1px misalignments or subtle contrast issues. Use real tools for precision checks.

Knowledge cut-off

Models are trained up to a date. Without web access they may not know recent tools, guidelines or your competitors' latest releases.

Design implication: for anything current, use a tool with web search and check the sources.

3. From chatbots to agents: the building blocks

What makes an agent different

A chatbot gives you an answer. An agent pursues a goal:

Goal: "Implement this Figma frame using our design system"
  1. Read the design context (via MCP)
  2. Look at the screenshot
  3. Find matching components in the codebase
  4. Write the code
  5. Run it and see errors
  6. Fix the errors
  7. Compare with the screenshot
  8. Report back

Agents are powerful because they iterate, and risky because they act: they can change files, send things and spend money. That's why governance matters, meaning what an agent may do without approval (Module 13).

Why MCP matters to you

Before MCP, every AI tool needed a custom integration for every app. MCP standardises that, which is why a single Figma MCP server works with many clients, including Claude Code, Codex, Copilot, Cursor and VS Code (Figma's client list).

As a design lead, the Figma MCP server is the bridge between your design system and every coding agent in your company. What you put in Figma (component names, variables, descriptions, Code Connect mappings) directly becomes what agents see.

4. Will AI help with this task? A quick heuristic

Score the task on four questions:

• Four favourable answers: delegate the draft and review it.
• Mixed: use AI as an assistant, with heavy review.
• Mostly unfavourable: do it yourself, and maybe use AI to critique your work afterwards.

Examples

• Generate 10 microcopy variants for an empty state → ✅ delegate.
• Summarise 12 interview transcripts → ⚠️ assist. Verify quotes and watch for over-focus on the wrong theme.
• Decide the information architecture for a medical dosing tool → ❌ do it yourself, with domain experts and users.

Common mistakes

• Treating AI output as fact. Verify claims, numbers and citations.
• Asking for validation instead of critique. You'll get flattery.
• Expecting consistency from prompts alone. Consistency comes from systems, rules and components.
• Overloading context. Dumping every file in degrades quality. Curate.
• Anthropomorphising. "It understands our users" is wrong. It has text about your users if you gave it some.

Lab 02

Exercise 1: Observe non-determinism (20 min). Ask the same assistant the same prompt three times in fresh chats: "Design the information hierarchy for a mobile banking home screen. List sections in order with a one-line rationale." Compare the results. What stayed the same (the "average") and what varied?

Exercise 2: Provoke sycophancy, then fix it (30 min). Upload a screenshot of one of your designs.

• Prompt A: "What do you think of my design?"
• Prompt B: "You are a strict senior design reviewer. List the 7 most severe usability problems in this screen, ranked by severity (critical/major/minor), each mapped to a Nielsen heuristic, with a concrete fix. Do not include praise."

Compare the two responses. Log both.

Exercise 3: Catch a hallucination (30 min). Ask: "Give me 5 statistics with sources about how users interact with onboarding flows in fintech apps." Check every source. How many exist and say what was claimed? Write down what you found.

Exercise 4: Multimodal limits (20 min). Take one screen, introduce three subtle issues (a 2px misalignment, a 3.5:1 contrast text, one inconsistent corner radius) and ask the AI to find "all visual inconsistencies". Which did it catch?

Exercise 5: Apply the heuristic (30 min). List 10 recurring tasks from your work. Score each with the four questions above and label it delegate, assist or do myself. This becomes the first draft of your team's AI workflow map (Module 13).

Exercise 6: Read (60 min)

• NN/G: How AI Works study guide: glossary, How Generative AI Works, Hallucinations, Sycophancy.
• Claude Academy: Introduction to Model Context Protocol (about 1 h, free).

Deliverable

An AI mental model cheat sheet (one page) in your own words, covering the eight concepts above. For each, add one line on "what it means for design work", plus your 10-task delegate/assist/do-myself map.

Self-check

1. Why does an LLM tend to produce an "average" design, and what's the main lever to change that?
2. Two designers prompt "a settings page" and get different results. Why, and how do you get consistency?
3. Rewrite "Is my design good?" as a prompt that resists sycophancy.
4. What's the difference between a chatbot and an agent?
5. What is MCP, and why does the Figma MCP server matter to a design lead?
6. What did NN/G's synthetic-user study reveal about synthetic respondents?

Go deeper

• NN/G: Artificial Intelligence: Glossary
• NN/G: AI: First New UI Paradigm in 60 Years (intent-based interaction)
• Model Context Protocol introduction
• Figma: What is MCP? (Resource Library)

Next → Module 03: Working with AI

Module 03: Working with AI, prompting, critique and verification

Time: about 5 hours · Output: your personal prompt library and a verification protocol

Learning objectives

• Write prompts using a reliable structure, not clever tricks.
• Use AI as a critic, not just a generator, without getting flattered.
• Run a diverge → converge loop with AI that produces genuine variety.
• Apply a verification protocol proportional to risk.
• Build a reusable prompt library for yourself and, later, your team.

Why this matters for a lead

You'll review a lot of AI-assisted work from your team, from PMs and from engineers. You need a shared vocabulary for good AI use ("did you verify that?", "what context did you give it?") and reusable assets (prompts, checklists) that raise the floor for everyone.

1. Prompting fundamentals that last

Prompting tricks come and go with each model generation. These fundamentals don't, because they're about communicating a task clearly, as you would to a capable new colleague.

The 6-part prompt structure

You don't need all six every time. But when output disappoints, one of these six is usually missing, most often context or constraints.

Other durable habits

• Show, don't just tell. One good example beats a paragraph of description. Paste an existing screen, copy sample or component.
• Ask it to ask. "Before you start, ask me up to 5 questions that would most improve the result."
• Iterate in the same thread. Refine with feedback ("make 3 bolder, drop the playful ones") instead of starting over.
• Break big tasks down. Brief → structure → content → visual, not "design the whole app".
• Name things precisely. "Use the Button/Primary component" beats "a nice button".
• Dictate when it's faster. NN/G found power users casually dictate prompts and invest their effort in context instead (source).

2. Diverge → converge with AI

AI is excellent at divergence (volume and variety) if you push against its pull toward the average. You stay in charge of convergence: choosing, combining and justifying.

Forcing real divergence

Bad: "Give me 10 ideas for onboarding." You'll get 10 variations of the same carousel.

Better:

Give me 10 onboarding concepts for [product], each built on a DIFFERENT
underlying strategy. Use these lenses, one per concept:
1. Zero onboarding (learn by doing)
2. Progressive disclosure over the first week
3. Template-first
4. Concierge / human-assisted
5. Import-first (bring your data)
6. Goal-setting first
7. Social / team invite first
8. Interactive tutorial with real data
9. Contextual tips only
10. Something from a non-software domain (e.g., games, hospitality)
For each: one-sentence concept, who it's best for, biggest risk.

Other divergence levers

• "Assume the opposite of our current approach."
• "How would [Stripe / Duolingo / a hospital / an airline cockpit] solve this?"
• "Give 5 options a conservative enterprise team would ship, and 5 a bold startup would."
• Ask for extremes ("most minimal", "most guided") to map the solution space.

Converging, which is your job

1. Kill fast. Cut obviously weak options and note why in one line each. Your reasons are your design judgment, and writing them down trains it.
2. Cluster. Group the survivors by strategy.
3. Evaluate against the brief. User goals, business goals, constraints, risks.
4. Combine. The best concept is often a hybrid.
5. Decide and document. One paragraph of rationale. This becomes context later.

3. AI as critic

Generation is the obvious use. Critique is the underrated one. A good critique prompt gives you a fast, tireless "second pair of eyes", provided you defend against sycophancy.

Critique prompt patterns

Heuristic evaluation

You are a strict senior UX reviewer. Evaluate the attached screen against
Nielsen's 10 usability heuristics. For each problem:
- Severity: critical / major / minor
- Heuristic violated
- Exact location on screen
- Why it matters for [user type] doing [task]
- Concrete fix
List at most 10, ranked by severity. No praise. If you're unsure, say so.

Persona walk-through (a cognitive-walkthrough style)

Walk through this flow as [specific user: e.g., "a first-time admin at a
50-person company who has 10 minutes between meetings"]. At each step say:
what they're trying to do, what they see, what they'd likely do next, and
where they might hesitate or fail.

Red team

Argue AGAINST this design decision as convincingly as possible: [decision].
What would a sceptical engineer, a sceptical PM, and a frustrated user say?

Consistency check

Compare these 4 screens. List every inconsistency in spacing, type styles,
component usage, terminology, and interaction patterns.

Accessibility pre-check

Review this screen for likely WCAG 2.2 AA issues: contrast, target size,
focus order, labels, reliance on colour, motion. Mark each as "likely" or
"needs tool verification".

Rules for using AI critique

• Treat it as hypotheses, not verdicts. Some findings will be wrong, generic or irrelevant.
• Triage: accept, reject (and say why), or "needs testing with users".
• Precision checks need real tools. Measure contrast with a contrast checker and accessibility with a proper audit tool and manual testing.
• Compare with your own review first. Do your critique, then ask AI. The gaps on both sides are where you learn.

4. Verification: a protocol proportional to risk

Not everything needs the same scrutiny. Use risk tiers:

The "verify 3" habit: for any AI research or summary, pick the 3 claims your decision depends on most and check them against the primary source. If any are wrong, distrust the rest and redo it.

Red flags that need extra checking

• Specific numbers, percentages or dates
• Named sources, studies, quotes or URLs
• "Best practice says..." with no source
• Accessibility or legal compliance claims
• Anything that conveniently confirms what you hoped

5. Your prompt library

Prompts you reuse are assets. Store them, version them, share them.

Format for each entry

## [Name] – [when to use]
Tier: low / medium / high
Inputs needed: [screenshot, brief, persona...]
Prompt:
  ...
Known weaknesses:
  ...
Last improved: [date] – [what changed]

A starter library is in templates/prompt-library.md. Over the course, you'll grow it to 15–25 prompts. In Module 13 it becomes a team asset.

Evolution path: a prompt you use often should graduate into a context file, rule or skill, so that it's applied automatically instead of pasted in each time. That's the step from prompting to context engineering (Module 09).

Common mistakes

• Prompting like a search engine: three keywords and no context.
• Accepting the first output. The first answer is the most average one.
• Long chats that drift. After many turns, models can lose earlier constraints. Restate key constraints or start fresh with a summary.
• Asking for opinions instead of structured critique.
• No verification on medium and high tiers.

Lab 03

Exercise 1: Prompt anatomy (45 min). Take a real task (microcopy, a flow description, a design rationale). Write a one-line prompt and run it. Then write the full 6-part prompt and run it. Compare the two and note which of the six parts made the biggest difference.

Exercise 2: Diverge and converge (60 min). On your capstone, generate 10 strategically different concepts using the lens technique. Kill 7 with one-line reasons, cluster the remaining 3, and write a one-paragraph decision.

Exercise 3: Critique duel (60 min). Do your own heuristic evaluation of one capstone screen (or a current product screen). Then run the AI heuristic prompt. Make a table with three columns: found by both, found only by me, found only by AI. Triage the AI-only items as accept, reject or test.

Exercise 4: Verification drill (30 min). Ask AI for a competitive scan of 4 competitors for your capstone area. Apply "verify 3". Log what you found.

Exercise 5: Build your library (45 min). Save your 5 best prompts from this week in the library format.

Deliverable

1. Prompt library v1 with at least 5 entries.
2. Critique duel table with a one-paragraph reflection on where AI critique adds value and where it doesn't.
3. Your verification protocol (adapt the tiers to your context).

Self-check

1. Name the six parts of the prompt structure. Which is most often missing?
2. How do you force genuine divergence instead of 10 variations of the average?
3. Why should you do your own critique before asking AI?
4. What is the "verify 3" habit?
5. When should a prompt graduate into a rule, context file or skill?

Go deeper

• NN/G: Careful prompts and the AI study guides
• Claude Academy: AI Fluency for creative work (free; the 4D framework is useful vocabulary for team policy)
• NN/G: Heuristic evaluation (a refresher on the human method you're augmenting)

Next → Module 04: AI across the design process

Module 04: AI across the design process

Time: about 6 hours · Output: a research-informed capstone brief, plus your stage-by-stage AI workflow map

Learning objectives

• Apply AI appropriately at each stage of the design process: discover, define, ideate, design, validate, deliver.
• Know where AI is strong, where it's risky, and where it should not replace human work.
• Use AI for research support without corrupting your research.
• Use AI for content and UX writing, visual exploration, and documentation.
• Produce a capstone brief using an AI-assisted but human-led process.

Why this matters for a lead

You'll define the team's workflow. A lead who knows exactly where AI helps (and where it hurts) at each stage can write guidance that speeds the team up without lowering quality, and can push back credibly on "just use AI for research".

The map: AI by stage

This matches how practitioners actually work. NN/G's 2026 survey found AI is used most for desk-based work and least for work with users (source).

Stage 1: Discover

Desk research

AI (ideally with web search) is very good at fast orientation: "What are the main regulatory constraints for X?", "How do the top 6 competitors handle onboarding?", "Explain the workflow of a warehouse dispatcher."

Do:

• Ask for sources and open them.
• Ask for uncertainty: "What are you least sure about?"
• Use the output as a map of what to verify and whom to ask, not as findings.

Prompt: domain primer

I'm a product designer new to [domain]. Give me a primer:
1) key roles and their goals, 2) typical workflows, 3) jargon (glossary),
4) regulations/constraints, 5) common pain points reported publicly,
6) 10 questions I should ask domain experts.
Cite sources where possible and mark anything uncertain.

Planning research with AI

AI is a solid assistant for drafting interview guides, screeners and survey questions. It's also good at reviewing them for leading questions, double-barrelled questions and jargon.

Review this interview guide for: leading questions, double-barrelled
questions, jargon, missing probes, and questions that ask users to predict
future behaviour. Suggest rewrites.

Synthesis: powerful, but handle with care

AI can transcribe, summarise and cluster interview notes fast. The risks:

• Over-focus or wrong focus. NN/G notes that AI given raw transcripts may "over-focus on the wrong takeaway" or lose important points in the noise (source).
• Invented or merged quotes. Always trace quotes back to the transcript.
• Flattened nuance. Minority but critical findings (such as an accessibility blocker for a few users) get averaged away.
• Privacy. Transcripts often contain personal data. Use approved tools only, and anonymise.

A safe synthesis workflow

1. You read or skim all the raw material first, or at least a substantial sample, and note your top impressions.
2. AI produces a first-pass clustering with quotes and transcript references.
3. You check the references, merge, split and rename themes.
4. You ask AI: "What evidence contradicts theme X?" and "Which participants don't fit any theme?"
5. You write the final insights. AI can help phrase them, but the claims are yours.

Synthetic users: what they are and aren't good for

"Synthetic users" are AI-generated stand-ins for research participants. NN/G's 2026 comparison (120 synthetic vs 604 human respondents) found they reached the same broad conclusion but with far less variety, plus methodological problems such as the platform rewording questions (source).

As a lead, put this in your team's AI policy (Module 13).

Stage 2: Define

AI helps you articulate and stress-test problem framings.

• Turn messy notes into 5 alternative problem statements, then pick one.
• Generate assumption maps: "List assumptions behind this solution, rated by risk and evidence."
• Write jobs to be done: "Rewrite these needs as JTBD statements: When [situation], I want to [motivation], so I can [outcome]."
• Pre-mortem: "It's 6 months after launch and this failed. Write the 8 most likely reasons."

Deciding which problem matters is a strategic, political and ethical choice. That stays with you and the team.

Stage 3: Ideate

Covered in depth in Module 03 (diverge → converge). Additional ideation uses:

• User flows: "Draft 3 alternative flows for X: minimal steps, maximum guidance, and expert mode."
• Information architecture: "Propose 3 navigation structures for these 40 features; for each, name the organising principle."
• Analogies: "How do airlines, hospitals and games handle 'something went wrong, here's what to do next'?"
• Sketch to wireframe: photograph a paper sketch and ask the Figma agent, Make or an AI prototyping tool to turn it into a wireframe for discussion.

Stage 4: Design

Content and UX writing (one of the highest-value uses)

AI is excellent for drafting and varying copy, once you give it a voice and a terminology.

• Empty states, errors, confirmations, onboarding, tooltips, notifications
• Terminology consistency: "Here's our glossary; flag any text that uses non-preferred terms."
• Localisation drafts: first-pass translations, plus checks for text expansion (German often runs about 30% longer, so test your layouts). Use professional review for production.
• Readability: "Rewrite at a plain-language level; keep all meaning; show the changes."

Prompt: error message system

Our voice: calm, direct, no blame, no exclamation marks, no jargon.
Our glossary: [paste]. Error message structure: what happened + why
(if useful) + what to do next.
Write messages for these 12 error cases: [list]. Return a table:
case / message / action label / notes. Flag any case where you'd need more
information to write a good message.

Visual exploration

• Moodboards and direction: image generation for mood, illustration directions and photography style references. Watch out for licensing and brand rules, and don't ship generated imagery without checking your company's policy.
• Layout variants: the Figma agent and Make can produce variants quickly. Use them for exploration, then rebuild or refine with your system.
• Placeholder and realistic data: "Generate 30 realistic but fictional invoices with edge cases: long names, zero amounts, overdue, foreign currency." Realistic data makes reviews and tests far better.
• States: "List every state this component needs: empty, loading, partial, error, success, disabled, long content, permission-denied..." AI is good at completeness checks.

Brand-defining work

Core identity, signature interactions, and the "feel" of a product are where AI's pull toward the average hurts most. Use it to explore, but the defining choices should be deliberate human decisions, captured afterwards as context (DESIGN.md, Module 08).

Stage 5: Validate

• Test planning: draft tasks and scenarios, then check them for bias and leading wording.
• Pilot-test the script with synthetic users or colleagues.
• Note-taking and transcription during sessions, with participant consent and approved tools.
• First-pass analysis: cluster observations. You interpret.
• Heuristic pre-check before testing, to catch obvious issues cheaply so that tests find deeper ones.

Never replace testing with real users. The whole value of testing is in what you didn't predict, and AI predicts the predictable.

Stage 6: Deliver

• Specs and annotations: AI drafts behaviour specs from your frames ("Describe all interactions and states for this component"). You correct them.
• Documentation: component usage guidelines, do's and don'ts, changelogs.
• Handoff becomes context: in Modules 08–10, handoff turns into machine-readable context and agent-built code.

Disclosure: when to say AI was involved

As AI-generated content increases, so do disclosure questions, and the EU's transparency obligations started applying in August 2026, as NN/G notes (source). NN/G's PACED framework helps decide when to disclose:

• Policy: is it required by law, your organisation or the platform?
• Audience: how does your audience view AI?
• Context: how much does human contribution matter here?
• Expectations: would people feel misled if they found out later?
• Degree: how much did AI actually contribute?

This applies to user-facing content and to internal deliverables, such as a research report that was largely AI-synthesised.

Common mistakes

• Letting AI do the research. It can support research, but it can't meet your users.
• Untraceable synthesis. Insights with no link to evidence.
• Shipping generic copy. No voice and no glossary give you generic output.
• Generating visuals you can't legally use.
• Skipping states. AI makes it easy to check for completeness, so use it.

Lab 04

Exercise 1: Domain primer (45 min). Run the domain-primer prompt for your capstone. Verify 3 claims. List the 10 expert questions.

Exercise 2: Real research, AI-assisted (2–3 h). Talk to at least 3 real people who match your capstone's users. Thirty-minute calls are enough. Draft the guide with AI and review it for bias. Record or take notes with consent, then follow the safe synthesis workflow above.

Exercise 3: Define (30 min). Generate 5 problem statements, then pick one and justify it. Run a pre-mortem.

Exercise 4: Content system (45 min). Create a voice description and glossary (10–20 terms) for your capstone. Use the error-message prompt to write 8–12 messages, then edit them.

Exercise 5: States inventory (30 min). For your capstone's main screen, use AI to list every state, then review the list and add what it missed.

Exercise 6: Your workflow map (30 min). Turn the stage table into your version: for each stage, what you'll use AI for, which tool, the risk tier and the verification step.

Deliverable

1. Capstone brief (2–3 pages): problem, users (from real conversations), key insights with evidence, constraints, success metrics, chosen direction, and the risks from the pre-mortem.
2. Voice and glossary for the capstone.
3. Personal AI workflow map across the six stages.

Self-check

1. At which stage is AI used least by practitioners, and why is that appropriate?
2. Describe the five steps of the safe synthesis workflow.
3. Give two acceptable and two unacceptable uses of synthetic users.
4. Why is AI particularly valuable for UX writing, and what must you provide?
5. What does PACED stand for?

Go deeper

• NN/G: Synthetic Users vs. Human Respondents
• NN/G: When Should You Disclose AI Use? PACED
• NN/G course (paid): Accelerating Research with AI
• NN/G course (paid): AI for Design Workflows

Next → Module 05: Figma's AI toolkit

Module 05: Figma's AI toolkit

Time: about 4 hours · Output: a "which Figma AI tool for which job" guide, tested on your capstone

🔧 This module is the most volatile in the course. Features described here are accurate as of October 2026 per Figma's documentation, and several are in beta. Always check Figma's Help Center and developer docs for the current state. Focus on the concepts, because they will outlast the UI.

Learning objectives

• Understand the four layers of Figma's AI ecosystem and what each is for.
• Use the Figma agent with your library, so output uses your components.
• Use Figma Make for interactive prototypes, and know how Make connects to code.
• Explain what the Figma MCP server does: read design context, write to the canvas, and capture code to the canvas.
• Choose the right tool for a task, and know when to leave Figma.

Why this matters for a lead

Figma is where your team lives. Knowing its AI layers well lets you set conventions ("always connect the library before prompting the agent"), make the right seat and plan decisions, and design the bridge between your team's Figma work and engineering's coding agents.

1. The four layers

┌─────────────────────────────────────────────────────────────────┐
│ 1. FIGMA AGENT (in Figma Design)                                │
│    Generate, remix, automate busywork, get feedback — on canvas  │
├─────────────────────────────────────────────────────────────────┤
│ 2. FIGMA MAKE                                                   │
│    Prompt → interactive, code-backed prototypes/apps            │
├─────────────────────────────────────────────────────────────────┤
│ 3. FIGMA MCP SERVER (for external agents)                       │
│    Read design context · Write to canvas · Code → canvas         │
│    Make & FigJam resources · Code Connect · Figma Specs          │
├─────────────────────────────────────────────────────────────────┤
│ 4. YOUR DESIGN SYSTEM (libraries, variables, components, docs)  │
│    The foundation every layer above draws on                    │
└─────────────────────────────────────────────────────────────────┘

Key insight: layers 1–3 are only as good as layer 4. Figma's documentation repeats this throughout: write-to-canvas "works especially well with design systems", and the agent produces better results with a connected library. Modules 07–08 are about making layer 4 excellent.

2. The Figma agent (in Figma Design)

As of May 20, 2026, Figma's agent became the entry point for generation features such as the earlier "First Draft" (Figma Help).

What it does

Per Figma's help article:

• Generate and remix designs, automate busywork, and give design feedback.
• Open it from a selected layer with Agents or Cmd/Ctrl + Enter, or from the persistent sidebar.
• Add context: attach Figma files, images, files, skills and connected-app information.
• Run multiple prompts in parallel on different frames.
• Connect a library so results use your components, styles and variables, and @-reference specific components, variables and styles in prompts.
• Undo the agent's last change from the chat.
• Answer how-to questions about Figma, drawing on the Help Center.

Permissions to know (as lead)

• Full seat with edit access: can ask the agent to make edits.
• View, Dev or Collab seats, or view-only access: can chat but not edit, except in their own Drafts.
• Since June 23, 2026, new agent chats in a design file are visible by default to people with a Full seat and edit access. Tell your team this, because people may assume their chats are private.

Good uses

• Busywork: renaming layers, applying auto layout, converting raw values to variables, generating states and variants, filling in realistic content.
• Exploration: "Remix this card in 4 directions using our library."
• Feedback: "Check this frame for inconsistencies with the connected library."

Habits to teach your team

1. Connect the library first, every time.
2. @-reference components and variables instead of describing them.
3. Duplicate before big changes if you want to compare (Figma's own tip).
4. Review agent output like a junior designer's work: check structure, naming and variable use, not just looks.

3. Figma Make

Figma Make turns prompts (and designs) into interactive, code-backed prototypes and apps. It is aimed at designers.

When to use Make

• You need real interactivity: filters that filter, forms that validate, state that persists, realistic data.
• You want to test complex interactions with users early (Module 06).
• You want stakeholders to feel a concept rather than just look at it.

How Make connects to production

Through the MCP server, an engineer's (or your) coding agent can pull resources from a Make file into the codebase, such as the code for a component's behaviour and styles, and implement them using the existing production components (Figma docs).

Figma's tip: "Name the component in your codebase you want your agent to use, so it extends what you already have instead of creating something new." That's a good example of a durable principle (reuse the system) expressed as a tool tip.

Make vs other AI prototyping tools

Covered in depth in Module 06. In short: Make is the best choice when you want to stay close to Figma and your library. Tools like v0, Lovable, Bolt or a coding agent give you more control and closer-to-production code.

4. The Figma MCP server

This is the most strategically important layer for a lead, because it connects your system to every coding agent in the company.

What it is

An MCP server (Module 02) that exposes Figma to AI agents. There are two ways to connect (Figma docs):

• Remote server (recommended): Figma's hosted endpoint, https://mcp.figma.com/mcp. It has the broadest feature set and doesn't need the desktop app.
• Desktop server: runs via the Figma desktop app, for specific organisation and enterprise needs. It requires a Dev or Full seat on a paid plan.

Supported clients include Claude Code, Claude Desktop, Codex, Copilot CLI, Cursor, VS Code, Android Studio and others.

What it can do (October 2026)

Write to canvas vs code to canvas

These are easy to confuse, and the difference matters:

• Write to canvas builds with your components and variables, producing system-connected, editable design. The agent uses the use_figma tool, which runs code via the Figma Plugin API (docs).
• Code to canvas captures a running app as flat layers, without a connection to your libraries (docs).

Figma suggests using them together: capture the latest UI, then have the agent refine it with your design system.

Write-to-canvas notes

• It requires the remote server and a Full seat to write outside your drafts. It's free during beta and will become usage-based paid later.
• Figma recommends installing its skills (for example figma-use) for your client, so the agent follows the right workflow.
• ⚠️ Figma's own caution: test on a duplicate of your library or a draft file before changing production files, and keep a backup.

The round trip this enables

     Figma (design system)                         Code (component library)
  ┌──────────────────────┐   read design context   ┌──────────────────────┐
  │ Components, variables │ ──────────────────────→ │ Agent writes code    │
  │ Code Connect mappings │                         │ using real components│
  │                       │ ←────────────────────── │                      │
  └──────────────────────┘   code to canvas /       └──────────────────────┘
            ↑                write to canvas
            └── designers review, annotate, refine ──┘

Module 10 has you do this hands-on.

Plans and limits (as lead)

🔧 Rate limits apply, and some features need specific plans and seats. Write to canvas needs a Professional, Education, Organization or Enterprise plan with edit access. Code Connect has framework limits on Professional plans (one active framework). Check Plans, access and permissions before recommending a rollout.

5. Choosing the right tool

When to leave Figma

• Complex logic or real data integrations: a coding agent.
• Research synthesis or long-form writing: a general assistant.
• Production code: an engineer-owned repository with review gates (Module 11).

Common mistakes

• Prompting the agent without a connected library, which produces off-system output.
• Treating agent output as finished. Check layer structure, variable usage and naming.
• Running write-to-canvas on the production library. Duplicate first.
• Confusing code-to-canvas layers with system components. Captured layers are flat.
• Ignoring seat and plan implications when recommending a rollout.

Lab 05

Exercise 1: Agent busywork (45 min). Take a messy file (old work is perfect). Ask the agent to rename layers semantically, apply auto layout to 3 frames, and convert raw colour values to existing variables. Review each change and log the time saved and any errors.

Exercise 2: Library-connected generation (45 min). Connect a library (your company's, or a community UI kit). Generate the same capstone screen twice: once without the library connected and once with it, @-referencing 3 components. Compare structure, not just looks: are real instances used? Are variables bound?

Exercise 3: Make a prototype (60 min). In Figma Make, build a small interactive version of one capstone interaction, such as a filter panel or a multi-step form. Note what was easy, what was hard and what felt "average".

Exercise 4: Code to canvas (optional, 30 min, needs MCP set up). Capture any live web page you have rights to use (your company's staging site, or a simple local page) into Figma and inspect the layers. What's lost compared with a system-built design?

Exercise 5: Your tool guide (30 min). Turn section 5 into a one-page guide for your future team, including the habits from section 2.

Deliverable

"Figma AI at [Team]": a one-page guide covering which tool for which job, the five habits, the permissions and privacy notes (chat visibility), and the plan or seat implications. Include your before/after comparison from Exercise 2.

Self-check

1. Name the four layers of Figma's AI ecosystem.
2. What's the difference between write to canvas and code to canvas?
3. Why does connecting a library matter for agent output?
4. Which MCP server type does Figma recommend, and why?
5. What precaution does Figma recommend before using write-to-canvas on important files?

Go deeper

• Figma Help: Work with the Figma agent in design files
• Figma Help: Use AI in your design workflows (collection)
• Figma Docs: MCP server introduction, Write to canvas, Code to canvas
• Figma blog: The Figma canvas is now open to agents
• GitHub: figma/mcp-server-guide

Next → Module 06: AI prototyping

Module 06: AI prototyping and testing with real users

Time: about 8 hours, spread across 2 weeks · Output: a tested, interactive capstone prototype (v2) and a findings report

Learning objectives

• Decide when a prototype needs to be interactive and when static Figma is enough.
• Understand the AI prototyping tool landscape and choose a tool by need.
• Follow a reliable six-step AI prototyping process.
• Create realistic data and complete states for prototypes.
• Run usability tests on AI prototypes and avoid the fidelity trap.

Why this matters for a lead

AI prototyping is the most visible change in design practice, and the most misunderstood. Stakeholders will see a polished AI prototype and ask, "Can we just ship this?" A lead needs a clear point of view on what prototypes are for, how they're validated, and where they stop.

1. Why interactive prototypes changed the game

Before AI, complex interactions (filters, dashboards, data tables, conversational UI, multi-step logic) were tedious to prototype. Teams tested a few happy-path screens and waited for engineering to see real behaviour.

NN/G's 2026 article Test Complex Interactions Earlier with AI Prototyping describes what changed:

• Ramp: a senior designer used Cursor to prototype a redesign of the expense-policy editor, with AI chat-based editing. Participants tested a working prototype loaded with their own sanitised data. The team found an issue with how edits were tracked and displayed that they "couldn't have found... without an interactive prototype". It went from concept to demo in three weeks and influenced the roadmap.
• Ramp (conversational AI): a prototype connected to a real agent, so participants could type anything, revealing how the agent handled unexpected requests. Static screens can't simulate non-deterministic behaviour.
• Purdue University: a traffic-data filtering interface was first built as static Figma wireframes, then rebuilt with v0 and Bolt using a synthetic dataset. With static screens, participants gave less specific feedback. With the interactive prototype, they identified specific problems.

The durable lesson: for complex interactions, realistic behaviour and data produce better feedback earlier. For simple questions (layout preference, content comprehension, visual hierarchy), static prototypes are still fine and often faster.

2. Static or interactive? Decide first

Rule of thumb: prototype the minimum fidelity that answers the research question. AI makes high fidelity cheap to create, but high fidelity can still cost you, through slower iteration, attachment, and stakeholders assuming it's done.

3. The tool landscape (🔧 volatile, so choose by category)

NN/G: "The tool you use depends on how much control you need and how comfortable you are editing code."

Recommendation for this course: use one prompt-to-app builder or Make now, and a coding agent in Module 10. As a lead you'll want both: builders for speed and agents for system-faithful prototypes.

4. The six-step AI prototyping process

From NN/G's article, with practical additions:

Step 1: Decide what the prototype must do

Write the research questions and derive the required behaviour:

Research question: Can admins find and fix a misconfigured spending rule
in under 2 minutes?
Must work: rule list with search; rule detail; edit; validation errors;
save; undo. Data: 40 realistic rules incl. 3 misconfigured.
Doesn't need to work: login, settings, other modules.

Step 2: Make your design decisions before prompting

Layout, hierarchy, interactions and edge cases (empty, error, loading). NN/G: "The quality of the prompt... depends on the thinking you do in this step." Sketch or wireframe in Figma first.

If you leave design decisions to the AI tool, it will fill in the gaps, with average choices. The decisions remain yours.

Step 3: Collect or create data

• Real data: only if allowed. Remove personal data, follow company policy, and check the tool's data policy.
• Synthetic data: have an AI generate it from your criteria. Include edge cases: long names, empty values, extreme numbers, unicode, many items, zero items.

Prompt: realistic dataset

Generate a JSON dataset of 40 spending rules for a mid-size company.
Fields: id, name, category, limit (EUR), approver role, status
(active/paused/misconfigured), lastEdited, editor name.
Include: 3 misconfigured rules (explain why in a "notes" field), 2 with
very long names (60+ chars), 1 with limit 0, varied categories, realistic
European names. Return valid JSON only.

Step 4: Write a structured prompt (markdown helps)

# Prototype: Spending rules editor

## Goal
Test whether admins can find and fix misconfigured rules quickly.

## Users
Finance admins at 50–500 person companies; expert users; use it weekly.

## Layout
- Left: searchable, filterable rule list (status chips, category filter)
- Right: rule detail panel with inline editing
- Top: summary bar (total rules, # misconfigured – clickable filter)

## Interactions
- Search filters list as you type
- Clicking a rule opens detail; edits validate on blur
- Save shows toast with Undo (10s)
- Misconfigured rules show inline warning with "Fix" suggestion

## States
Empty search result; loading (300ms simulated); validation error; save
error (simulate on rule id 13); success.

## Visual
Use these tokens: [paste key tokens or DESIGN.md excerpt]. Dense, calm,
professional; no gradients; 8px spacing grid.

## Data
Use attached rules.json.

Step 5: Generate in the tool

Attach the prompt, data, sketches, screenshots and (if supported) your DESIGN.md.

Step 6: Edit, iterate, then pilot-test

• Expect several rounds of iteration. Fix one thing at a time.
• Pilot test with a colleague before real sessions, to catch broken flows.
• Check that it works on the device and browser participants will use.

5. Getting AI prototypes to look like your product

Prompt-to-app tools default to a generic aesthetic. To pull them toward your system:

1. Give exact tokens: colours, type scale, spacing, radius, ideally as a DESIGN.md (Module 08).
2. Attach screenshots of 2–3 real screens as visual reference.
3. Name components and patterns: "use a data table with sticky header", "use toast for confirmations".
4. State what not to do: "no gradients, no emoji, no card shadows".
5. For the highest fidelity, use a coding agent with your real component library (Module 10).

6. Testing AI prototypes with real users

The research method is the same as always. The new considerations are:

• Moderated sessions work best for complex prototypes, because you can recover if something breaks.
• Share a hosted link. Most builders provide one. Test the link from an incognito window first.
• Reset state between participants (reload, clear local storage), or pre-seed data per participant.
• For AI or conversational features, expect different outputs per session. Log what the system said in each session, since findings depend on it.
• Tell participants it's a prototype. Some features may be missing.

Sample size: 5 participants per round finds most major usability problems in qualitative testing. Iterate, then test again.

Analysing: apply the safe synthesis workflow from Module 04.

7. The fidelity trap: prototype ≠ product

NN/G warns: a polished AI prototype prompts "can we just ship this?", but it may contain wrong patterns, confusing hierarchy and repeated elements, plus (from engineering's perspective) no security, error handling, accessibility, performance, tests or architecture.

As a lead, establish this rule: A prototype is a learning artifact. Production is built through the agreed pipeline: system components, code review, accessibility and QA gates (Module 11).

How to communicate it:

• Label prototype links clearly: "PROTOTYPE – for research only".
• In reviews, present what you learned, not just the prototype.
• Offer the path to production: "Here's the validated design; engineering will build it with system components, and Make or MCP resources can speed that up."

Common mistakes

• Prompting before deciding. You get the AI's design, not yours.
• Toy data. "Lorem ipsum" and three perfect rows hide real problems.
• Over-building. Prototyping the whole app when one interaction was the question.
• Endless polishing instead of testing.
• Shipping the prototype (the fidelity trap).
• Skipping the pilot, so session 1 is wasted on bugs.

Lab 06 (two weeks)

Week A: Build

1. Research questions (30 min). Write 2–3 research questions for your capstone and derive what must and must not work.
2. Design decisions (60–90 min). Sketch or wireframe the key screens and all states in Figma.
3. Dataset (30 min). Generate realistic data with edge cases and review it.
4. Prompt (45 min). Write the structured markdown prompt.
5. Build (2–3 h). Generate in Make, v0, Lovable or Bolt. Iterate until it supports your test tasks. Log each iteration in your AI log.
6. Pilot (30 min). Have a colleague run through it.

Week B: Test

7. Test plan (45 min). Write 3–5 tasks with success criteria.
8. Sessions (3 h). Run 3–5 moderated sessions with real target users.
9. Synthesis (60 min). Write findings ranked by severity, with evidence.
10. Iterate (60 min). Fix the top 3 issues and produce v2.

Deliverable

1. Prototype v1 and v2 links, with the prompt and dataset.
2. Test report (2 pages): research questions, method, participants, findings by severity, evidence, changes made.
3. A reflection: what did interactivity reveal that a static prototype wouldn't have?

Self-check

1. Name three research questions that need an interactive prototype, and two that don't.
2. What are NN/G's steps for AI prototyping complex interfaces?
3. What edge cases should a synthetic dataset include?
4. What is the fidelity trap, and how do you protect against it as a lead?
5. How do you make a prompt-to-app builder produce something closer to your brand?

Go deeper

• NN/G: Test Complex Interactions Earlier with AI Prototyping
• Paper: User-Centered Design with AI in the Loop: Rapid UI prototyping with "vibe coding" (Purdue, 2025)
• Video: Building with Cursor, with designers from Cursor, Notion and Ramp
• Paid option: AI prototyping for designers (Maven)

Next → Module 07: Design system foundations

Module 07: Design system foundations for the AI era

Time: about 8 hours · Output: a tokenised mini design system in Figma (variables plus 6–8 core components) for your capstone

Learning objectives

• Explain what a design system is (and isn't) and why AI makes it more important.
• Design a token architecture: primitive → semantic → component tokens.
• Implement tokens as Figma variables with collections and modes (for example light and dark).
• Understand the W3C Design Tokens (DTCG) format at a conceptual level.
• Build components with strong properties, variants, auto layout and naming.
• Apply accessibility at the system level.

Why this matters for a lead

AI amplifies whatever system it's given. A clean system yields consistent output at speed, and a messy one yields inconsistency at speed. As lead, the design system is your highest-leverage asset: it shapes the work of your designers, your engineers, and every AI agent touching UI.

1. What a design system is

A design system is a shared set of decisions, expressed as reusable assets (tokens, components, patterns), documentation and a governance process, so that teams build consistent products faster.

NN/G's design systems course puts it well: design systems "aren't just style guides or component libraries. They are living products and an ongoing practice of decision-making at scale" (source).

The layers

┌──────────────────────────────────────────────┐
│ Governance & contribution (how it evolves)   │  ← Module 13
├──────────────────────────────────────────────┤
│ Documentation & guidelines (when/why/how)    │  ← Module 08 (for AI too)
├──────────────────────────────────────────────┤
│ Patterns (forms, tables, empty states, flows)│
├──────────────────────────────────────────────┤
│ Components (Button, Input, Modal...)         │
├──────────────────────────────────────────────┤
│ Tokens (color, type, space, radius, motion)  │
├──────────────────────────────────────────────┤
│ Principles (what we value, trade-offs)       │
└──────────────────────────────────────────────┘

Why AI raises the stakes

1. Agents read structure, not vibes. An agent can't tell that Rectangle 47 is a card. It can use Card/Elevated with a bound color/bg/surface variable.
2. Generated UI has no taste of its own. Without a system, it falls back to the generic average.
3. More people generate UI (PMs, engineers, agents). A system plus rules is how your standards reach work you never see.
4. The Figma MCP server passes your system to agents: variables, components, Code Connect mappings. Your system is the interface.

2. Design tokens

What a token is

A design token is a named design decision stored as data: color.bg.surface = #FFFFFF. Tokens are the single source of truth shared between design tools and code.

The three tiers

Why tiers matter:

• Theming: dark mode means pointing semantic tokens at different primitives, without touching components.
• Rebranding: change primitives or aliases, and everything updates.
• AI clarity: semantic names tell agents when to use a value. color.text.danger is self-explanatory; red.500 is not.

Rule: components should use semantic tokens and almost never primitives directly.

Naming tokens

A common structure is category → property → role/variant → state:

color / bg / surface
color / bg / surface-raised
color / text / primary
color / text / muted
color / border / default
color / action / primary / default
color / action / primary / hover
color / feedback / danger / bg
space / inset / sm | md | lg
space / stack / sm | md | lg
radius / sm | md | lg | full
font / size / body | heading-sm | heading-lg

Good names are predictable (someone can guess a token name they've never seen), purposeful (they describe intent, not appearance), and consistent (one pattern everywhere).

The W3C Design Tokens standard (DTCG)

The Design Tokens Community Group (DTCG) at the W3C published the first stable version (2025.10) of the Design Tokens specification (designtokens.org). It defines a vendor-neutral JSON format for exchanging tokens between tools. Figma, Penpot, Sketch, Framer, Style Dictionary, Tokens Studio, Supernova, zeroheight and others are listed as adopters or participants.

Conceptually, a DTCG token file looks like this:

{
  "color": {
    "blue": {
      "600": { "$type": "color", "$value": "#2563EB" }
    },
    "action": {
      "primary": {
        "$type": "color",
        "$value": "{color.blue.600}",
        "$description": "Primary interactive elements: main CTA, links, selected states."
      }
    }
  }
}

Key ideas: $value, $type, $description, groups (nesting) and aliases ({color.blue.600}).

Why a lead should care: a standard format means tokens can flow Figma → code → other tools without hand translation, typically via a pipeline (for example Figma variables → export → Style Dictionary → CSS variables and platform files). You don't need to build the pipeline yourself, but you should insist on one source of truth and know that the standard exists. 🔧 Check your tooling's current DTCG support.

Note $description: descriptions travel with tokens and are read by tools and agents. Writing them is a cheap, high-value AI-readiness step (Module 08).

3. Tokens in Figma: variables

🔧 Figma implements tokens as variables, organised into collections with modes.

Recommended setup for this course

Collection: Primitives        (no modes; hidden from publishing if possible)
  blue/50…900, grey/50…900, red/…, green/…, amber/…
  space/0,1,2,3,4,6,8,12,16    (4px base)
  radius/0,2,4,8,12,full

Collection: Semantic color    (modes: Light, Dark)
  color/bg/*, color/text/*, color/border/*, color/action/*, color/feedback/*

Collection: Semantic size     (modes: Comfortable, Compact) – optional
  space/inset/*, space/stack/*, space/inline/*

Use scoping so designers (and agents) only see appropriate variables in each picker. That's a quiet but powerful quality guardrail.

Typography: use text styles (or typography variables, where your setup supports them) with semantic names like heading/lg and body/md.

4. Components

Anatomy of a good component

Match property names to code (critical for AI)

If engineering's Button takes variant="primary" | "secondary" and size="sm" | "md" | "lg", name Figma properties the same way. That makes Code Connect mapping trivial (Module 08) and makes MCP output closer to real code.

Tip: sit with an engineer and compare component APIs to Figma properties. Every mismatch is a translation error waiting to happen, for humans and agents alike.

Core component set for your capstone (6–8)

1. Button: variants, sizes, icon options, states including focus and loading
2. Text input: label, helper, error, disabled, with an optional icon
3. Select / dropdown
4. Checkbox / toggle
5. Card / container
6. Modal / dialog
7. Toast / inline alert: info, success, warning, danger
8. Empty state: illustration or icon, title, body, action

Then one pattern relevant to your capstone, such as a filter bar, table row or form section.

5. Accessibility built into the system

Building accessibility into the system means every product (and every AI generation) inherits it.

• Contrast: WCAG 2.2 AA requires 4.5:1 for normal text and 3:1 for large text and essential UI components and graphics. Check each semantic text and background pairing in every mode.
• Focus states: visible, consistent, and tokenised (color/border/focus).
• Target size: WCAG 2.2 AA's minimum target size is 24×24 CSS px (with exceptions). Many systems use 44×44 for touch.
• Don't rely on colour alone: pair danger red with an icon or text.
• Motion: respect reduced-motion preferences, and tokenise durations.
• Content: labels are required, and placeholders are not labels.

Document these in component descriptions, because agents will read them (Module 08).

6. Documentation basics

At minimum, every component needs:

1. Purpose: what it's for, in one line.
2. When to use / when not to use, plus alternatives.
3. Anatomy: named parts.
4. Properties: what each does.
5. Behaviour: interactions and states.
6. Content guidelines: label length, tone.
7. Accessibility notes.

Free reference: Figma's designsystems.com has guides on space, grids, iconography, typography and content strategy.

Common mistakes

• Primitives used directly in components, which makes theming impossible.
• Visual names (blue-button) instead of purpose names (action/primary).
• Variant explosion: 400 variants where 4 properties would do.
• Figma and code mismatch in names and props.
• Missing states, especially focus and error.
• No descriptions, so humans and agents guess.
• Building everything at once. Start with the 20% of components used 80% of the time.

Lab 07

Exercise 1: Audit (45 min). Screenshot 5–8 screens from your capstone or a real product. Use AI to help list every colour, font size, spacing value and component variant in use. Count the inconsistencies, because this becomes your "why we need a system" evidence.

Exercise 2: Token architecture (90 min). Define primitives and semantic tokens (colour with light and dark modes, spacing, radius, type). Create them as Figma variables with scoping. Write a $description-style one-liner for each semantic token in the variable description field.

Exercise 3: Contrast check (30 min). Verify every semantic text and background pair in both modes with a contrast checker and fix failures.

Exercise 4: Components (3 h). Build the 6–8 core components, fully bound to variables, with auto layout, properties, all states and semantic layer names.

Exercise 5: Pattern (60 min). Build one capstone-specific pattern from the components.

Exercise 6: Rebuild one screen (45 min). Rebuild your main capstone screen using only system components. Switch to dark mode. Did everything theme correctly? Fix what didn't.

Optional: export your variables as JSON (via a plugin or your preferred method) and look at the structure. Can you see the tiers?

Deliverable

A published Figma library with:

• Primitive and semantic variable collections (light and dark modes), with descriptions
• 6–8 core components plus one pattern, fully tokenised, with all states
• One capstone screen built 100% from the system, working in both modes
• A one-page audit summary: "before the system → after the system"

Self-check

1. What are the three token tiers, and which should components use?
2. Why are semantic names better for AI agents than visual names?
3. What is the DTCG, and what did it publish in October 2025?
4. Why should Figma component properties match code component props?
5. What WCAG contrast ratios apply to normal text and to UI components?

Go deeper

• designtokens.org and the DTCG spec drafts
• designsystems.com (by Figma)
• Design System University free courses (Dan Mall)
• Paid: Subatomic: The Complete Guide to Design Tokens (Brad and Ian Frost)
• Paid: NN/G Architecting and Managing Effective Design Systems

Next → Module 08: Making your design system AI-ready

Module 08: Making your design system AI-ready

Time: about 6 hours · Output: component descriptions, a DESIGN.md, an agent rules file, and an AI-readiness scorecard for your system

Learning objectives

• Define what makes a design system machine-readable.
• Write component descriptions that guide both people and agents.
• Write a DESIGN.md following Google Labs' open format.
• Understand Code Connect and why it's the strongest link between Figma and code.
• Write rules files (AGENTS.md, CLAUDE.md, Cursor rules, Copilot instructions) that keep agents on-system.
• Score your system's AI-readiness and use AI to audit it.

Why this matters for a lead

This is where design leadership multiplies. Without AI-readiness, agents improvise. With it, every agent (yours, your engineers', your PMs') builds with your components, your tokens and your rules. You stop policing output one screen at a time and start shaping it at the source.

1. What "machine-readable" means

A human can infer meaning from visual context, history and conversation. An agent can only use what's explicit and structured. A machine-readable design system has:

The test: could a capable new hire build a correct screen using only what's written down and structured? If yes, an agent probably can too.

2. Component descriptions

Figma components have a description field. It shows in the UI and is part of what tools and agents can read. Treat it like a short spec.

Template

PURPOSE: Primary action trigger for forms and dialogs.
USE WHEN: One main action per view/section (Save, Continue, Create).
DON'T USE: For navigation (use Link); for destructive actions (use
Button variant=danger); more than one primary per section.
PROPERTIES: variant (primary|secondary|tertiary|danger), size (sm|md|lg),
iconLeading, iconTrailing, loading, disabled.
CONTENT: Verb-first, ≤ 3 words, sentence case ("Save changes").
A11Y: Min target 24×24 (44×44 on touch). Visible focus ring
(color/border/focus). Loading state must keep label for screen readers.
CODE: <Button> in @acme/ui (see Code Connect).
RELATED: Link, IconButton, ButtonGroup.

Write these for all core components. It takes about 10 minutes each and is the highest-ROI AI-readiness task you can do. (The Figma agent can draft them from your component, and then you edit.)

Also describe variables: color/text/muted: "Secondary text: metadata, helper text, timestamps. Not for disabled text (use color/text/disabled). Min contrast 4.5:1 on bg/surface."

3. DESIGN.md: visual identity for coding agents

In April 2026, Google Labs open-sourced DESIGN.md, a format for describing a product's visual identity to coding agents (GitHub; NN/G's coverage). It's a draft (alpha) specification, but the idea is durable and easy to adopt.

Structure

A DESIGN.md combines two layers:

1. Machine-readable tokens in YAML front matter (or YAML blocks): colours, typography, rounded (radii), spacing, components.
2. Human-readable rationale in markdown: what the values are for and how to apply them, plus do's and don'ts.

"Tokens give agents exact values. Prose tells them why those values exist and how to apply them." (DESIGN.md README)

Example (abridged)

---
name: Acme Finance
colors:
  text-primary: "#111827"
  text-muted: "#4B5563"
  surface: "#FFFFFF"
  action-primary: "#2563EB"
  danger: "#B91C1C"
typography:
  heading-lg: { fontFamily: Inter, fontSize: 1.5rem, fontWeight: 600 }
  body-md: { fontFamily: Inter, fontSize: 1rem, lineHeight: 1.5 }
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 24px
---

## Overview
Calm, precise, trustworthy. Dense layouts for expert users; whitespace is
used for grouping, not decoration.

## Colors
- **action-primary** is the only colour for primary actions and links.
  Never use it decoratively.
- **danger** only for destructive actions and errors; always pair with an
  icon or text.

## Typography
One family (Inter). Max three sizes per screen. Sentence case everywhere.

## Do / Don't
- Do: use tables for comparable data.
- Don't: use gradients, shadows deeper than 1 level, or emoji in UI.

Tooling

The project provides a CLI that lints a DESIGN.md (broken token references, WCAG contrast checks) and diffs two versions to detect regressions:

npx @google/design.md lint DESIGN.md
npx @google/design.md diff DESIGN.md DESIGN-v2.md

🔧 This tool is new. Check the repo for the current spec.

Where DESIGN.md fits

• Next to the code, in the product's repository, where coding agents read it every time.
• Attached to prompt-to-app tools (v0, Lovable, Make) to pull prototypes toward your brand (Module 06).
• Generated from your Figma variables. Your Figma variables are the source of truth, and DESIGN.md is a published view of them. Keep them in sync, ideally automatically.

4. Code Connect: the strongest Figma ↔ code link

Code Connect links components in your design files to components in your codebase. It makes Dev Mode show real production snippets, and it gives the Figma MCP server direct references to your actual code, so agents use <Button variant="primary"> from your library instead of inventing a <button className="bg-blue-600…"> (Figma docs).

Two ways to set it up

They can be used together. CLI-created connections appear in the UI but are edited in the CLI.

What a mapping looks like (template file, conceptually)

// url=https://www.figma.com/file/…/Button?node-id=123
import figma from 'figma'
const instance = figma.selectedInstance

export default {
  example: figma.code`
    <Button
      size={${instance.getEnum('Size', { Large: 'large', Medium: 'medium', Small: 'small' })}}
      disabled={${instance.getBoolean('Disabled')}}
    >
      ${instance.getString('Text Content')}
    </Button>
  `,
  imports: ['import { Button } from "components/Button"'],
  id: 'button',
}

Notice how it maps Figma properties to code props. This is why Module 07 insisted on matching names: mismatched names mean more mapping work and more mistakes.

There is also a figma-code-connect skill that helps coding agents write these templates from a component URL.

Plan notes (🔧)

On Professional plans you can have one active framework at a time. Organization and Enterprise plans can have multiple. This matters if you ship web and native.

Your role as lead

You probably won't write the templates. You will:

• Prioritise which components to connect first (the most-used ones).
• Align Figma properties with code props.
• Own the decision that Code Connect is part of the "definition of done" for a system component.

5. Rules files: instructions agents always follow

Rules are project-level instructions an agent follows every time, "the unwritten rules of your codebase that an experienced developer would pass on to a new teammate" (Figma).

Where they live (🔧 varies by tool)

Many teams keep one canonical file (often AGENTS.md) and reference it from the others.

What to put in them: design-system rules

From Figma's recommended general rules (adapted):

## Design system rules
- IMPORTANT: Always use components from `packages/ui` when possible.
  Never create a new Button, Input, Modal, etc. if one exists.
- Never hardcode colours, spacing, radii or font sizes. Use tokens
  (CSS variables from `packages/tokens`). If a token is missing, stop
  and ask — do not invent one.
- Follow WCAG 2.2 AA: labels on all inputs, visible focus, contrast ≥ 4.5:1.
- Use sentence case for all UI text. Use terms from /docs/GLOSSARY.md.
- Read DESIGN.md before any UI work.

## Figma MCP flow (do not skip)
1. Run get_design_context for the exact node(s).
2. If too large, run get_metadata, then re-fetch only needed nodes.
3. Run get_screenshot for visual reference.
4. Only then implement. Treat MCP output (often React + Tailwind) as a
   description of design intent, not final code style — translate it into
   this project's components and tokens.
5. Validate against the screenshot before marking complete.

Figma also suggests asking the agent to generate rules by analysing the codebase (where tokens live, the component architecture, styling approach, icon system), then reviewing them. A full template is in templates/AGENTS.md.

Rules hygiene

• Short and specific beats long and vague. Each rule should be testable.
• Use "IMPORTANT" sparingly, for the rules that matter most.
• Version them in git, review changes like code, and give them an owner (Module 13).
• Update them from failures. When an agent drifts, ask which rule would have prevented it, then add it (the "drift log", Module 10).

6. Using AI to audit your design system

Agents can help maintain the system too.

• Figma agent: "Find all layers in this file using raw colour values instead of variables" or "List detached instances".
• Write-to-canvas agent (beta, use a duplicate!): "Convert the raw values in this section to variables."
• Coding agent on the repo: "Find hardcoded hex colours and px values in /src that should be tokens. Produce a table with file, line, value and suggested token."
• DESIGN.md lint: contrast and broken references.
• Consistency: "Compare these Figma components' properties with the props of the matching React components. List mismatches."

7. The AI-readiness scorecard

Score each 0–2 (0 = absent, 1 = partial, 2 = solid):

0–7: not AI-ready; agents will improvise. 8–14: partially ready; expect drift. 15–20: AI-ready; agents mostly stay on-system.

Common mistakes

• Writing a rules novel. Agents follow concise, specific rules better.
• DESIGN.md out of sync with Figma. Two sources of truth means no truth.
• Connecting everything with Code Connect at once. Start with the top 10.
• Running write-to-canvas audits on the production library.
• No owner for the rules. They go stale (NN/G: context needs ongoing maintenance).

Lab 08

Exercise 1: Descriptions (90 min). Write structured descriptions for all your capstone components and semantic variables. Try having the Figma agent draft them first, then edit and compare.

Exercise 2: DESIGN.md (60 min). Write a DESIGN.md for your capstone system: tokens in YAML plus rationale prose. If you have Node.js, run npx @google/design.md lint DESIGN.md and fix the findings. (If not, do it in Module 10 when you set up a coding environment.)

Exercise 3: Rules file (45 min). Adapt templates/AGENTS.md for your capstone.

Exercise 4: Code Connect mapping plan (30 min). You may not have a codebase yet. List your components, their Figma properties and the props you'd expect in code. Mark which to connect first. (You'll implement 2 in Module 10.)

Exercise 5: Scorecard (30 min). Score your capstone system, and also a real system you know, such as your company's. Write the top 3 improvements for each.

Deliverable

1. Component and variable descriptions in your Figma library.
2. DESIGN.md (linted if possible).
3. AGENTS.md (design-system rules plus the Figma MCP flow).
4. AI-readiness scorecard with an improvement plan.

Self-check

1. What's the "new hire test" for machine-readability?
2. What are the two layers of a DESIGN.md?
3. What does Code Connect give the Figma MCP server that it otherwise lacks?
4. Name three places rules files live, depending on the tool.
5. How should rules evolve over time?

Go deeper

• DESIGN.md spec (Google Labs)
• Figma: Code Connect docs and Add custom rules
• figma/mcp-server-guide
• Paid, and the best fit for this module: AI & Design Systems (Brad Frost et al.)
• Paid: AI Design Systems & Prototyping intensive (Christine Vallaure)

Next → Module 09: Context engineering

Module 09: Context engineering and UX-context design

Time: about 6 hours · Output: UX.md (your product's UX context), a context library structure, and a with/without-context experiment

Learning objectives

• Explain context engineering and why it now matters more than prompt wording.
• Apply NN/G's global / local / ambient model of context.
• Practise UX-context design: turning research and standards into context that steers everyone's AI.
• Write a UX.md covering research synthesis, interaction standards, glossary, user models and world models.
• Run a context experiment to measure whether your context improves output.
• Maintain a context library without building a "big ball of mud".

Why this matters for a lead

This is probably the most important new responsibility of an AI-era design lead. In many organisations, designers are no longer the only people producing designs: PMs make mockups and engineers' coding agents choose labels and error states. NN/G's answer is not gatekeeping. It is to make sure everything AI generates, no matter who prompts it, is informed by the organisation's knowledge of its users and design standards (source).

If you own that context, your influence extends to every screen, including the ones you never see.

1. From prompts to context

Context is everything the model can see when it does the work: your request plus instructions, standards, examples and background information (NN/G).

• Prompt engineering: how you phrase the request.
• Context engineering: what knowledge, rules and examples surround the request, and how they're curated, structured, scoped and maintained.

NN/G's research with AI power users found they spent more effort engineering context libraries than crafting prompts, and most prompts were casually dictated (source). "Curating the right context now matters even more than writing a good prompt" (source).

An analogy: the house builder who never meets your family designs the average house, which is wrong in ways that matter if you use a wheelchair or work from home. "That's not the builder's fault; the problem is the builder didn't have context." (NN/G)

2. The three roles of context

From NN/G's study of AI power users (source):

        ┌────────────── ambient (Slack, transcripts, tickets) ──────────────┐
        │                                                                    │
        │     [local: brief]   [local: research]   [local: Figma frame]      │
        │            \               |                    /                  │
        │             ───────→  AI OUTPUT  ←──────────────                   │
        │                           ↑                                        │
        │   ═══════ global: principles · DESIGN.md · UX.md · rules ═══════   │
        └────────────────────────────────────────────────────────────────────┘

Information can change roles. A Slack decision (ambient) becomes local when you point the agent at it, and may become global if it turns into a standing rule.

Design-lead implication: your job is mostly to curate global context (the standards everyone shares) and to define templates for local context (what a good feature brief contains). Be cautious with ambient context: it's noisy and can contain sensitive data.

3. UX-context design

UX-context design is the practice of discovering and curating what an organization knows and wants into the context that guides everything its AI tools generate: from who its users are and the world they live in, to how a product should look and behave. (NN/G)

It also involves testing the context with the models your team uses and refining it.

Why traditional deliverables aren't enough

A persona has a stock photo and a name to help humans empathise. "A model does not need persuading, it needs the underlying reasoning." (NN/G) So AI-ready deliverables are:

• Distilled: findings stated as clear, reasoned insights.
• Curated by a skilled human: not raw transcripts dumped in.
• Available to everyone who designs, regardless of role.
• Living next to the product: in the repo or a shared library, read on every generation.
• Measured by output quality, not by stakeholder persuasion.

Curation, not handoff

Traditional deliverables are handed off and left behind. UX context is continuously curated: "New research updates it, and so does watching what the AI gets wrong." (NN/G)

4. Writing UX.md

NN/G proposes UX.md as a hypothesis: a broader companion to DESIGN.md. DESIGN.md covers visual identity; UX.md covers experience knowledge. For large products, UX.md can be an index to a folder of context files.

Recommended sections

1. Research synthesis: insights as constraints

Write findings so they constrain generation:

❌ "Users find onboarding hard." ✅ "Users abandon setup when asked for information they don't have on hand. → Never require external info (IDs, documents) in the first session; allow save-and-return."

Include the evidence strength (for example "n=12 interviews, 2025-Q4") so agents and humans know how much to trust each one.

2. User models

Expertise, goals, concerns, frequency of use, what doesn't work for them. No stock photos, just reasoning:

"Finance admins: expert users, work in the product 2–4 h/day during month-end, prefer density and keyboard shortcuts, distrust automation that changes numbers without showing the change."

NN/G's example of how a user model leans generation: if users spend hours making complex decisions, lean toward denser screens. If they use it a few minutes a month, lean toward fewer choices per screen.

3. World models (context of use)

The conditions users are in: interruptions (a nurse on a hospital floor), stress (filing a claim after an accident), compliance (every action must leave an audit trail), devices, connectivity, environment.

4. Interaction standards

How the product behaves:

• When to confirm versus allow undo
• How errors are worded and placed
• Expert versus novice optimisation
• Loading, empty and partial states
• Notifications: when, where, how loud

5. Glossary

The words users and domain experts use, with definitions and forbidden synonyms: "Users say 'case', not 'ticket'." NN/G notes a side effect: users' terms start appearing even in code, because agents pick them up.

6. Pointers

Links to DESIGN.md, the component library location, the accessibility standard and key research reports.

A full template is in templates/UX.md.

5. Building a context library

A context library is "a collection of institutional and procedural knowledge, contained within markdown files or external software, that AI agents may reference and edit" (NN/G).

Suggested structure for a product team

/context
  README.md               ← index: what's here, when to use what, owners
  UX.md                   ← global UX context (or index)
  DESIGN.md               ← global visual identity
  GLOSSARY.md             ← global terminology
  principles.md           ← design principles with do/don't
  accessibility.md        ← standards and checks
  /research
    2026-q3-onboarding.md ← distilled insights, evidence strength, date
  /features
    _brief-template.md    ← local-context template
    invoices-redesign.md  ← local context for an active project
  /skills                 ← packaged procedures (optional, tool-dependent)
AGENTS.md                 ← rules; points agents to /context

NN/G's four lessons (from power users)

1. Context needs ongoing maintenance. Files written once and used for months go stale. Schedule reviews and audit context against recent decisions.
2. Let the agent update context for you, then verify. Most power users asked the AI to edit context files rather than typing into them. It's faster and keeps the style consistent, but review the changes, because users "rarely checked what Claude had changed".
3. Structure the library for findability. Clear names, an index, one topic per file.
4. Give agents only the context they need. More isn't better: irrelevant context dilutes quality and wastes tokens.

Skills: packaging procedures

Skills package instructions (and sometimes scripts and resources) that an agent loads when relevant, typically a folder with a SKILL.md describing when to use it. Examples: "write UX copy using our voice", "run a heuristic review using our checklist", "create a feature brief". Figma ships skills for its MCP server (such as figma-use and figma-code-connect). As the team grows, turning frequent prompts into skills is the natural evolution from your prompt library (Module 03).

6. Testing context: the with/without experiment

UX-context design must be tested. NN/G lists open questions: which artifacts help most, when raw data helps, how to measure efficacy, and whether there is such a thing as too much context. Your team can answer these for your product.

Method

1. Pick 3 representative generation tasks: for example "invoice list screen", "error state for failed payment", "onboarding step 2".
2. Define a rubric (score 1–5): - Uses system components and tokens correctly - Fits users' expertise and context (density, terminology) - Follows interaction standards (confirm/undo, error style) - Accessibility basics - Copy matches voice and glossary
3. Generate each task under 3 conditions: - A: prompt only - B: prompt + DESIGN.md - C: prompt + DESIGN.md + UX.md (+ rules)
4. Run each condition 2–3 times (outputs vary).
5. Score blind if possible: have a colleague score without knowing the condition.
6. Analyse: which context moved which rubric line? What did the AI still get wrong, and which context would fix it?
7. Update the context, then re-test. Keep a changelog.

This gives you evidence for leadership ("adding UX.md raised the average rubric score from 2.4 to 3.9") and tells you where to invest.

A template is in templates/context-experiment.md.

7. Avoid building a big ball of mud

NN/G found AI power users ("vibe architects") repeatedly building "big balls of mud": systems "scraped together for short-term functionality, not architected for long-term durability" (source). Because building feels free, people overbuild. The patterns they saw include:

• Throwaway code becomes permanent: a quick rules.md draft that everything comes to depend on.
• Piecemeal growth: features bolted on as needs arise, until nobody understands the whole.

…and others from Foote and Yoder's original catalogue, leading to systems that are hard to direct, diagnose or rebuild.

Guardrails for your context library

• Plan the structure before writing lots of files (use the structure above).
• One owner per file, and a review cadence (for example quarterly, or after each research round).
• Changelog: what changed, why, and what triggered it.
• Prune: delete or archive stale context. Context debt is real.
• Prefer fewer, better files over many overlapping ones.
• Re-test (section 6) after big changes.
• Rebuild deliberately when the system gets too tangled, rather than patching forever.

8. Privacy and safety in context

• No personal data in context files. Distil insights, don't paste transcripts.
• No secrets (keys, credentials) in any file an agent reads.
• Check where context goes: which tools read it, and what their data policies are.
• Ambient connections (Slack, email, MCP to Notion and so on) can expose more than intended. Scope them deliberately. NN/G also notes connections break ("system decay"), so expect maintenance.

Common mistakes

• Dumping raw research into context. NN/G warns of noise and over-focus on the wrong things.
• Writing for humans: persuasive decks instead of reasoned constraints.
• One giant file, or the opposite: 60 overlapping files.
• Never testing whether the context helps.
• Never updating it: write once, rot forever.
• No owner.

Lab 09

Exercise 1: Inventory (30 min). List all your capstone knowledge: research findings, users, constraints, voice, glossary, interaction decisions. Tag each item global, local or ambient.

Exercise 2: Write UX.md (2 h). Use templates/UX.md. Convert your Module 04 and 06 findings into constraint-style insights with evidence strength. Write user models, world models, interaction standards and a glossary.

Exercise 3: Library structure (30 min). Organise your files (UX.md, DESIGN.md, AGENTS.md, glossary, a feature brief) in the structure from section 5, with an index README.

Exercise 4: Context experiment (2 h). Run the with/without experiment on 3 tasks × 3 conditions × 2 runs, using a prompt-to-app tool or the Figma agent. Score with the rubric, ideally with a colleague scoring blind.

Exercise 5: Improve and re-test (45 min). Based on the results, update the context and re-run the weakest task. Record the score change.

Deliverable

1. UX.md for your capstone.
2. Context library folder with index README, owners and changelog.
3. Context experiment report (1–2 pages): method, scores, what improved output, what didn't, and next changes, with before/after screenshots.

Self-check

1. Define UX-context design in one sentence.
2. Give a design example of global, local and ambient context.
3. Rewrite "users find search confusing" as a constraint-style insight.
4. What are NN/G's four lessons for context libraries?
5. Why run the with/without experiment, and what's in the rubric?
6. What is a "big ball of mud", and name two guardrails against it.

Go deeper

• NN/G: UX-Context Design
• NN/G: The 3 Roles of Context for AI Agents
• NN/G: Context Libraries
• NN/G: The New Big Ball of Mud
• Claude Academy (free): Introduction to agent skills
• Paid: NN/G Context Engineering: Shaping AI-Generated Designs

Next → Module 10: Design to code with agents

Module 10: Design to code with agents

Time: about 8 hours · Output: a small repository with tokens, 2 Code-Connected components and 1 capstone screen built by an agent from Figma, plus a drift log

Learning objectives

• Understand the developer basics a design lead needs: repo, terminal, git, branches, pull requests, dev server, components and props.
• Set up a coding agent with the Figma MCP server.
• Run the design → code workflow: Figma frame → agent → running UI → review.
• Map components with Code Connect.
• Close the loop with code to canvas for design review.
• Maintain a drift log and turn drift into better rules.

Why this matters for a lead

You don't need to become an engineer. But engineering's workflow is now where your design system lives or dies. If you can run this loop yourself, even on a toy project, you can:

• Judge agent output and set realistic expectations.
• Design the team's design-to-code pipeline with engineering, not around it.
• Speak the language: branch, PR, props, tokens, build.
• Prototype at production fidelity when it matters.

1. Developer basics for designers (crash course)

Five commands worth recognising (the agent will run most of them):

git clone <url>          # copy a repo to your machine
git checkout -b my-branch  # start a branch
npm install              # install dependencies
npm run dev              # start the dev server (localhost)
git status / git diff    # see what changed

Safety rule: never work directly on main. Use branches, and let changes reach main through PRs with review.

2. Setup (🔧 tool-specific, so follow current docs)

You need:

1. VS Code (or Cursor).
2. Node.js (LTS), which most web projects need.
3. A coding agent: Claude Code, Cursor, GitHub Copilot (VS Code agent mode or CLI), or Codex.
4. The Figma MCP server, remote (recommended): https://mcp.figma.com/mcp. Follow the client-specific steps in Figma's installation docs. You'll authenticate with your Figma account.
5. Figma's skills or plugin for your client, where available (for example the Figma plugin for Claude Code, or Figma skills), so the agent follows Figma's workflows.
6. A GitHub account and a new repository for the capstone.

Ask the agent to help with setup. For example: "I'm a designer. Help me set up a new React + TypeScript project with Vite in this folder, explain each step in plain language, and don't run anything destructive without asking."

3. Scaffold the project with tokens

Prompt your agent (adapt as needed):

Create a minimal React + TypeScript app (Vite) for a design-system demo.
Structure:
- /src/tokens/tokens.css  → CSS custom properties for our tokens
- /src/components/        → one folder per component
- /src/screens/           → screens composed from components
- /context/               → copy of DESIGN.md, UX.md, GLOSSARY.md
- AGENTS.md at root       → I will provide content
Use plain CSS modules (no Tailwind). Explain what you did in plain language.

Then:

1. Copy your DESIGN.md, UX.md, glossary and AGENTS.md (Modules 08–09) into the repo.
2. Ask the agent to generate tokens.css from your Figma variables via MCP. The get_variable_defs tool exposes variables. For example: "Using this Figma file , read the variables and create tokens.css with CSS custom properties for the semantic tokens, including light and dark modes."
3. Review: are names semantic? Do both modes exist? Are the values right?
4. Commit on a branch: git checkout -b setup-tokens, and let the agent commit with a clear message.

4. The design → code loop

Step-by-step

1. In Figma, right-click your Button component → Copy link to selection.
2. Prompt the agent:

Implement the Button component from this Figma selection: <link>.
Follow AGENTS.md (Figma MCP flow). Use tokens from src/tokens/tokens.css.
Props must match the Figma component properties (variant, size,
iconLeading, loading, disabled). Include all states incl. visible focus.
Add a demo page showing all variants. Then run the dev server.

3. The agent (per the rules) calls get_design_context, then get_screenshot, implements the component, and runs it.
4. You review in the browser: every variant, keyboard focus (press Tab), hover, disabled, loading.
5. Compare against Figma side by side. Note every difference in the drift log.
6. Feed back: "Focus ring uses the wrong colour; use --color-border-focus. The loading state hides the label from screen readers; keep it with aria-busy."
7. Commit when it's right.

Repeat for Input, then build one capstone screen from components:

Build the "Rules list" screen from this Figma frame: <link>.
Use ONLY components in src/components. If a needed component doesn't
exist, stop and list what's missing — do not create ad-hoc UI.
Use realistic data from src/data/rules.json. Include empty, loading, and
error states as designed.

That "stop and list what's missing" instruction is a powerful governance pattern. It turns potential drift into a design-system backlog item.

What MCP output really is

Figma's rules note that MCP output (often React + Tailwind) is a representation of design and behaviour, not final code style. The agent should translate it into your project's components and tokens. If you see Tailwind classes or raw hex values in the result, a rule is missing or being ignored.

5. Code Connect: map your two components

With the components in code, connect them to Figma (🔧 docs):

• Option A, Code Connect UI: in Figma, connect your GitHub repo and map the components. This is the simplest route for designers.
• Option B, CLI with template files: ask the agent to use the figma-code-connect skill: "Create Code Connect template files for Button and Input from these Figma component links, mapping Figma properties to props." Then publish (the agent can guide you).

Verify:

• In Dev Mode, inspect a Button instance. You should see your <Button variant=…> snippet.
• Ask the agent to build another small screen. It should now import your Button without being told, because MCP returns the Code Connect reference.

6. Close the loop: code to canvas

Use the MCP code to canvas capability (generate_figma_design) to capture your running screen into Figma:

Start the dev server and capture the Rules list screen (including the
empty and error states) into this Figma file: <link>.

Now place the captured UI next to the designed frame. Remember that captured layers are flat, with no library connection. This is a review artifact, not a source of truth.

Design QA on canvas:

• Spacing and alignment differences
• Type styles
• Colours in both modes
• Missing states
• Copy differences

Annotate the issues, share the frame link with the agent, and ask it to fix them. That's the full round trip.

7. The drift log

Drift is any difference between the design-system intent and the agent's output. Track it in templates/drift-log.md:

Root causes usually fall into five types:

1. Missing rule
2. Missing or ambiguous context (DESIGN.md or UX.md gap)
3. Design system gap (component or token doesn't exist)
4. Figma hygiene issue (raw values, bad names, unmapped component)
5. Model limitation (rare once 1–4 are solved)

As a lead, the drift log becomes your evidence base for system investment: "60% of drift came from missing Code Connect mappings."

8. Design QA checklist for agent-built UI

Full checklist: templates/design-qa-checklist.md. The essentials:

• [ ] Uses system components only (no ad-hoc duplicates)
• [ ] No hardcoded colours, spacing or type values
• [ ] All states implemented (empty, loading, error, disabled, focus, long content)
• [ ] Keyboard: logical tab order, visible focus, no traps
• [ ] Labels on inputs; meaningful button text; alt text where needed
• [ ] Contrast checked in all modes
• [ ] Copy matches voice and glossary
• [ ] Responsive at the agreed breakpoints
• [ ] Matches Figma within agreed tolerances

9. Safety habits with agents

• Work on branches; review the diff before committing.
• Approve commands you don't understand only after asking the agent to explain them.
• No secrets in prompts or files.
• Don't let agents push to main or deploy without review.
• Start fresh sessions for new tasks. Long sessions accumulate stale context.

Common mistakes

• Prompting "build this app" from one frame. Go component by component.
• Accepting Tailwind or raw values because "it looks right".
• No rules file, so you correct the same drift repeatedly.
• Skipping keyboard and screen reader checks. Agents often miss focus and ARIA details.
• Treating captured layers as the system.

Lab 10

1. Setup (60–90 min): tools, MCP, repo, and a scaffolded project with your context files.
2. Tokens (30 min): generate tokens.css from Figma variables and review it.
3. Button and Input (2 h): run the loop and log drift.
4. Code Connect (45 min): map both components and verify in Dev Mode.
5. Screen (90 min): build one capstone screen from components only.
6. Code to canvas (30 min): capture it, do design QA on canvas, and fix the issues.
7. Rules update (20 min): update AGENTS.md from the drift log, re-run one task and check that the drift is gone.

Deliverable

1. GitHub repo with tokens, Button, Input, one screen, context files and AGENTS.md.
2. Code Connect for 2 components (with a Dev Mode screenshot).
3. Drift log with at least 8 entries, classified by root cause.
4. Before/after evidence that rule changes reduced drift.

Self-check

1. What's the design analogy for a branch and a pull request?
2. Why is MCP output "a representation of design intent, not final code style"?
3. What does Code Connect change in agent output?
4. Name the five root-cause categories of drift.
5. Why does "stop and list what's missing" matter for governance?

Go deeper

• Figma: MCP server docs, Tools and prompts, Code to canvas
• Figma: Code Connect quickstart
• Free: DeepLearning.AI: Claude Code, A Highly Agentic Coding Assistant (builds an app from a Figma mockup via MCP)
• Free: Claude Academy: Claude Code in action
• Paid: Claude Code for Designers (Maven), Designlab Vibe Coding Camp

Next → Module 11: Designer–developer collaboration

Module 11: Designer–developer collaboration, rebuilt

Time: about 4 hours · Output: a designer–developer collaboration contract, a RACI, and a definition of done for AI-assisted UI

Learning objectives

• Describe how the dynamics between design and engineering change when both can generate UI.
• Identify the common friction points and their causes.
• Define ownership (RACI) for the system, context, prototypes and production code.
• Design review gates and a shared definition of done.
• Set up rituals that keep design and code in sync.

Why this matters for a lead

Handoff used to be a clear line: design in Figma, then engineering builds. Now designers ship coded prototypes, engineers' agents generate UI, PMs make mockups, and everyone's output looks "finished". Without explicit agreements, you get duplicated components, off-brand UI, turf wars and quality regressions. Defining this collaboration is a core lead responsibility.

1. What changed in the relationship

What each side gains

Designers:

• Test realistic interactions early (Module 06).
• Influence code directly through the system and rules.
• See exactly what was built (code to canvas).

Engineers:

• Faster first passes from accurate design context.
• Fewer ambiguous specs, because tokens and components are explicit.
• Less pixel-pushing, more architecture and quality work.

2. Common friction points (and what's really going on)

3. Ownership: a RACI for AI-era UI

R = Responsible (does it) · A = Accountable (final say) · C = Consulted · I = Informed

* In small companies the "DS team" may be you plus one engineer. ** AGENTS.md is shared: design owns the design-system sections, engineering owns the code-convention sections.

Key principle: designers may contribute code (prototypes, proposals, even PRs to the component library), but engineering is accountable for production code, and design is accountable for the experience.

4. Review gates

Gates are where quality is protected. Keep them few, clear and early.

 Idea → [Gate 1] → Prototype & test → [Gate 2] → Build → [Gate 3] → Release

Make Gate 3 lightweight but mandatory. Ideally designers review PR preview deployments (many teams auto-deploy each PR to a temporary URL) and comment directly on the PR.

5. Definition of done for AI-assisted UI

A UI change is "done" when:

• [ ] Built from system components; any new component went through the contribution process
• [ ] No hardcoded design values; tokens only
• [ ] All designed states implemented
• [ ] Accessibility: keyboard, focus, labels, contrast and screen-reader basics checked
• [ ] Copy matches voice and glossary
• [ ] Design QA passed (Gate 3)
• [ ] Code reviewed by an engineer
• [ ] If a new pattern emerged: Figma, code, Code Connect and docs all updated
• [ ] If drift was found: drift log updated and a rule or context change proposed

6. Rituals that keep design and code in sync

7. The contribution model (how the system grows)

When a team needs something the system doesn't have:

1. Check: does something existing work, perhaps with a new variant?
2. Propose: a short request covering the need, use cases and a design proposal.
3. Review: the DS team decides between a one-off, a new variant or a new component.
4. Build both sides: Figma component, code component, Code Connect, docs and description.
5. Announce: changelog and a rules or context update if needed.

Agents participate too: the "stop and list what's missing" rule (Module 10) feeds this process automatically.

8. Communication principles

• Lead with shared goals: quality, speed and user outcomes, not ownership.
• Talk about the system, not people: "the rule was missing" rather than "you did it wrong".
• Make your work inspectable: decisions in docs, rationale in context files.
• Learn their tools (Module 10). Credibility comes from understanding.
• Invite engineers into design critique, and ask to join code reviews for UI.

Common mistakes

• Designers shipping prototype code to production without engineering review.
• Engineering ignoring design QA because "the AI matched Figma".
• No contribution process, so the system fragments.
• Treating AGENTS.md as engineering-only. Design-system rules belong to design too.
• Gates too late, with review only after release.

Lab 11

Exercise 1: Developer interviews (90 min). Interview 2 engineers (from your company, or acquaintances):

• How do you use AI to build UI today?
• What's frustrating about design handoff?
• What would make AI-generated UI more correct for you?
• What do you think designers should and shouldn't do in code?
• How do you feel about design reviewing PRs?

Synthesise the answers into 5 insights.

Exercise 2: RACI (45 min). Adapt the RACI to your (future) organisation. Mark the rows you're unsure about as questions for your eng lead.

Exercise 3: Collaboration contract (60 min). Write it with templates/collaboration-contract.md. Include ownership, gates, definition of done, rituals, the contribution model, and how you'll resolve disagreements.

Exercise 4: Gate 3 dry run (30 min). Use your Module 10 repo: open a PR, review it as a designer using the QA checklist, and comment.

Deliverable

1. Designer–developer collaboration contract (2 pages), ideally reviewed by one engineer.
2. RACI for your context.
3. Interview synthesis (5 insights).

Self-check

1. Name three things that changed in design–dev collaboration.
2. What's the key ownership principle for production code?
3. Describe the three review gates.
4. Why should design own part of AGENTS.md?
5. What happens when an agent can't find a needed component?

Go deeper

• NN/G: UX-Context Design: "Everyone Is Designing"
• designsystems.com: Design & Development section
• Figma: Code Connect
• Paid: AI & Design Systems (Brad Frost et al.), especially the rollout and governance chapter

Next → Module 12: Designing AI-powered product features

Module 12: Designing AI-powered product features

Time: about 4 hours · Output: an AI-feature review of a real product, plus an AI feature concept for your capstone that passes the "value first" test

This course is mostly about using AI to design. But as a lead you'll also be asked to design AI features into products, and you'll review your team's AI feature work. This module gives you the durable principles.

Learning objectives

• Decide whether AI adds value to a feature, before deciding how.
• Recognise the main interaction paradigms for AI features (intent-based, chat, inline, generative UI, agents).
• Design for non-determinism, errors and trust.
• Apply guidelines for transparency, control, explanation and disclosure.
• Design for AI agents as users of your product.

Why this matters for a lead

AI features are where hype hits users hardest: sparkle buttons nobody understands, chatbots that can't help, agents that act without consent. A lead protects users and the business by insisting on value first, then trustworthy design.

1. Value first: should this be AI at all?

NN/G is blunt: "Powered by AI" is not a value proposition, and AI features must solve real user problems (study guide). Novelty rarely produces value. Start from the problem, not the technology.

Where AI genuinely helps

NN/G's four AI "superpowers": content creation, summarisation, basic data analysis and perspective-taking (source). If your feature idea doesn't use at least one, question it.

The value-first test

1. What user problem does this solve? Is there evidence it exists?
2. What do users do today without AI? Is the AI way clearly better?
3. Could a non-AI solution work (better defaults, search, a filter, a template)?
4. What happens when the AI is wrong? Is that acceptable for this task?
5. Can users tell what it does? (NN/G found users often can't tell what a site's AI chatbot is for.)
6. Is the scope narrow enough? Narrowly scoped AI features are easier to understand and see better adoption (source).

2. Interaction paradigms

Intent-based interaction

NN/G describes AI as the first new UI paradigm in 60 years: intent-based outcome specification, where users state what they want rather than how to do it (source).

Its weakness is the articulation barrier: many users struggle to express what they want in words. The solution is hybrid interfaces, combining prompts with GUI controls (source).

Patterns and when to use them

The ✨ sparkles problem

The sparkles icon has become associated with AI but is inherently ambiguous (NN/G). Label what the feature does ("Summarise reviews"), not that it's AI.

3. Designing for non-determinism and errors

AI output varies and is sometimes wrong. Design for that explicitly.

• Set expectations: state capabilities and limits up front ("I can answer questions about your invoices; I can't change payments").
• Show sources and evidence: citations, links, "based on 248 reviews".
• Make output editable: a draft the user refines, not a final answer.
• Easy undo and recovery: especially for actions.
• Confidence cues, where meaningful and honest.
• Graceful failure: "I'm not sure. Here's how to find out" beats a confident error.
• Human handoff: a path to a person when it matters. NN/G lists handoff willingness among the five qualities of trustworthy site chatbots (source).
• Write for the web: AI output should be concise, scannable, inverted-pyramid and plain-language (NN/G).

Testing AI features

• Test the range of outputs, not one happy path. Run the same scenario multiple times.
• Include adversarial and edge inputs: vague requests, out-of-scope requests, sensitive topics.
• Use interactive prototypes connected to real models (the Ramp example, Module 06).
• Define quality rubrics with domain experts.

4. Trust, control and transparency

Durable guideline sets worth knowing

• Microsoft's Guidelines for Human-AI Interaction (HAX): 18 guidelines grouped by initially, during interaction, when wrong and over time (for example "make clear what the system can do", "support efficient correction", "remember recent interactions", "notify users about changes"). HAX Toolkit
• Google PAIR People + AI Guidebook: user needs, mental models, explainability and trust, feedback and control, errors and graceful failure. PAIR Guidebook

These predate the current wave but remain highly relevant, which is a good sign they're durable.

Control principles for agents

When AI acts for users (sends, books, edits, buys):

• Preview before acting on anything consequential.
• Explicit consent for irreversible, financial or social actions.
• Visible activity: what it did, step by step.
• Interruptible: users can stop it.
• Reversible where possible.
• Scoped permissions: what it can access, and for how long.

NN/G's lessons from studying an AI agent (Qwen): support discoverability, reuse familiar patterns, handle personal data carefully, and protect user autonomy (source).

Explanations

Different roles need different explanations of the same AI output (NN/G). An end user needs "why this result"; an admin needs "what data and rules"; compliance needs an audit trail.

Disclosure (PACED)

Revisit Module 04: Policy, Audience, Context, Expectations, Degree. NN/G notes that third-party disclosure triggered the strongest negative reactions in the studies reviewed, so proactive disclosure is often safer (source). EU transparency obligations for AI-generated content began applying in August 2026. Involve legal for regulated contexts.

5. AI agents as users of your product

A newer shift: AI agents now use digital interfaces alongside humans: browsing, filling forms, comparing products (NN/G).

Implications for design leads:

• Accessibility helps agents too: semantic HTML, proper labels and clear structure make UIs legible to agents as well as assistive technology.
• Clear, consistent information architecture and predictable patterns.
• Machine-readable content: structured data, clear pricing and policies.
• Decide your stance: which agent actions to support, require confirmation for, or block.

Common mistakes

• AI-first, problem-second.
• Chat as the default UI.
• Sparkles instead of labels.
• Testing one happy path for a non-deterministic feature.
• Agents acting without preview or consent.
• Opaque output with no sources, no edit and no undo.

Lab 12

Exercise 1: AI feature teardown (60 min). Pick 2 AI features in products you use. Evaluate each against the value-first test, the error and trust principles, and 5 HAX guidelines of your choice. Rate each 1–5 and list 3 improvements.

Exercise 2: Capstone AI feature (90 min). Propose one AI feature for your capstone. It must:

• Pass the value-first test, with evidence from your research
• Choose a pattern deliberately (and say why not chat, if it isn't chat)
• Specify error states, recovery, sources and editing
• Specify consent and preview if it acts
• Include a PACED disclosure decision

Exercise 3: Prototype the risky part (optional, 90 min). Use an AI prototyping tool to prototype the feature's riskiest interaction, connected to a real model if possible. Run the same scenario 5 times and document the variation.

Deliverable

1. AI feature teardown of 2 real features.
2. Capstone AI feature spec (1–2 pages), including error, trust and disclosure design.

Self-check

1. What are NN/G's four AI superpowers?
2. What's the articulation barrier, and how do hybrid interfaces help?
3. Name four principles for designing around AI errors.
4. Name four control principles for agents that act on behalf of users.
5. Why does accessibility matter for AI agents as users?

Go deeper

• NN/G: Designing AI Products and Features: Study Guide
• Microsoft HAX Toolkit
• Google PAIR People + AI Guidebook
• Paid: NN/G Designing AI Experiences
• Paid: 50 AI Design Patterns That Actually Work (Vitaly Friedman, Maven)

Next → Module 13: Leading AI adoption

Module 13: Leading AI adoption as a design lead

Time: about 6 hours · Output: a Design Team AI Policy, a pilot plan with metrics, a skills matrix and training plan, and a leadership pitch

Learning objectives

• Set a strategy for AI in your design team that balances speed, quality and wellbeing.
• Write a practical AI policy covering tools, data, research, disclosure, review and agents.
• Select tools with clear criteria.
• Design and run a pilot with meaningful metrics.
• Lead change between mandates and scepticism.
• Build team skills and a training plan.
• Communicate value to executives with evidence.

Why this matters

NN/G's 2026 survey found that the biggest problems aren't access or buy-in. They are output quality (54%), data privacy (50%), lack of time to learn (36%), difficulty integrating into workflows (30%) and lack of training (23%). Many comments complained of mandates and unreliable output that "eat the gains" (source).

Every one of those problems is a leadership problem, which makes it your job.

1. Strategy: what are we trying to achieve?

Start with outcomes, not tools. Example strategic goals for a design team:

1. Learn faster: test realistic prototypes with users earlier and more often.
2. Scale quality: make design standards reach all AI-generated UI (system + context).
3. Reduce busywork: reclaim time for research, critique and craft.
4. Strengthen design–eng flow: fewer translation errors, faster parity.

And explicit non-goals:

• Not to reduce research with real users.
• Not to measure designers by output volume.
• Not to ship prototypes as production.

One-sentence strategy template:

"We use AI to [learn faster / scale quality / reduce busywork] so that [user/business outcome], while protecting [research with real users / accessibility / craft / wellbeing]."

2. The Design Team AI Policy

Full template: templates/ai-policy.md. The essential sections:

2.1 Principles

• Humans are accountable for everything we ship.
• AI drafts; designers decide.
• Real users over synthetic users for evidence.
• Verify in proportion to risk (Module 03).
• Accessibility is non-negotiable.
• Be transparent about AI use where it matters (PACED).

2.2 Approved tools

A list by category (design tool AI, assistant, prototyping, coding agent), with the plan or tier, who has access, and any restrictions. NN/G: 59% of practitioners work with an approved set. That's normal and healthy.

2.3 Data classification (what may go where)

Work with security and legal on this. Check tools' data retention and whether inputs are used for training.

2.4 Research rules

• AI may assist in planning, transcription and first-pass synthesis, using approved tools and with consent.
• Synthetic users may be used for pilot-testing materials and hypotheses, never as evidence.
• All insights must be traceable to real evidence.

2.5 Disclosure

When and how to disclose AI use, internally (research reports, design rationale) and externally (user-facing content). Use PACED and follow legal requirements.

2.6 Review gates

Reference the gates and definition of done (Module 11).

2.7 Agent permissions

As agents gain the ability to act, define what they may do without approval, a pattern NN/G saw power users encode as "governance rules" in global context (source):

2.8 Imagery, IP and licensing

Rules for AI-generated images, fonts and icons; brand approval; and checking that tools' licensing terms allow commercial use.

2.9 Ownership and review cadence

Who owns the policy, and when it is reviewed (at least quarterly, because the field moves fast).

3. Tool selection criteria

Prefer open standards (MCP, DTCG tokens, markdown context files, AGENTS.md conventions). They reduce lock-in, which is a key durability principle.

4. Running a pilot

Design

• Scope: one team, one product area, 4–6 weeks.
• Hypotheses: for example, "AI prototyping will let us run usability tests 1 sprint earlier", or "Adding DESIGN.md and AGENTS.md will cut design-QA defects on AI-built UI by 30%."
• Baseline: measure before you start (use the past 2–3 sprints).
• Support: training, office hours, a channel for questions.

Metrics that matter (and the vanity ones to avoid)

Evaluate

Compare against the baseline, collect qualitative stories, and decide to scale, adjust or stop. Publish what you learned, including what didn't work, because that builds trust.

Template: templates/pilot-plan.md.

5. Leading change: between hype and scepticism

Know your team

Principles

1. Invitation, not mandate. Mandates were a top complaint in NN/G's survey. Set expectations about outcomes, and let people choose tools within the policy.
2. Protect time to learn. "Lack of time" was the #3 barrier. Budget for it, for example 2 hours a week for 8 weeks.
3. Start with pain, not features. Ask "what's the most tedious part of your week?" and solve that first.
4. Make learning social: demos, show-and-tell, pairing, a shared prompt library.
5. Celebrate good judgment, including the decision not to use AI.
6. Be honest about job anxiety. NN/G found designers and researchers felt less job-secure than PMs. Talk about the evolving role openly, and invest in people's skills.
7. Push back upward with evidence. One respondent said: "I have to actively push against them on things I know AI doesn't do well yet." Your pilot data is how you do that credibly.

6. Skills and training

Skills matrix (rate each person 1–4)

Template: templates/skills-matrix.md.

You don't need everyone at 4 in everything. Aim for T-shapes: everyone at 2+ in literacy, critique and process; specialists at 3–4 in systems, context or design-to-code.

Training plan

Reuse this course. A team version:

• Weeks 1–2: Modules 01–03 together (reading plus weekly discussion).
• Weeks 3–6: Modules 04–06 on a real team project.
• Weeks 7–10: Modules 07–10, with DS-focused people going deeper.
• Ongoing: monthly show-and-tell, the prompt library, and drift reviews.

Hiring and career ladders

Add to job descriptions and ladders:

• Evidence of judgment with AI (what they chose not to use, and why)
• Systems thinking (tokens, components, context)
• Comfort with code-adjacent work (prototypes, PR reviews)
• Research integrity

7. Communicating to executives

Executives want to know: Is this making us better, faster or cheaper? What's the risk? What do you need?

One-slide structure:

1. Goal: strategy sentence.
2. Evidence: pilot metrics against the baseline (2–3 numbers).
3. Story: one concrete example, such as "we found a critical issue in week 2 instead of after launch".
4. Risks and controls: policy, gates, data rules.
5. Ask: budget, tools, time, or engineering partnership (for Code Connect and tokens).

Pre-empt the "replace designers" question: show how AI shifted time toward research, systems and quality, and how design context now improves everyone's AI-generated UI. That's design's influence growing.

8. Ethics and sustainability

• Bias: AI reflects its training data. Review generated content and imagery for stereotypes, and test with diverse users.
• Labour and craft: be clear about attribution and how AI-assisted work is evaluated.
• Environmental cost: AI use has energy costs. NN/G's survey listed ethics and sustainability as a barrier for 34%. Avoid wasteful use, such as generating 100 variants when 10 will do.
• Accessibility: never accept AI output that regresses accessibility.

Common mistakes

• Tool-first rollout without strategy.
• Mandates and volume metrics.
• No data rules, leading to an incident and then a blanket ban.
• No time to learn.
• Pilots without baselines.
• Ignoring job anxiety.

Lab 13

Exercise 1: Strategy (30 min). Write your strategy sentence, 3–4 goals and 3 non-goals.

Exercise 2: AI policy (2 h). Draft the policy with templates/ai-policy.md. Use your AI log (Module 01 onwards) as evidence for your choices.

Exercise 3: Pilot plan (60 min). Write the plan with hypotheses, baseline, metrics and timeline using templates/pilot-plan.md.

Exercise 4: Skills and training (45 min). Fill in the skills matrix for an imagined (or real) team of 4–6 and write a 10-week training plan.

Exercise 5: Executive slide (45 min). Make the one-slide pitch, using your capstone data as illustrative evidence (context-experiment scores, drift reduction, test timing).

Deliverable

1. Design Team AI Policy (2–4 pages)
2. Pilot plan
3. Skills matrix and training plan
4. Executive one-slider

Self-check

1. What were the top barriers in the NN/G survey, and why are they leadership problems?
2. Name three good pilot metrics and two vanity metrics.
3. What should an agent never do without approval?
4. How do you handle a sceptic versus an enthusiast?
5. What are the five parts of the executive slide?

Go deeper

• NN/G: AI in UX survey 2026 and its comments dashboard
• NN/G: AI Can Help Write an Article, but It Can't Stand Behind It (an example of a team AI process)
• Paid: NN/G AI Product Strategy
• Paid: AI & Design Systems, Chapter 6 (buy-in, pilot, rollout, governance)
• Free: Design System University: Make Design Systems People Want to Use

Next → Module 14: Capstone and your first 90 days

Module 14: Capstone and your first 90 days as an AI-native design lead

Time: about 8 hours · Output: a complete portfolio case study, a 20-minute presentation, and a 90-day plan for your new role

Learning objectives

• Assemble your capstone into a compelling lead-level case study.
• Present it to a mixed audience (design, engineering, leadership).
• Turn everything into a concrete 90-day plan for your new role.
• Set up habits to keep learning as tools change.

Part A: Assemble the capstone

What you have (checklist)

The case-study narrative

Lead-level case studies show judgment, systems and impact, not just screens. Structure:

1. Context: the product area, users and why it matters.
2. The challenge: user problem plus the organisational and AI-era challenge (for example "UI generated by many people and agents, inconsistently").
3. Approach: your workflow, and where AI was and wasn't used, and why.
4. Research and validation: real users, what the interactive prototype revealed, iteration.
5. The system: tokens, components, AI-readiness, and how standards reach agents.
6. Context engineering: UX.md, plus experiment results (before/after scores and visuals).
7. Design to code: the MCP loop, drift log insights, and rule improvements with evidence.
8. Collaboration and leadership: contract, policy, pilot plan.
9. Outcomes and metrics: what improved, with numbers from your logs and experiments.
10. Reflection: what you'd do differently, what you chose not to automate, and what's next.

Show evidence everywhere: AI log stats, rubric scores, drift reduction, test findings.

Quality bar

Before presenting, check each item:

• [ ] Every claim is backed by an artifact or data
• [ ] AI's role is transparent (PACED applied to your own case study)
• [ ] The human decisions are visible: what you chose, rejected and why
• [ ] Accessibility is evident throughout
• [ ] It can be understood in 5 minutes (summary) and explored in depth

Part B: The presentation (20 minutes)

A live demo beats slides. If you can, show the MCP loop live with a pre-recorded fallback. Watching an agent build from your system with your rules is a powerful moment for an engineering or leadership audience.

Rehearse with three audiences in mind:

• Designers: "How do I work this way?"
• Engineers: "Will this make my job easier or harder?"
• Executives: "What's the value and risk?"

Part C: Your first 90 days as lead

Use this as a template. Adapt it after your first weeks of listening. Template: templates/90-day-plan.md.

Days 1–30: Listen and baseline

Goal: understand before changing.

• 1:1s with every designer, the eng lead, PMs, research, and the DS owners (if any).
• What's working? What's painful? How do you use AI today? What worries you?
• Audit:
• Design system: run the AI-readiness scorecard (Module 08).
• Workflow: map the current process and where AI is (unofficially) used.
• Tools and data: what's being used? Any data risks?
• Design–eng: how does handoff work? Where does UI drift?
• Baseline metrics: time to first user test, design-QA defects, test frequency, team sentiment.
• Quick win: pick one painful, low-risk thing (for example busywork in Figma) and help fix it.
• Don't: announce big AI changes, buy tools, or rewrite the system.

Output: a "State of design and AI" memo (2 pages) shared with your manager and the team.

Days 31–60: Foundations and a pilot

Goal: establish guardrails and prove value on a small scale.

• Policy v1: draft with the team; review with security and legal.
• Collaboration contract v1: co-write with the eng lead.
• System foundations: fix the biggest AI-readiness gaps (often naming, variables and descriptions for the top 10 components).
• Context v1: DESIGN.md and a first UX.md from existing research.
• Pilot: one team, 4–6 weeks, with hypotheses and the baseline.
• Training: start the team version of this course (Modules 01–03).

Output: policy v1, contract v1, pilot launched, system improvements shipped.

Days 61–90: Evidence and roadmap

Goal: show results and set direction.

• Pilot review: metrics against baseline, plus stories. Scale, adjust or stop.
• Engineering partnership: plan the token pipeline and Code Connect for the top components.
• Rituals: drift review, DS sync, prototype showcase (Module 11).
• Roadmap (6–12 months): system, context, tooling, skills, rituals.
• Executive update: the one-slider (Module 13).

Output: a pilot report, a 6–12 month roadmap and an executive update.

Risks to watch

Part D: Staying current without drowning

Tools change monthly, so build a sustainable learning system:

• Weekly (30 min): skim one trusted source, such as the NN/G AI topic, Figma's release notes and help center, or your coding agent's changelog.
• Monthly (2 h): try one new capability on a real task and log it in your AI log.
• Quarterly (half day): review your policy, context and tool list. What's stale? What's new and proven?
• Yearly: re-run your context experiments with the latest models. NN/G warns that "a curation decision made for today's models may be wrong for next year's."

Filter for durability. Ask of any new trend:

1. Does it solve a real problem we have?
2. Is it based on an open standard or a proprietary lock-in?
3. Do practitioners report sustained use, or just launch-day excitement?
4. Does it strengthen or weaken human judgment, users in the loop and system consistency?

If it doesn't pass at least three of the four, wait.

Final self-assessment

Return to the competency rubric in 00-START-HERE.md. Score yourself again and compare with your week-1 baseline. Pick two competencies to deepen in the next 6 months, choosing from the optional paid courses in RESOURCES.md or a self-directed project.

Deliverable

1. Case study (portfolio-ready)
2. 20-minute presentation (with demo or recording)
3. 90-day plan tailored to your new role
4. Personal learning system (sources and cadence)
5. Updated self-assessment

Congratulations

You've gone from "Figma designer who uses AI sometimes" to someone who can:

• explain how AI works and where it fails,
• use it with judgment across the whole design process,
• build a system that steers everyone's AI toward your standards,
• connect design to code through agents,
• define how designers and engineers collaborate in this new reality,
• and lead a team through the change with evidence and empathy.

That is what an AI-native design lead is. The tools will change; these capabilities won't.

→ Back to Start Here · Templates · Glossary · Resources

Templates

Ready-to-use files referenced throughout the course. Copy them into your own workspace or repository and adapt them.

AI Log

Log every AI use for the duration of the course (and ideally beyond). Each entry takes about 30 seconds. After 12 weeks you'll have real evidence of where AI helps you, which you can use for your policy, pilot and executive conversations.

How to use

• One row per AI use.
• Time saved = estimated time without AI minus actual time (including prompting and fixing). Negative values are fine and important.
• Quality = 1 (unusable) to 5 (better than I'd have done).
• Verification = what you checked (none / skim / verify-3 / full).

Monthly summary

Stages

Discover · Define · Ideate · Design · Validate · Deliver · System · Code · Leadership

Prompt Library (starter)

Reusable prompts are assets. Version them, improve them and share them. When a prompt is used constantly, graduate it into a rule, context file or skill (Module 09).

Format for each entry:

## Name – when to use
Tier: low / medium / high      Inputs: ...
Prompt: ...
Known weaknesses: ...
Last improved: date – change

1. Structured critique: heuristic evaluation

Tier: medium · Inputs: screenshot, user and task description

You are a strict senior UX reviewer. Evaluate the attached screen for
[user type] trying to [task]. Use Nielsen's 10 usability heuristics.
For each problem: severity (critical/major/minor), heuristic, exact
location, why it matters for this user, concrete fix.
Max 10 items, ranked by severity. No praise. Say when you're unsure.

Known weaknesses: generic findings, and it misses fine visual detail. Verify contrast with a real tool.

2. Divergent concepts with lenses

Tier: low · Inputs: problem statement, users

Problem: [..]. Users: [..].
Give 10 concepts, each using a DIFFERENT strategy:
1 zero-UI/automation, 2 progressive disclosure, 3 template-first,
4 human-assisted, 5 import-first, 6 goal-first, 7 social/team,
8 interactive tutorial with real data, 9 contextual tips only,
10 borrowed from a non-software domain.
For each: one-sentence concept, best for whom, biggest risk.

3. Domain primer

Tier: medium · Inputs: domain name

I'm a product designer new to [domain]. Give me: key roles and goals,
typical workflows, glossary, regulations/constraints, publicly reported
pain points, and 10 questions to ask domain experts. Cite sources; mark
uncertain items.

4. Interview guide review

Tier: medium · Inputs: draft guide

Review this interview guide for leading questions, double-barrelled
questions, jargon, missing follow-up probes, and questions that ask users
to predict future behaviour. Suggest rewrites in a table: original /
problem / rewrite.

5. Synthesis first pass (approved tools and anonymised data only)

Tier: medium · Inputs: anonymised notes/transcripts

Cluster these notes into themes. For each theme: name, 1-sentence
insight, supporting quotes WITH participant ID and line reference,
number of participants. Then list: evidence that contradicts each theme,
and participants who don't fit any theme. Don't invent quotes.

Known weaknesses: can over-focus on frequent but shallow themes. Always verify quotes.

6. Error-message system

Tier: medium (high if shipped) · Inputs: voice, glossary, error cases

Voice: [..]. Glossary: [..]. Structure: what happened + why (if useful)
+ what to do next. Write messages for these cases: [..].
Table: case / message / action label / notes. Flag cases needing more info.

7. States inventory

Tier: low · Inputs: component or screen description or screenshot

List every state this [component/screen] needs, including: empty,
loading, partial, error (by type), success, disabled, read-only,
permission-denied, offline, long content, many items, zero items,
first-time use, and any domain-specific states. For each: trigger and
what the UI should show.

8. Realistic test dataset

Tier: low · Inputs: schema and edge cases

Generate [N] realistic but fictional [records] as JSON with fields: [..].
Include edge cases: very long text, empty optional fields, zero/extreme
values, special characters, and [domain-specific cases]. Use realistic,
diverse names. Valid JSON only.

9. Red-team a design decision

Tier: low · Inputs: decision and rationale

Argue AGAINST this decision as convincingly as possible: [..].
Give the strongest objections from: a sceptical engineer, a sceptical
PM, a frustrated novice user, a power user, and an accessibility expert.

10. Component description draft

Tier: low · Inputs: component name, properties, screenshot

Draft a design-system component description using this structure:
PURPOSE / USE WHEN / DON'T USE / PROPERTIES / CONTENT / A11Y / CODE /
RELATED. Component: [..]. Properties: [..]. Keep each line short and
testable.

Your prompts

Add your own below as you go through the course.

Feature Brief (local context template)

A good brief is local context for both people and AI agents (Module 09). Keep it short, structured and linked to evidence. Store it in /context/features/.

Feature: · Owner: · Status: · Last updated:

Problem

[1–3 sentences. Whose problem, what happens today, why it matters.]

Evidence

• [Research finding + source/link]
• [Analytics / support data]

Users and context

• Primary user: [link to the user model in UX.md]
• Situation: [when and where they hit this problem]

Goals and success metrics

• User outcome:
• Business outcome:
• Metric(s):

Scope

• In:
• Out:

Constraints

• Technical:
• Legal / compliance:
• Accessibility:
• Must use components: [list]

Design decisions so far

States to design

Empty · Loading · Error (types) · Success · Permission · Long content · [domain-specific]

Open questions

-

Links

• Figma: [link to frame/selection]
• Prototype: [link]
• Research: [link]
• Related PRs/issues:

Template: DESIGN.md

Copy this file as-is into your repository or context folder and edit it.

---
name: "[Product name]"
description: "Visual identity for [Product]. Source of truth: Figma variables in [library name]. Keep in sync."
colors:
  text-primary: "#111827"
  text-muted: "#4B5563"
  text-on-action: "#FFFFFF"
  surface: "#FFFFFF"
  surface-raised: "#F9FAFB"
  border-default: "#E5E7EB"
  border-focus: "#2563EB"
  action-primary: "#2563EB"
  action-primary-hover: "#1D4ED8"
  danger: "#B91C1C"
  success: "#15803D"
  warning: "#B45309"
typography:
  heading-lg:
    fontFamily: Inter
    fontSize: 1.5rem
    fontWeight: 600
    lineHeight: 1.3
  heading-md:
    fontFamily: Inter
    fontSize: 1.125rem
    fontWeight: 600
    lineHeight: 1.4
  body-md:
    fontFamily: Inter
    fontSize: 1rem
    fontWeight: 400
    lineHeight: 1.5
  body-sm:
    fontFamily: Inter
    fontSize: 0.875rem
    fontWeight: 400
    lineHeight: 1.5
  label:
    fontFamily: Inter
    fontSize: 0.875rem
    fontWeight: 500
rounded:
  sm: 4px
  md: 8px
  lg: 12px
  full: 9999px
spacing:
  xs: 4px
  sm: 8px
  md: 16px
  lg: 24px
  xl: 32px
---

<!--
  TEMPLATE based on the open DESIGN.md format by Google Labs
  (https://github.com/google-labs-code/design.md), an alpha/draft spec.
  Replace the example values with yours. Lint with:
    npx @google/design.md lint DESIGN.md
  The YAML tokens above are the normative values; the prose below explains
  how to apply them.
-->

## Overview

[2–4 sentences on the personality of the UI. Example: "Calm, precise and trustworthy. Dense layouts for expert users. Whitespace groups related content; it is never decorative."]

## Colors

- **action-primary** is the only colour for primary actions, links and selected states. Never use it decoratively.
- **text-muted** is for secondary text (metadata, helper text). It is not for disabled text.
- **danger / success / warning** are for feedback only, always paired with an icon or text. Never rely on colour alone.
- **surface-raised** is for grouped areas such as sidebars and table headers. Avoid stacking more than 2 surface levels.
- All text/background pairs meet WCAG 2.2 AA (4.5:1 normal text, 3:1 large text and UI components).

## Typography

- One family: Inter.
- Max 3 type sizes per screen.
- Sentence case for all UI text, including buttons and headings.
- Don't use bold for emphasis in body text; restructure instead.

## Layout & spacing

- 4px base unit; use spacing tokens only.
- Related items: sm (8px). Groups: md (16px). Sections: lg–xl (24–32px).
- Prefer tables for comparable data; cards only for heterogeneous items.

## Shape

- rounded.md for most containers and inputs; rounded.sm for small elements (tags); rounded.full only for avatars and pills.

## Components

- Always use the existing components from `[path]`. If one is missing, **stop and ask**.
- One primary button per section.
- Focus ring: 2px `border-focus`, offset 2px, on every interactive element.

## Do

- Use tokens for every colour, size and spacing value.
- Keep layouts dense and aligned to the spacing scale.
- Use icons with text labels for important actions.

## Don't

- No gradients, glows or drop shadows deeper than one level.
- No emoji in UI.
- No new colours outside this file.
- No centre-aligned body text.

Template: AGENTS.md

Copy this file as-is into your repository or context folder and edit it.

# AGENTS.md

> Instructions for AI coding agents working in this repository. Many tools read `AGENTS.md`. If your tool uses a different file (`CLAUDE.md`, `.cursor/rules/`, `.github/copilot-instructions.md`), point that file here so there's **one source of truth**.
>
> **Owners:** Design-system sections: [Design lead / DS owner] · Code-convention sections: [Eng lead]
> **Last reviewed:** [date] · Changes go through PR review like code.

---

## 1. Read first

Before any UI work, read:

- `context/DESIGN.md`: visual identity and tokens
- `context/UX.md`: users, context of use, interaction standards
- `context/GLOSSARY.md`: required terminology

## 2. Design-system rules (owned by Design)

- **IMPORTANT:** Always use components from `src/components` (or `[package name]`). Never create a new Button, Input, Select, Modal, Toast, Card, etc. if one exists.
- **IMPORTANT:** If a needed component or variant does not exist, **stop and list what's missing** (name, purpose, where it's needed). Do not build ad-hoc UI.
- **Never hardcode** colours, spacing, radii, font sizes or shadows. Use tokens from `src/tokens/tokens.css` (`var(--…)`). If a token is missing, stop and ask; don't invent one.
- Match component props to Figma component properties (see Code Connect mappings).
- Implement **all states** defined in the design: empty, loading, error, disabled, focus, long content.
- **Accessibility (WCAG 2.2 AA):** labels on all inputs; visible focus on all interactive elements; logical tab order; text contrast ≥ 4.5:1; don't rely on colour alone; respect `prefers-reduced-motion`.
- **Copy:** sentence case; follow `context/GLOSSARY.md` terminology exactly; voice per `context/UX.md`.

## 3. Figma MCP flow (do not skip)

Adapted from [Figma's recommended rules](https://developers.figma.com/docs/figma-mcp-server/add-custom-rules/):

1. Run `get_design_context` for the exact node(s) linked.
2. If the response is too large, run `get_metadata` for the node map, then re-fetch only the needed nodes.
3. Run `get_screenshot` for a visual reference of the exact variant.
4. Only then implement. Download assets if needed. Don't add new icon packages; use assets from the Figma payload.
5. Treat MCP output (often React + Tailwind) as a **description of design intent, not final code style**. Translate it into this project's components and tokens.
6. Validate against the screenshot for look **and** behaviour before marking complete.

## 4. Code conventions (owned by Engineering)

- Framework: [e.g. React + TypeScript]
- Styling: [e.g. CSS Modules; no Tailwind; no inline styles unless necessary]
- File structure: components in `src/components/<Name>/`, screens in `src/screens/`
- Naming: [conventions]
- Tests: [what's required]
- State and data fetching: follow existing patterns in `[path]`

## 5. Workflow and safety

- Work on a **branch**; never commit directly to `main`.
- Show a summary of changes and the diff before committing.
- Don't add dependencies without explaining why.
- Never put secrets, keys or personal data in code, prompts or context files.
- Ask before running destructive commands.

## 6. Definition of done (UI)

- [ ] System components only; no hardcoded design values
- [ ] All states implemented
- [ ] Keyboard and focus verified; labels present; contrast OK
- [ ] Copy matches glossary and voice
- [ ] Visual parity with the Figma screenshot
- [ ] Summary of any missing components or tokens reported

## 7. Changelog

| Date | Change | Reason (drift log #) | Owner |
|---|---|---|---|
| | | | |

Template: UX.md

Copy this file as-is into your repository or context folder and edit it.

# UX.md: [Product name]

> **Purpose:** the experience knowledge that every AI tool (and every person) should use when generating anything for this product. Inspired by NN/G's UX.md hypothesis ([UX-Context Design](https://www.nngroup.com/articles/ux-context-design/)).
>
> **Owner:** [name, role] · **Last reviewed:** [date] · **Review cadence:** quarterly and after each research round
>
> **Related:** [DESIGN.md](./DESIGN.md) (visual identity) · [GLOSSARY.md](./GLOSSARY.md) · Components: `[path/to/components]` · Accessibility: WCAG 2.2 AA

---

## 1. Product in one paragraph

[What the product does, for whom, and the core value. 3–5 sentences.]

## 2. User models

### [Primary user, e.g. "Finance admin"]
- **Expertise:** [novice / intermediate / expert in domain; in the product]
- **Frequency and duration:** [e.g. daily, 2–4 h during month-end]
- **Goals:** [..]
- **Concerns:** [e.g. distrusts automation that changes numbers silently]
- **Prefers:** [e.g. density, keyboard shortcuts, tables over cards]
- **Doesn't work for them:** [e.g. wizards for routine tasks]
- **Design implication:** [e.g. "Optimise for density and efficiency; avoid hand-holding in routine flows."]

### [Secondary user]
- ...

## 3. World model (context of use)

- **Environment:** [desk, field, noisy, mobile on the go...]
- **Interruptions:** [e.g. frequently interrupted → must preserve state, allow resume]
- **Stress and stakes:** [e.g. errors cost money → confirmation for irreversible actions]
- **Compliance:** [e.g. every change must be auditable → show who changed what, when]
- **Devices and connectivity:** [..]
- **Design implications:** [..]

## 4. Research insights (as constraints)

> Write each as **insight → constraint**, with evidence strength.

| # | Insight | → Constraint for generation | Evidence |
|---|---|---|---|
| 1 | Users abandon setup when asked for info they don't have on hand | Never require external documents/IDs in first session; allow save-and-return | 12 interviews, 2026-Q3 |
| 2 | | | |
| 3 | | | |

## 5. Interaction standards

- **Confirm vs undo:** [e.g. undo (toast, 10 s) for reversible actions; confirmation dialog only for irreversible or bulk-destructive actions]
- **Errors:** [inline, next to the field; structure: what happened + what to do; never blame the user]
- **Loading:** [skeletons for content > 300 ms; never block the whole page for partial loads]
- **Empty states:** [explain value + one primary action; no dead ends]
- **Notifications:** [when to use toast vs inline vs banner; never interrupt with modals for info]
- **Forms:** [labels always visible; validate on blur; save drafts automatically]
- **Density:** [default compact for experts / comfortable for occasional users]
- **Keyboard:** [all primary actions reachable; shortcuts for frequent actions]

## 6. Content and voice

- **Voice:** [e.g. calm, precise, direct, no blame, no exclamation marks]
- **Case:** sentence case everywhere
- **Terminology:** follow [GLOSSARY.md](./GLOSSARY.md). Preferred terms override synonyms.
- **Numbers and dates:** [formats, locales]

## 7. Accessibility requirements

- WCAG 2.2 AA minimum
- Visible focus on all interactive elements
- Labels on all inputs; no placeholder-as-label
- Don't convey meaning by colour alone
- Respect reduced-motion preferences

## 8. Things AI tools should NEVER do here

- [e.g. invent new components when one exists → stop and list what's missing]
- [e.g. use "ticket" instead of "case"]
- [e.g. auto-submit financial changes without preview]

## 9. Changelog

| Date | Change | Trigger (research / drift / decision) | By |
|---|---|---|---|
| | | | |

Context Experiment: with / without context

Purpose: prove (and improve) the value of your UX context with evidence (Module 09).

Setup

• Date: · Tool and model: · Tester: · Blind scorer:
• Tasks (3 representative generation tasks): 1. 2. 3.
• Conditions:
• A: prompt only
• B: prompt + DESIGN.md
• C: prompt + DESIGN.md + UX.md (+ AGENTS.md / rules)
• Runs per condition: 2–3 (outputs vary)

Use the same base prompt for all conditions:

[paste base prompt]

Rubric (1–5 each)

Scores

Averages: A = __ · B = __ · C = __

Findings

• Which context moved which criterion?
• What did the AI still get wrong in condition C?
• Which context change would fix it?

Changes made and re-test

Evidence

Paste or link before/after screenshots here.

Drift Log

Drift = any difference between design-system intent and AI-generated output. Each entry should end with a rule or context change, so the same drift doesn't recur (Module 10).

Root-cause categories:

1. Rule: missing or unclear rule in AGENTS.md
2. Context: gap or ambiguity in DESIGN.md, UX.md or the glossary
3. System: missing component, variant or token
4. Figma: hygiene issue (raw values, bad names, unmapped component, missing description)
5. Model: genuine model limitation

Monthly review

Lead tip: category counts are your investment argument. For example: "60% of drift came from missing Code Connect mappings. Connecting the top 10 components is our next priority."

Design QA Checklist: AI-built or human-built UI

Use at Gate 3 (design QA on running UI: PR preview or staging). Copy into the PR comment and tick each item.

System fidelity

• [ ] Only system components used (no duplicates or ad-hoc look-alikes)
• [ ] No hardcoded colours, spacing, radii, type or shadows (tokens only)
• [ ] Correct component variants and sizes
• [ ] Matches Figma within agreed tolerance (spacing, alignment, type)
• [ ] Works in all modes (light/dark, density, brand)

States and content

• [ ] Empty state
• [ ] Loading state (and no layout jump)
• [ ] Error states (each type), with recovery action
• [ ] Disabled / read-only / permission-denied
• [ ] Long content, many items, zero items
• [ ] Copy matches voice; glossary terms correct; sentence case
• [ ] Numbers, dates and currency formatted correctly for the locale

Accessibility (WCAG 2.2 AA basics)

• [ ] Keyboard: all interactive elements reachable; logical order; no traps
• [ ] Visible focus on every interactive element
• [ ] Labels on inputs (not placeholder-only); buttons have meaningful names
• [ ] Contrast checked with a tool (4.5:1 text; 3:1 large text and UI components)
• [ ] Meaning not conveyed by colour alone
• [ ] Images have appropriate alt text (or are marked decorative)
• [ ] Target sizes adequate (≥ 24×24 CSS px; 44×44 recommended on touch)
• [ ] Reduced-motion respected
• [ ] Quick screen reader pass on the main flow

Responsive and robustness

• [ ] Agreed breakpoints checked
• [ ] Zoom to 200% without loss of content or function
• [ ] Text expansion (for example German) doesn't break the layout

Close the loop

• [ ] Drift found → logged in the drift log
• [ ] Missing component or token → contribution request filed
• [ ] New pattern → Figma, code, Code Connect and docs updated (or ticket filed)

Result: ✅ Approved · ⚠️ Approved with follow-ups · ❌ Changes requested

Designer–Developer Collaboration Contract

Team(s): · Design lead: · Eng lead: · Version: · Date: · Review: quarterly

Purpose: clear agreements for building UI together when designers, engineers, PMs and AI agents can all produce UI (Module 11).

1. Shared goals

We collaborate to ship usable, accessible, consistent UI faster, with evidence from real users, while keeping the codebase healthy.

2. Core principles

1. Design is accountable for the experience; engineering is accountable for production code.
2. Designers may write code for prototypes and propose changes via PRs; engineers review and own merging.
3. Prototypes are learning artifacts, not production code.
4. One design system, with Figma and code linked (tokens, Code Connect), owned jointly.
5. Agents follow AGENTS.md. Design owns the design-system sections and engineering owns the code-convention sections.
6. We discuss systems, not people: when something goes wrong, we fix the rule, context or component.

3. Ownership (RACI summary)

4. Review gates

5. Definition of done (UI)

• [ ] System components only; any new component went through contribution
• [ ] Tokens only (no hardcoded values)
• [ ] All states implemented
• [ ] Accessibility checks passed
• [ ] Copy matches glossary and voice
• [ ] Gate 3 passed; code review passed
• [ ] New patterns: Figma, code, Code Connect and docs updated
• [ ] Drift logged and rule or context change proposed

6. Contribution model

1. Check existing components and variants.
2. Submit a request: need, use cases, proposal.
3. DS team decides: one-off, new variant, or new component (SLA: __ days).
4. Build in Figma and code, plus Code Connect, docs and description.
5. Announce in the changelog; update rules and context if needed.

7. Rituals

8. AI-specific agreements

• Approved tools: see the Design Team AI Policy.
• Agents work on branches; humans merge.
• Write-to-canvas on shared libraries happens on duplicates or branches only.
• AI-generated UI meets the same definition of done as human-written UI.

9. Resolving disagreements

1. Return to user evidence and the shared goals.
2. If unresolved, design lead and eng lead decide together within __ days.
3. Escalate to [role] only if needed. Record decisions in [location].

Signed / agreed: Design lead ______ · Eng lead ______ · Date ______

Design Team AI Policy

Version: · Owner: [Design lead] · Approved by: [Security, Legal, Head of Product/Design] · Effective: · Review: quarterly

Scope: all design work, including research, design, content, prototyping and design-system work, by the design team and by others using design assets.

1. Why we use AI

[Strategy sentence: "We use AI to … so that … while protecting …"]

Goals: 1. 2. 3.

Non-goals: - We do not replace research with real users. - We do not measure designers by output volume or "% AI use". - We do not ship prototypes as production.

2. Principles

1. Humans are accountable for everything we ship.
2. AI drafts; designers decide.
3. Real users over synthetic users for evidence.
4. Verify in proportion to risk (low / medium / high tiers).
5. Accessibility is non-negotiable.
6. Transparency: disclose AI use where it matters (PACED: Policy, Audience, Context, Expectations, Degree).
7. Open standards first (MCP, DTCG tokens, markdown context) to avoid lock-in.

3. Approved tools

Requests for new tools go to [owner] and are evaluated against the tool selection criteria.

4. Data rules

• Use realistic synthetic data in prototypes by default.
• Context files (DESIGN.md, UX.md, AGENTS.md) contain no personal data or secrets.

5. Research

• AI may assist with planning, transcription and first-pass synthesis (approved tools, consent).
• Every insight must be traceable to real evidence (participant ID and reference).
• Synthetic users: allowed for pilot-testing materials and generating hypotheses; never as evidence for decisions.
• Researchers review all AI synthesis before sharing.

6. Verification tiers

7. Review gates and definition of done

See the Designer–Developer Collaboration Contract. AI-generated work meets the same bar as human work.

8. Agent permissions

9. Imagery, IP and licensing

• AI-generated imagery for production requires [brand/legal] approval and a tool licence that allows commercial use.
• Don't generate content imitating identifiable artists' styles or real people without approval.
• Fonts, icons and assets follow existing licensing rules.

10. Disclosure

• Internal: note substantial AI involvement in research reports and design rationale.
• External: follow legal requirements (for example EU AI Act transparency obligations) and PACED. Prefer proactive disclosure where it applies.

11. Learning and wellbeing

• [X] hours per week of protected learning time during adoption.
• Use of AI tools is encouraged, not mandated for specific tasks; outcomes matter.
• Concerns (ethical, quality, job-related) can be raised with [lead] at any time without penalty.

12. Incidents

If confidential or personal data is shared with an unapproved tool, or AI output causes harm: report it to [security contact] within [time]. We focus on fixing the system, not blaming people.

13. Changelog

AI Adoption Pilot Plan

Team: · Product area: · Duration: 4–6 weeks · Start: · Owner:

1. Why this pilot

[The problem or opportunity in 2–3 sentences, with evidence from your AI log, audits or team interviews.]

2. Hypotheses

3. Scope

• In: [workflows, tools, people]
• Out: [what we won't change]
• Data rules: per the AI Policy, with [specifics]

4. Baseline (collect before start)

• Past 2–3 sprints: [metrics]
• Sentiment pulse: [score]
• AI-readiness scorecard: [score]

5. Plan

6. Measurement

• Metrics collected by: [who / how]
• Qualitative: weekly 15-min check-ins; stories log
• Avoid vanity metrics: number of prompts, screens generated, "% AI"

7. Risks and mitigations

8. Decision criteria

• Scale if ≥ 2 hypotheses are met and sentiment is ≥ baseline.
• Adjust if mixed.
• Stop if quality or sentiment drops.

9. Results (fill in at the end)

Stories / quotes:

What didn't work:

Recommendation:

Team Skills Matrix: AI-native design

Rate 1–4: 1 Aware · 2 Practising · 3 Fluent · 4 Leading/teaching. Aim for T-shapes: everyone at ≥ 2 in the core rows; specialists at 3–4 in their area.

Development plan

My First 90 Days as AI-Native Design Lead

Role: · Company: · Start date: · Manager:

Days 1–30: Listen and baseline

Goal: understand before changing.

Output: "State of design and AI" memo (2 pages). Shared on: ____

Days 31–60: Foundations and pilot

Output: policy v1, contract v1, pilot launched.

Days 61–90: Evidence and roadmap

Output: pilot report, roadmap, exec update.

Risks I'm watching

Personal learning system

• Weekly (30 min): [sources]
• Monthly (2 h): try one new capability on a real task
• Quarterly: review policy, context and tools
• Yearly: re-run context experiments with new models

Glossary

Plain-language definitions of every term used in the course. The module where each term is taught is shown in brackets.

Agent (AI agent). An AI system that pursues a goal over multiple steps, using tools, checking results and iterating. For example, a coding agent that reads a Figma frame, writes code, runs it and fixes errors. [02]

AGENTS.md. An open-convention markdown file at the root of a code repository with instructions for AI coding agents. Other tools use CLAUDE.md, .cursor/rules/ or .github/copilot-instructions.md. [08]

Alias (token). A token that references another token, such as color.action.primary → {color.blue.600}. Aliases enable theming. [07]

Ambient context. Raw, uncurated information streams an agent can sift through, such as Slack, email or meeting transcripts. One of NN/G's three context roles. [09]

Articulation barrier. The difficulty users have expressing their intent in words to an AI. Hybrid prompt + GUI interfaces reduce it. [12]

Auto layout. Figma's layout system for responsive, content-driven frames. Essential for systematic components. [07]

Big ball of mud. A system "scraped together for short-term functionality, not architected for long-term durability". NN/G uses the term for over-grown AI context and agent setups. [09]

Branch (git). A parallel line of work in a repository. You change things safely without affecting main. [10]

Code Connect. A Figma feature linking design components to real code components, so Dev Mode and the Figma MCP server show and use production code. Comes in UI and CLI versions. [08, 10]

Code to canvas. A Figma MCP capability that captures live UI from a browser into Figma as editable but flat layers, without a library connection. [05, 10]

Collection (Figma variables). A group of variables, often with modes. [07]

Component properties. Figma's configurable component settings: variant, boolean, text and instance swap. These should match code props. [07]

Context. Everything a model can see when it does the work: the prompt plus instructions, standards, examples and background. [02, 09]

Context engineering. Curating, structuring, scoping and maintaining the context AI uses. It matters more than prompt wording. [09]

Context library. A collection of institutional and procedural knowledge (markdown files, databases, connections) that AI agents may reference and edit. [09]

Context window. The maximum amount of content (in tokens) a model can consider at once. [02]

Contribution model. The process by which teams propose additions or changes to the design system. [11]

Design QA. Reviewing built UI against design intent, the system and accessibility standards. [10, 11]

Design system. A shared set of decisions expressed as tokens, components, patterns, documentation and governance. [07]

Design token. A named design decision stored as data, such as color.bg.surface = #FFFFFF. [07]

DESIGN.md. An open format from Google Labs (alpha, April 2026) describing a product's visual identity to coding agents. It combines YAML tokens with markdown rationale. [08]

Dev Mode. Figma's mode for developers to inspect designs. It shows Code Connect snippets when they're configured. [08]

Drift. Any difference between design-system intent and AI- or human-generated output. Tracked in the drift log. [10]

DTCG. The W3C Design Tokens Community Group. It published the first stable Design Tokens specification (2025.10), a vendor-neutral JSON format. [07]

Fidelity trap. Mistaking a polished AI prototype for production-ready work. [06]

Figma agent. Figma's built-in AI agent in Figma Design, for generating, remixing, automating busywork and giving feedback. Since May 2026 it is the entry point for features that replaced "First Draft". [05]

Figma Make. Figma's prompt-to-interactive-prototype/app tool. [05, 06]

Figma MCP server. Figma's MCP server. It lets AI agents read design context and generate code, write to the canvas, capture code to the canvas, and use Make, FigJam, Code Connect and Specs. Available as remote (recommended) or desktop. [05, 10]

Figma Specs. Figma's (open beta) feature for requirements and specs that agents can read and update via the figma-spec skill. [05]

Global context. Information that rarely changes and shapes an agent's actions across tasks, such as principles, DESIGN.md and rules. [09]

Hallucination. AI stating false information confidently. [02]

HAX guidelines. Microsoft's 18 Guidelines for Human-AI Interaction. [12]

Intent-based interaction. A UI paradigm where users specify the outcome they want rather than the commands to get there. [12]

LLM (large language model). A model trained on large amounts of text (and often other media) to predict plausible continuations. It is the basis of most generative AI tools. [02]

Local context. Information scoped to a specific task or project, such as a feature brief or Figma frame. [09]

MCP (Model Context Protocol). An open standard for connecting AI applications to tools and data sources. [02]

Mode (Figma variables). Alternate values for the same variables, such as light/dark or compact/comfortable. [07]

Mode collapse. AI outputs clustering around a narrow set of typical answers, with less variety than real humans. [02]

Multimodal. Able to process or generate several media types (text, images, audio). [02]

Non-determinism. The same input producing different outputs on different runs. [02]

PACED. NN/G's framework for deciding on AI disclosure: Policy, Audience, Context, Expectations, Degree. [04, 12]

PAIR Guidebook. Google's People + AI Research guidebook for designing AI products. [12]

Pilot. A small, time-boxed, measured trial of a new practice before scaling it. [13]

Primitive token. The raw value tier, such as blue.600. [07]

Prompt. The instruction or request given to an AI model. [03]

Pull request (PR). A proposal to merge changes from a branch, with review. [10]

RACI. Responsible, Accountable, Consulted, Informed. A framework for clarifying ownership. [11]

RAG (retrieval-augmented generation). Retrieving relevant documents and adding them to the context before generating. [02]

Rules file. Project-level instructions an agent follows every time (see AGENTS.md). [08]

Semantic token. A token that expresses intent, such as color.text.danger. Components should use semantic tokens. [07]

Skill (agent skill). Packaged instructions and resources an agent loads when relevant, often a folder with a SKILL.md. Figma provides skills such as figma-use. [09]

Sycophancy. AI's tendency to agree with and flatter the user. [02]

Synthetic users. AI-generated stand-ins for research participants. Useful for pilot-testing materials, never as evidence. [04]

Token (LLM). A chunk of text (about ¾ of an English word) that models read and write in. Not the same as a design token. [02]

UX-context design. NN/G's term for discovering and curating what an organisation knows and wants into the context that guides everything its AI tools generate. [09]

UX.md. NN/G's hypothetical file (or folder index) holding UX context: research insights, user and world models, interaction standards and glossary. [09]

Variable (Figma). Figma's implementation of design tokens. [07]

Vibe coding. Informal term for building software mainly by prompting AI, with little manual coding. [06]

World model (UX). A description of the conditions users are in while using the product (interruptions, stress, compliance, environment). [09]

Write to canvas. A Figma MCP capability (beta) letting agents create and edit real Figma content with your components and variables via the use_figma tool. [05]

Resources

All links below were checked in October 2026. Prices and availability change, so re-check before buying.

Free: core reading (used in the course)

Research and practice (NN/G)

• AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings (2026 survey) and the comments dashboard
• UX-Context Design
• The 3 Roles of Context for AI Agents
• Context Libraries
• The New Big Ball of Mud
• Test Complex Interactions Earlier with AI Prototyping
• Synthetic Users vs. Human Respondents
• When Should You Disclose AI Use? PACED
• Study guide: How AI Works and How Users Think About It
• Study guide: Designing AI Products and Features
• AI topic hub

Figma (official)

• Figma MCP server: introduction
• Write to canvas · Code to canvas · Make resources via MCP
• Add custom rules
• Code Connect
• figma/mcp-server-guide (GitHub)
• Work with the Figma agent
• Use AI in your design workflows (collection)
• designsystems.com
• Figma Resource Library

Standards and formats

• Design Tokens Community Group (DTCG): first stable spec 2025.10
• DESIGN.md by Google Labs
• Model Context Protocol

Human-AI interaction guidelines

• Microsoft HAX Toolkit
• Google PAIR People + AI Guidebook

Free courses

Paid: optional upgrades (choose at most 1–2)

"About" prices were read from page data rather than visible text, so confirm them at checkout.

Staying current

• NN/G AI articles: weekly
• Figma Help Center and Figma developer docs: release changes
• Your coding agent's changelog
• Config (Figma's conference; Config 2027 is May 25–27, 2027)