Understanding Generative AI Methods

Welcome to Introduction to Generative AI. If your work involves drafting design specs, writing release-note UX copy, preparing research-synthesis notes, communicating with stakeholders, or running usability sessions, generative AI is already becoming part of the UX design workflow. In this first unit, you'll build a plain-language mental model for what generative AI does, how it works, and where it can go wrong.

You'll cover:

• The five major AI capabilities: text generation, image generation, image description, web search, and automation
• The three main model families: large language models, diffusion-style image models, and multimodal models
• Key limitations like context windows and hallucinations, plus why human verification matters

Before any AI-assisted design task, run the Responsible AI Use Checklist:

• Approved Tools: Use only tools approved for your design work.
• Safe Inputs & Confidentiality: Never paste confidential product roadmaps, unreleased research, or participant data; use sanitized or fictional inputs instead.
• Privacy & Consent: De-identify participant details and verify consent before using research assets.
• IP, Copyright & Likeness: Do not feed in or reproduce protected assets, brand logos, or recognizable likenesses without permission.
• Human Review & Verification: Verify all factual claims before they leave the team, apply human review before anything ships, and escalate outputs that carry accessibility, brand, or accuracy risk.
• System of Record: Remember that AI chat sessions are not a system of record.

When people say "AI," they may be talking about five different capabilities, and mixing them up can lead you to use the wrong tool for the job.

The practical move: before you open a tool, name which capability you actually need. "I need a design-spec draft" is text generation. "I need a concept moodboard" is image generation. "What's in this usability screenshot?" is image description. Asking the wrong tool the right question is a top reason people decide AI "doesn't work."

A scope note for this course: web search and automation are covered as capability awareness only, not hands-on skills. Treat AI "current-info" research as a starting point that still requires verification against an authoritative source, and keep a firm line between drafting support (a human ships the output) and automation that triggers actions or changes records (which requires approval, auditability, and is out of scope here).

Three model families sit underneath those capabilities, and a rough mental picture of each will save you a lot of guesswork.

Large language models (LLMs) power text generation. Picture an extremely well-read autocomplete: given everything you've typed so far, the model predicts the most likely next word, then the next, then the next, all the way to the end of the response. It learned these patterns from massive amounts of human-written text. It doesn't "understand" your design system the way you do; it pattern-matches at a scale that feels like understanding. That's what's drafting your design specs and release-note UX copy.

Diffusion-style image models power image generation. Think of them as starting with a screen of static (random noise) and gradually "uncrumpling" it into a coherent picture that matches your description, one denoising pass at a time. They learned what a "clean, minimal product mockup" looks like by training on millions of captioned images. That's what's producing your concept mockups and moodboards.

Multimodal models can take in more than one type of input, like text plus an image, and reason across them. That's what lets a single tool answer "what's happening in this usability-test session screenshot?" or "read this competitor screen and describe the checkout flow." Capabilities like image description and most modern chat tools live here.

While LLMs operate on text and diffusion models generate images, multimodal models bridge the gap by accepting and reasoning across multiple input modalities at the same time—most commonly combining text prompts with images.

Think of an LLM as having ears and a voice for text, while a diffusion model is an artist holding a canvas. A multimodal model connects those senses into a unified reasoning system. Rather than treating visual elements and language as separate domains, it maps images (such as wireframe sketches, user flow diagrams, or usability-testing screen recordings) into the same conceptual space as text.

In UX design, this unlocks workflows that neither text nor image generation could handle alone:

• Usability Session Analysis: Uploading a screenshot of a user struggling during a usability test and asking the model, "What UI elements on this screen might be causing cognitive overload or confusion?"
• Interface Inspection: Providing a competitor's checkout flow screen and prompting, "Describe the step-by-step interaction pattern and highlight any accessibility contrast issues."
• Design System Verification: Uploading a component mock and asking whether its button sizing, spacing, and label hierarchy match your team's documented guidelines.

When you practice explaining AI models to your teammate Jake, emphasize this key distinction: multimodal models don't just "look" at an image to create another picture; they understand visual context and discuss it with you in plain language.

Here's the part that trips up UX designers specifically. A general-purpose model has read a huge slice of the public internet, but it has never seen your actual design system, your real user-research findings, or what your accessibility and brand teams have approved. So it fills those gaps with the average of everything it has seen — and "average" is exactly what your product is not. There are three things you almost always have to supply, then verify:

• Your actual design system and brand guidelines. Left alone, the model writes a generic, plausible-sounding design spec or release note that may contradict your team's agreed-upon patterns. Any system-specific detail in a handoff or stakeholder message has to come from your real guidelines — not the model's best guess.
• Your real research findings. Asked for a usability summary or a competitive-analysis note, the model will invent a plausible metric, participant behavior, or product feature rather than admit it doesn't know. Any claim about users or competitor products must trace back to an authoritative source (a session recording, a published spec, or the product itself).
• What you can accurately and responsibly say. The model doesn't know your accessibility obligations, your NDA boundaries, or what's been brand- and accuracy-cleared. It will cheerfully write an accessibility-compliance claim or a competitor-feature comparison with nothing behind it. Accuracy and responsibility are your job, never the model's.

Keep these three gaps in mind — they're the reason the next section matters so much for design work.

Because LLMs predict the next likely word, they will happily produce a confident, well-formed sentence even when the underlying claim is false. That's called a hallucination: an output that sounds factual but is unsupported, inaccurate, or invented.

A hallucination might be a fabricated competitor feature, an invented design-award credit, a metric a study never measured, or a confident description of a product flow that doesn't exist. The model is not "lying" on purpose; it is generating a plausible pattern. That's why hallucinations are not a bug you can fully prompt your way out of; they're a property of how the model works.

Another term worth noting is a context window: everything the model can "see" in your current conversation, including your prompt, any pasted notes, and its own prior responses. Past that window, it has no memory. And because the model is optimizing for plausible-sounding output, the most dangerous hallucinations are the polished ones: feature claims, benchmark figures, design-award credits, and competitor details that look exactly right in a design review or a stakeholder presentation.

Here's what that looks like in a normal design task. Jake used an AI tool to draft a short competitor profile from a few bullet facts for a design-sprint prep note, but the draft included a specific award he didn't recognize. He asks Emily, a senior designer with more experience reviewing AI output, what to do with it.

• Jake: I asked it to write a quick competitor profile and it gave me this line about a 2023 Core77 Usability Award. Looked totally real.
• Emily: Did the bullet points you gave it mention any award?
• Jake: No, I just gave it the product name, a rough description, and one or two features I knew.
• Emily: Then the model filled the gap with whatever sounded plausible. That's a hallucination, not a fact.
• Jake: So I need to verify anything it added that I didn't put in?
• Emily: Exactly. If you didn't give it the information, treat it as a claim to check — not a fact to paste into a design review.

Notice the move: Emily didn't argue with the output, she traced it back to what was in the prompt versus what the model invented.

In most jobs, a hallucination is an embarrassing mistake. In design work, a polished one can become a shared, decision-driving claim about a competitor, a user, or a product. A fabricated feature, an invented usability metric, or a misattributed design-award credit isn't just wrong — it can steer a design sprint in the wrong direction, erode stakeholder trust, and create NDA or accuracy problems if the document circulates. That's why the verification bar is higher than in casual drafting: anything that wasn't in your prompt gets confirmed against an authoritative source before it goes into a design review, a handoff, or a stakeholder presentation.

The single most important takeaway from this unit: generative AI doesn't retrieve truth, it generates plausible patterns, so your value as the designer in the loop is to pick the right capability, supply what the model can't know (your real design system, your real research findings, your accuracy and responsibility guardrails), and verify what came out before anything is shared or acted on.

Everything above is theory until you have to explain it to someone else in plain English. Your next step is a live roleplay where a curious design teammate asks you how this stuff actually works: your job is to make the three model families stick using everyday analogies, no jargon allowed.