When people say a model "hallucinated," they usually picture a chatbot inventing a court case. In design work the hallucination is quieter and, in some ways, more dangerous, because it arrives wearing a clean type scale and a confident filled button. A generated mock will hand you a component that does not exist in your system, copy that confidently mislabels a destructive action, and an accessibility claim that is simply false. All three look correct. None of them are. This lesson names the three hallucination flavors you will meet in design output, gives each one a fast detection move, and leaves you with a Hallucination-Flavor Cheat Sheet you can pin in Figma and run against any AI screen before it reaches a review.

Why Design Hallucinations Hide Better Than Text Ones

A text hallucination is easy to catch once you know it can happen. You read "Smith v. Jones, 2019" and you go check the citation, and either it exists or it does not. The claim is legible, so the lie is legible. Design hallucinations do not work that way. A generated interface is a single confident image where the invented parts and the real parts are rendered with exactly the same polish. The made-up component has the same shadow as the real one. The wrong copy uses the same friendly tone as the right copy. The false accessibility claim sits in a tidy little badge that says "AA" in the same font as everything else. There is no visual seam between truth and fabrication, because the model rendered both with the same averaging machine that makes everything look finished.

Picture the UI designer on a Wednesday, rebuilding a Galileo-generated dashboard against the team's real design-system tokens before a Thursday review. They open the generated file, and it looks shippable. The trap is that "looks shippable" and "is buildable against our system" are different claims, and a hallucination lives precisely in the gap. The dashboard references a component called PrimaryCardButton. It is beautiful. It is also entirely fictional. It does not map to any token, any Code Connect entry, any Storybook story. The designer who trusts the render will spend Thursday morning explaining to engineering why half the spec cannot be built. The designer who knows the three flavors catches it Wednesday in thirty seconds.

Flavor One: The Invented Component

The first and most common flavor is the component that does not exist in your system. The model has seen thousands of design systems, so it has a deep, fuzzy sense of what a "card button" or a "segmented filter chip" or a "split action menu" tends to look like. When it generates your screen, it confidently composes one of these averaged components and gives it a confident name: PrimaryCardButton, GhostTabBar, ElevatedListRow. The name sounds like it belongs in a real library. It has the cadence of a real token. It is invented.

This matters because a generated mock is supposed to be a buildable artifact, and a buildable artifact has to map to something real - a token, a component, a Code Connect mapping that ties the Figma node to the actual coded component. The invented component breaks that chain silently. Nobody notices in the review because the render is gorgeous. Engineering notices three days later, when they go to build it and discover there is no PrimaryCardButton in the repo, only a Button with a card variant that behaves differently and looks slightly off. Now the spacing drifts by 2 pixels, the focus ring is wrong, and the conversation in the next review is about whether the AI did the right thing instead of whether the design is right.

Detection Move: Name It Against the Library

The detection move is mechanical and fast. For every component on the generated screen, ask one question: does this map to a real entry in our design system? Not "does it look like ours," but "can I point to the exact token, the exact component, the exact Code Connect mapping." If you can name it, it is real. If the only name it has is the one the model gave it, it is a hallucination. With the Figma MCP server and Code Connect, you can make this even sharper: the components that resolve to real code mappings are real, and the ones that resolve to nothing are invented, full stop. You do not need to argue about taste. You need to ask whether the thing exists.

The corrective is to rebuild the invented component out of real primitives or to make a deliberate decision to add a new component to the system, with a contribution PR, rather than smuggling a fictional one into a spec. The point is that the addition becomes a choice you made, documented, instead of an accident the model made, hidden.

Flavor Two: Plausible-but-Wrong Copy

The second flavor is microcopy that reads fluently and means the wrong thing. This is the most insidious of the three because the cost lands on the user, not on you, and it survives review most easily, since people read interface copy the way they read a stop sign: they recognize the shape and move on without parsing it. The model writes "Click here to save your changes" on a button that, in your flow, actually discards them. It writes "Remove" on an action that permanently deletes with no recovery. It writes "Continue" on a step that silently submits a payment. The grammar is perfect. The tone is on-brand. The meaning is a lie about what the button does.

The model produces this because copy, like layout, is generated from frequency. "Save your changes" is one of the most common phrases in its training data near a primary button, so it reaches for it whenever a primary button needs a label, regardless of whether this particular button saves anything. The model has no model of the action's actual consequence, because it has no model of your flow. It is pattern-matching a label to a button shape, not describing a behavior.

A generated label is a guess about what the button usually does, dressed as a statement about what this button does. The two are only the same by luck, and luck is not a content strategy.

Detection Move: Read the Verb Against the Consequence

The detection move is to ignore how the copy reads and check what the action does. For every action label on the screen, state the real consequence in plain words, then compare it to the verb the model chose. "This button permanently deletes the record" versus the label "Remove" - those do not match, because "remove" implies reversibility that does not exist. "This silently discards everything the user typed" versus "Save" - a direct contradiction. The mismatch is the hallucination. You are looking for the cases where the verb promises one outcome and the system delivers another.

The corrective patterns are well known once you go looking: name the object and the consequence ("Delete invoice" not "Remove"), reserve "Save" for things that actually persist, and make irreversible actions say so. The discipline is to never let a generated label ship without one human stating, out loud, what the button actually does and confirming the words match. The forty seconds this takes is the difference between a user who knows what they clicked and a support ticket that begins "I didn't realize it would delete everything."

Flavor Three: Fabricated Accessibility Compliance

The third flavor is the one that can cause real legal and ethical exposure: the model claims accessibility compliance that is false. You ask a tool to generate "an accessible, WCAG AA-compliant settings panel," and it cheerfully returns a panel with a little note or a confident assertion that it is AA-compliant. It is not. It cannot be, because the model produced an image, not a tested, focusable, screen-reader-navigable interface, and many WCAG success criteria are about behavior the static render cannot demonstrate.

The classic example is WCAG 2.4.11, Focus Appearance. The generated panel may have lovely contrast on its text - the model is genuinely good at contrast math, which is a high-frequency, computable thing - but it has no real focus indicator, or the focus indicator it drew is too thin, too low-contrast, or obscured. The model claimed AA and failed a specific AA criterion, because compliance is not a vibe the model can emit; it is a set of testable conditions across keyboard operability, focus visibility, target size, motion, and reading order that a flat mock simply cannot satisfy by existing.

Detection Move: Treat Every Compliance Claim as Unverified Until You Test It

The detection move is a hard rule: an accessibility claim from a generative tool has exactly zero evidentiary weight. Treat "AA-compliant" from a model the way you would treat "trust me" from a stranger. The claim is not a finding; it is a placeholder for a test you still have to run. Tab through the actual built interface and watch for a visible, sufficiently strong focus indicator on every interactive element. Check target sizes against the criterion. Check that the reading order matches the visual order. Run the contrast math yourself rather than trusting the badge. The model's contribution to accessibility is, at best, a decent starting contrast palette. Everything else is your test, on the real thing, or it is fabricated.

The motion designer auditing a Runway-generated transition against WCAG 2.3.3 and prefers-reduced-motion lives this constantly: the generated motion looks delightful and respects no reduced-motion preference at all, because the model rendered a single happy-path animation and has no concept of the user setting that should suppress it. "Accessible" was never tested; it was asserted. Your job is to convert every assertion into a test or strike it from the spec.

Why These Three Flavors Cluster Together

It is worth seeing why these are the three, and not some random list. They map onto the three layers where a design has to be true rather than merely plausible. The invented component is a hallucination of structure - the screen claims to be made of things your system contains and is not. The wrong copy is a hallucination of meaning - the screen claims an action does one thing and it does another. The fabricated accessibility claim is a hallucination of compliance - the screen claims to meet a standard it has not been tested against. Structure, meaning, compliance: three different kinds of truth, three different ways the average can be confidently wrong.

Each one is invisible to a looks-based review for the same underlying reason. The model renders the lie and the truth with identical polish, so visual scanning cannot separate them. Each one therefore needs a verification move that does not rely on looking: name it against the library, read the verb against the consequence, and test the claim instead of trusting it. The common thread is that you stop asking "does this look right" and start asking "is this specific thing actually true," which is the entire discipline of verifying AI work compressed into a design-shaped form.

The Hallucination-Flavor Cheat Sheet

Here is the artifact this lesson exists to give you. Pin it as a sticky in your Figma file or drop it into your team's review template. It is built so anyone, including a PM or an engineer, can run it against a generated screen, because the understanding has to live in the room and not only in your head.

1. Invented component (structure). For every component, ask: does this map to a real token, component, and Code Connect mapping in our system? If its only name is the one the model gave it, it is invented. Rebuild from real primitives or open a deliberate contribution PR.
2. Plausible-but-wrong copy (meaning). For every action label, state the real consequence in plain words and compare it to the verb. If the verb promises a different outcome than the system delivers, rewrite it to name the object and the consequence. Never let "Save," "Remove," or "Continue" ship unread.
3. Fabricated accessibility (compliance). Treat any "AA-compliant" or "accessible" claim as unverified. Tab the real build for visible focus appearance (2.4.11), check target size, reading order, reduced-motion, and run contrast yourself. The claim is a test you owe, not a finding you can quote.

Notice that none of the three checks is about whether the screen looks good. They are about whether the structure exists, the meaning is honest, and the compliance is real. That is the whole point. The cheat sheet is a deliberate counterweight to the polish that makes generated work so easy to wave through.

A Worked Example: Running the Cheat Sheet on a Generated Billing Screen

Imagine you prompt a tool for "a clean, accessible billing settings screen where users can update their card and cancel their plan." It returns something tidy: a card-on-file row, an "Update payment method" button, a prominent filled "Remove" button beside the plan, a small badge reading "WCAG AA," and a confident component name in the layers panel, PlanActionCard.

Flavor one, invented component. PlanActionCard does not exist in your system. You have a Card primitive and a Button with variants, but no PlanActionCard, and no Code Connect mapping resolves it. Hallucination of structure confirmed. You rebuild it from Card plus Button, or you decide, deliberately and in writing, to propose it as a new system component.

Flavor two, wrong copy. The filled "Remove" button next to the plan does not remove anything in a reversible sense; it cancels the subscription at period end and deletes the payment method. "Remove" undersells an irreversible, money-affecting action and invites the misclick. You rewrite it to "Cancel plan" with a confirmation that names the consequence and the date. Hallucination of meaning caught.

Flavor three, fabricated compliance. The "WCAG AA" badge is decorative. You tab through the built version and the "Update payment method" button has no visible focus ring, failing 2.4.11. The cancel confirmation traps focus incorrectly. The claim was asserted, never tested. You strike the badge, fix the focus appearance, and only then describe anything as conformant - and even then, as "tested against AA on these criteria," not as a vibe.

In under two minutes, a screen that looked shippable produced one structural fix, one meaning fix, and one compliance fix, none of which a looks-based review would have surfaced. That is the cheat sheet earning its place in your file.

This Is Not an Anti-AI Lesson

It would be easy to read three flavors of confident fabrication as a reason to stop using generative tools. It is the opposite. The designer who can name the flavors is the one who can move fastest, because they know exactly which parts of the output to trust and which to interrogate. Let the model produce the polished first pass and the decent contrast palette; those are real gifts. Then spend the time you saved running the cheat sheet, which is where your judgment was always the load-bearing thing.

The designers who get hurt in 2026 are not the ones who use AI. They are the ones who cannot tell an invented component from a real one, a confident label from an honest one, or an asserted standard from a tested one. The job is to be the verification the model cannot perform on itself, and to make that verification fast, shared, and routine enough to keep pace with a tool that generates a new convincing screen every few seconds.

Key Takeaways

• Design hallucinations hide better than text hallucinations because the model renders fabrication and truth with identical polish; there is no visual seam, so looks-based review cannot separate them.
• The three flavors map onto three kinds of truth: invented components hallucinate structure, plausible-but-wrong copy hallucinates meaning, and fabricated accessibility claims hallucinate compliance.
• Detection move for invented components: name every component against a real token, component, and Code Connect mapping. If its only name is the one the model gave it, it is fictional.
• Detection move for wrong copy: state the action's real consequence in plain words and compare it to the verb. Mismatch is the hallucination. Never ship "Save," "Remove," or "Continue" unread.
• Detection move for fabricated accessibility: treat every "AA-compliant" claim as an unverified test you still owe. Tab the real build for focus appearance (2.4.11), target size, reading order, and reduced-motion; run contrast yourself.
• Run the Hallucination-Flavor Cheat Sheet on any generated screen before it advances. None of the three checks is about looks; all three ask whether a specific thing is actually true.
• This is not anti-AI. Naming the flavors lets you delegate the polish and the contrast palette to the model and concentrate your scarce judgment on the structure, meaning, and compliance the model reliably fabricates.