A model can hand you a dashboard that looks like it shipped from a Series C company with a real design team, and that same dashboard can quietly tell a user to delete their account when they meant to log out. Both things are true at the same time, and the gap between them is the single most important idea in this entire program. It is the difference between a system that generates what design looks like and a designer who understands what design is for. This lesson teaches you to see that gap on sight, to name the three usability errors a generated mock most reliably hides, and to walk away with a five-question audit you can pin into any Figma file and run in ninety seconds.

The Galileo Dashboard That Fooled the Room

Start with a scene you have probably lived. It is a Thursday design review. A junior IC opens a Galileo-generated analytics dashboard on the big screen and the room makes the small approving noise designers make when something looks finished. The spacing is even. The type scale is clean. The chart colors are tasteful in that slightly desaturated way that reads as "enterprise." Somebody says "this looks great, ship it." And for about forty seconds, everyone believes it.

Then the senior product designer in the corner asks one question: "What happens when a user clicks the red button in the top right?" Silence. The red button is a primary-weight call to action sitting exactly where, on every other screen in the product, the destructive "delete workspace" action lives. Except here it says "Save view." The model put a save action in the muscle-memory location of a delete action, gave it the visual weight of a primary CTA, and colored it with the same alarm-red it had seen ten thousand times in its training data next to the word "delete." The dashboard looks right. It behaves wrong. Nobody in the room caught it on looks alone, because looks were never the problem.

This is not a story about a bad model. Galileo is a genuinely capable text-to-hi-fi tool, and by 2026 the visual quality of generated screens is frequently indistinguishable from hand-built work. That is precisely why this matters. When the output stops looking like a robot made it, the only defense left is a human who understands the difference between a plausible-looking interface and a usable one. That human is you. This lesson is about making sure you can still tell.

What "Generation" Actually Is, in Plain Terms

Here is the mechanism, stripped of math. A generative model is a probability engine. It has been trained on an enormous corpus of designs, screenshots, UI kits, and the relationships between them. When you prompt it with "a SaaS analytics dashboard," it does not retrieve a dashboard and it does not reason about your users. It produces, piece by piece, the arrangement of elements that is statistically most consistent with everything it has seen labeled "dashboard." It is, in the most literal sense, an averaging machine that has gotten extraordinarily good at producing convincing averages.

Think of it like a session musician who has played ten thousand gigs and can sit in with any band and sound great for the first eight bars of any genre. Ask for a blues shuffle and you get a flawless blues shuffle, because the patterns are deep in the hands. But the session player has never heard your song. They do not know that the bridge is supposed to feel like a held breath, or that the whole point of the chorus is the one note that breaks the pattern. They play what blues usually sounds like. A generative model designs what dashboards usually look like. The craft you spent years building is exactly the part that lives in "this specific song," and that is the part the average cannot reach.

Why the Average Looks So Good

The reason generated work looks polished is that visual polish is, mostly, a high-frequency pattern. Consistent spacing, a sensible type scale, restrained color, aligned grids: these appear in nearly every well-made design in the training set, so the model reproduces them reliably. Polish is common, and common is exactly what an averaging machine is best at. This is wonderful news for the first eighty percent of a mock and a trap for the last twenty, because the last twenty percent is where the decisions that actually serve a user live, and those decisions are specific, contextual, and rare.

Put differently: the model is excellent at the things that are true across most designs and unreliable at the things that are true only for this design, these users, and this moment in the flow. Hierarchy under unusual density, the right affordance for a destructive action, the copy that prevents a costly mistake, the empty state that teaches instead of apologizes: these are low-frequency, high-stakes, and that is the model's blind spot.

What "Understanding" Actually Is

Understanding, in the design sense, is the ability to hold a model of the user's intent in your head and check the interface against it. When you look at that red "Save view" button, you do not see a colored rectangle with a label. You see a person who is three clicks into a frustrating afternoon, scanning for the thing that gets them out, reaching for the position where "the big obvious action" has always lived, and you flinch on their behalf because you know that this time the big obvious action is the wrong one. That flinch is understanding. The model does not have it. It has no user in its head because it has no head; it has a probability distribution.

This is why the framing that matters is not "AI versus designers." It is "generation versus understanding." A generated mock is a hypothesis about what the screen should look like, produced by a system that has never met your user. Your job is not to compete with it on production speed. Your job is to be the understanding it lacks. You are the part of the system that knows what the screen is for.

The model produces what design looks like. You supply what design is for. Confusing the two is how a beautiful mock ships a broken product.

The Three Errors a Generated Mock Reliably Hides

Across hundreds of generated screens, the failures cluster. If you only have time to check three things before a generated mock advances, check these three. They are the ones that look fine and are not, and they are the ones that cost the most when they reach a user.

Error One: Two Primary Actions Competing at Equal Weight

The model has seen countless screens with a prominent primary button, so it reliably produces a prominent primary button. What it does not reliably do is enforce the rule that a screen should have exactly one. Generated screens frequently ship two or even three elements at primary weight: a filled "Save," a filled "Publish," and a filled "Share," all the same size, same color, same prominence, sitting in a row. Visually it is balanced and pleasant. Functionally it is a paralysis machine. The whole purpose of visual hierarchy is to answer the user's unspoken question, "what is the one thing I should do here?" Two primary buttons answer "we don't know either."

You catch this by asking a question the model cannot: what is the single most important action on this screen, and is it the only thing that looks most important? If a secondary action (cancel, back, share) carries the same visual weight as the primary one, you have found the error. The fix is trivial once you see it: demote the secondaries to outline or text buttons. The model will not do this on its own because "balanced row of equal buttons" is a high-frequency, good-looking pattern in its training data. Balance looks like design. Hierarchy is design.

Error Two: A Destructive Action Where Users Expect a Safe One

This is the red "Save view" button from our opening scene, and it is the most dangerous of the three because the cost lands on the user, not on you. Models routinely misplace destructive actions because their sense of "where the important button goes" is purely positional and chromatic. They learned that the big bold button goes top-right or bottom-right, and they learned that important buttons are often red or filled. They did not learn that red plus top-right plus primary weight is the universal signal for "this is irreversible, be careful," and that putting a routine save action there is like labeling the fire exit "supply closet."

The detection move is to inventory every action that changes or destroys data (delete, remove, archive, cancel-subscription, reset) and ask: does its visual treatment and position match its consequence? Destructive actions should be visually distinct, should require confirmation proportional to their blast radius, and should never sit in the spot a user reaches for by reflex when they want something safe. A generated mock will get this right by accident sometimes and wrong by accident often, which is the same as getting it wrong, because you cannot trust a coin flip with your user's data.

Error Three: A Desktop Convention That Shatters at the Mobile Breakpoint

The third error is the sneakiest, because it is invisible until you change the viewport. Generated screens are usually produced at one canvas size, and the model borrows whatever navigation and layout patterns are most common at that size. A persistent left sidebar with twelve nav items, a three-column data table, a hover-reveal action menu: all gorgeous at 1440 pixels wide, all catastrophic at 390. The hover menu has no hover on touch. The twelve-item sidebar has nowhere to go. The three-column table forces a horizontal scroll that hides the column the user actually needs.

You catch this by mentally (or actually) resizing every generated screen to a phone and asking what happens to each pattern that depends on width or hover. The model did not consider the breakpoint because you did not show it the breakpoint, and even if you had, responsive behavior is a low-frequency, high-effort pattern it handles poorly. This one is worth a habit: never approve a generated layout without asking "and on a phone?" The answer is where the average breaks.

The Generated-Mock Audit: Five Questions, Ninety Seconds

Here is the artifact this lesson exists to give you. Pin it as a sticky in your Figma file, drop it in your team's review template, or tape it to your monitor. Run it against any generated screen before it advances. It is built so that anyone on the team, including a PM or an engineer, can run it, which is the point: the audit externalizes the understanding the model lacks so it does not live only in your head.

1. One primary? Is there exactly one element at primary visual weight, and is it the single most important action on the screen? If two things compete, demote one.
2. Destructive actions safe? Does every data-changing or destructive action look and sit like its consequence? Nothing irreversible should occupy the reflex position of something safe.
3. Survives the phone? Resize to 390 pixels wide. Does every nav, table, menu, and hover pattern still work, or does something depend on width or hover that a touch screen does not have?
4. Real content, real states? Replace placeholder copy and the happy path with the longest realistic string, an empty state, an error state, and a loading state. Does the layout hold, or was it only designed for "Hello, John"?
5. Whose job, and why? For the one decision that matters most on this screen, can you state the user's intent it serves and the evidence behind it? If the only justification is "the model put it there," it has not been designed yet.

Notice what these five questions have in common: not one of them is about whether the screen looks good. They are all about whether it behaves right, because looks were never in doubt. The audit is a deliberate counterweight to the polish that makes generated work so persuasive. You are training your eye and your team's eye to distrust the very thing the model is best at, and to interrogate the things it is worst at.

A Worked Example: Auditing a Generated Onboarding Screen

Let us run the audit on a real-shaped example so the abstraction becomes muscle. Imagine you prompt a tool for "a clean SaaS onboarding screen, step two of three, collecting workspace details." It returns something lovely: a centered card, a friendly heading, two input fields (workspace name, workspace URL), a filled "Continue" button, a filled "Skip for now" button beside it, a small "Back" text link, and a cheerful illustration of three identical smiling avatars.

Question one, one primary? No. "Continue" and "Skip for now" are both filled, both the same size. The model produced a balanced pair. But these actions are not equal: continuing completes setup, skipping abandons it. Demote "Skip for now" to a text link. One error found.

Question two, destructive safe? "Skip for now" is not destructive exactly, but it silently discards the user's progress, and as a filled button next to "Continue" it invites the misclick that loses their work. Treating it as low-emphasis also solves the consequence-mismatch. Confirmed.

Question three, survives the phone? The two side-by-side filled buttons will either crowd or wrap awkwardly at 390 pixels, and the centered card with a large illustration pushes the actual form fields below the fold on a small screen. The user has to scroll past a decorative illustration to reach the thing they came to do. Second error found.

Question four, real content and states? The workspace URL field shows "acme" as placeholder. What does it show when the URL is taken? When the name is 60 characters? When the network request to check availability is in flight? The generated mock has no error, no loading, no taken-URL state. It designed the happy path and nothing else. Third and largest gap found.

Question five, whose job and why? The most important decision here is whether to even ask for a workspace URL at step two. Is that serving a real user need, or did the model include it because onboarding screens in its training data often collect URLs? If your research says users do not care about the URL until later, the most "designed" move is to cut the field entirely. The model cannot make that call. You can.

In ninety seconds, a screen that "looked great, ship it" produced three structural fixes and one strategic question. None of them were visible on looks. All of them were visible through the audit. That is the entire job in miniature.

Why This Is Not an Anti-AI Lesson

It would be easy to read all of this as a case against using generative tools. It is the opposite. The designer who understands the generation-versus-understanding gap is the one who can use these tools hardest, because they know exactly what to delegate and what to guard. Let the model produce the polished first pass in nine seconds; that genuinely is a gift, and fighting it is nostalgia, not craft. Then spend the time you saved on the three errors and the one strategic question, which is where your value was always concentrated anyway.

The designers who get hurt in 2026 are not the ones who use AI. They are the ones who mistake the model's polish for understanding and ship the average. The job is not to out-type the machine. The job is to be the part of the system that knows what the screen is for, and to make that knowledge legible, repeatable, and fast enough to keep up with a tool that produces a new mock every nine seconds. The audit is how you do that.

The Deeper Pattern: Frequency Versus Stakes

If you internalize one mental model from this lesson, make it this two-by-two. On one axis, how frequently does a pattern appear in training data. On the other, how high are the stakes of getting it wrong. The model is reliable in the high-frequency quadrants regardless of stakes, and unreliable in the low-frequency quadrants regardless of stakes. The danger zone is low-frequency and high-stakes: rare situations where being wrong is expensive. That is exactly where destructive-action placement, dense-data hierarchy, edge-case states, and novel interaction patterns live.

Your audit, your verification habits, and your craft attention should concentrate in that quadrant. Do not waste your scarce attention double-checking the type scale; the model nails the type scale because type scales are everywhere in the training data. Spend your attention where the data is thin and the cost is high. This single reallocation of where you look is most of what separates a designer who is accelerated by AI from one who is quietly degraded by it.

Putting It to Work This Week

Before your next design review, do three things. First, save the five-question audit somewhere you will actually see it, ideally as a pinned component in your team's Figma review file so it shows up next to every generated screen. Second, the next time anyone presents a generated mock, run the audit out loud; modeling it once for the team is worth more than any process doc, because it shifts the review conversation from "does this look good" to "does this behave right." Third, when you find an error, name the category ("that is a competing-primary error" or "that is a desktop pattern that breaks on mobile") so the vocabulary spreads. Named errors get caught faster the second time.

You will know it is working when a teammate beats you to the catch. When the junior IC who generated the dashboard says "wait, that red button is in the delete position" before you do, you have transferred understanding into the room. That is the actual deliverable of L1: not that you can spot the broken mock, but that your whole team can, fast, every time, so the polish of generated work never again gets mistaken for the substance of designed work.

Key Takeaways

• Generative models produce what design looks like by averaging their training data; they do not produce what design is for, because they hold no model of your user's intent. The gap between the two is where good-looking mocks hide broken products.
• Visual polish is a high-frequency pattern, so models reproduce it reliably. The decisions that serve users are low-frequency and high-stakes, so models handle them poorly. Concentrate your attention in the low-frequency, high-stakes quadrant.
• The three errors a generated mock most reliably hides: two primary actions competing at equal weight, a destructive action placed where users expect a safe one, and a desktop pattern that breaks at the mobile breakpoint.
• Run the five-question Generated-Mock Audit before any generated screen advances: one primary? destructive actions safe? survives the phone? real content and states? whose job and why? None of the five is about whether it looks good.
• This is not anti-AI. The designer who understands the gap delegates the polished first pass to the model and spends the saved time on the errors and the strategy, which is where their value was always concentrated.
• The deliverable of this skill is not your own catch rate; it is transferring the understanding into your whole team so the audit runs fast and every time, and polish is never again mistaken for substance.