Before AI Builds the Wrong Thing Beautifully

TL;DR: I made a small Design Spec Gatekeeper file for ux teams working with AI-assisted tools. It helps AI clarify user outcome, scope, constraints, states, edge cases, and acceptance criteria before generating UI, flows, components, or code. Try this on the next "vibe coded" behemoth prototype you are handed or tasked with creating.

Grab it here: GitHub

Ask an AI agent to “make this dashboard more actionable,” and it will probably give you something that looks cleaner: better spacing, more cards, sharper labels, maybe even working code.

But our job, as UXers, is still the same: Did we clarify the user’s next step? Did we preserve the product logic? Did we handle empty states, error states, permissions, loading, recovery, and edge cases? Did we stay in scope?

Will AI do this from your prompt? Mostly, er, sometimes, but only if you told it to.

AI is very good at making vague product ideas look finished. That is the problem.

This is where designers need to get much better at spec-driven UX. Not giant documentation. Not handoff theater. Just a lightweight UX spec that tells AI what problem it is allowed to solve.

Before asking AI to generate a screen, flow, component, or implementation, define who the user is, what they need to understand, what the primary action is, what is in scope, what is out of scope, what constraints already exist, what states and edge cases need to be handled, and what success looks like.

The workflow is simple:

1. Write the UX spec

2. Add EARS-style requirements

3. Add acceptance criteria

4. Ask AI to identify gaps before starting

5. Revise the spec if needed

6. Ask AI to propose the solution

7. Ask AI to implement only what is in scope

8. Review the result against the acceptance criteria

The most useful part for me has been EARS.

EARS stands for Easy Approach to Requirements Syntax. It is a way to turn vague intent into clear, testable requirements.

The basic pattern is: WHEN something happens, the system SHALL respond in a specific way.

Or: IF a condition exists, the interface SHALL handle it in a specific way.

For UX work, that shift is huge.

Instead of writing, “Make the empty state more helpful,” write: “IF no results are available, the interface SHALL explain what was searched and provide one clear next step.”

Instead of writing, “Make the dashboard more actionable,” write: “WHEN a user lands on the dashboard, the interface SHALL make the highest-priority action visible without requiring the user to interpret every metric.”

Instead of writing, “Make AI results feel trustworthy,” write: “WHERE information is inferred, the interface SHALL label it as inferred rather than presenting it as fact.”

That gives the AI agent something concrete to work against. Not taste. Not polish. Not vibes. Behavior. A requirement. A pass/fail check.

This matters most on large AI-assisted projects, where prototypes grow fast and product logic gets blurry. A prototype may show the happy path but not the failure path. It may show the populated state but not the empty state. It may show the screen but not the rules behind it. It may look complete while still missing critical UX requirements.

That is where designers can add real leverage. We can define the product intent before AI turns unclear intent into polished UX debt.

That is the shift I care about: designers are not just prompting AI to make better screens. We are defining the product logic, constraints, states, and acceptance criteria AI needs in order to build the right thing.