Yeda AI Tips · #112

AI-Generated UIs Skip the Empty States — Prompt for Every One

AI built your UI's happy path. Your users live on the sad path. Ask a coding assistant for "a dashboard with a list of orders" and you'll get a beautiful screen — for the one case where the data loaded instantly, the list has 8 tidy rows, and nothing went wrong. First-run users see a blank void. Slow networks see a flash of nothing. Failed requests see silence. None of that was in the prompt, so none of it is in the code.

States, not edge cases

Every data-driven view has at least five states, and only one of them is "happy":

Loading — the request is in flight.
Empty — the request succeeded and returned zero items.
Error — the request failed.
Partial / overflow — too much content: 10,000 rows, a 300-character name, a title that wraps three times.
Ideal — the screenshot state. The only one AI reliably builds.

These aren't edge cases; they're the default experience for new users (empty), mobile users (loading), and everyone eventually (error). Nielsen Norman Group's guidance on empty states is blunt: a blank container leaves users unsure whether the app is broken, loading, or waiting on them — a well-designed empty state communicates status, teaches, and links to the next action.

Prompt for them explicitly — every time

The fix costs one sentence. Append it to every UI prompt:

Build the orders table. For every data-driven component, implement
all of: (1) a loading state with skeleton placeholders that reserve
the final layout's space, (2) an empty state with one line of copy
and a primary action, (3) an error state with a human-readable
message and a Retry button, (4) sensible handling of overflow —
long strings truncate with ellipsis, lists over 50 items paginate.

Rules of thumb per state:

State	Show	Don't
Loading	Skeleton in the final layout's shape	Spinner centered in a void
Empty	1 line of copy + a "create/import" action	The bare word "No data"
Error	What failed, in human words, + Retry	A raw stack trace or nothing
Overflow	Truncation, wrapping rules, pagination	Layout that breaks at 200 chars

Skeletons: reserve the space

Loading states aren't just decoration — they prevent layout shift. web.dev's CLS guidance says it directly: reserve sufficient space in advance (placeholder or skeleton UI) so loaded content doesn't shove the page around; a good Cumulative Layout Shift score is 0.1 or less. NN/g's skeleton-screen research adds calibration: skeletons earn their keep on full-page loads of roughly 2–10 seconds; under ~1 second they're unnecessary, and past ~10 seconds a progress bar beats both. Prefer static skeletons over shimmering ones, and match the skeleton to the real layout — same card heights, same column widths — or you've just moved the reflow.

Power-user moves

Make states a definition of done. Add "all five states implemented" to the acceptance criteria in your task file or CLAUDE.md-style project instructions, so every generated component inherits the requirement without re-prompting.
Demand a state-forcing harness. Ask the AI to also generate a dev toggle or Storybook stories that force each state (?state=empty, ?state=error). If you can't render a state on demand, you can't review it.
Test the sad path with sad data. Seed fixtures with zero rows, 10,000 rows, 300-character strings, and emoji. Overflow bugs never show up in ["Alice", "Bob"].
Steal copy patterns from design systems. Shopify Polaris's EmptyState component doc is a ready-made spec: explain the benefit, one clear primary action, simple language. Point your AI at a pattern like it instead of letting it improvise.
Never collapse reserved space. web.dev warns that removing a placeholder's space causes as much layout shift as inserting content — the error and empty states should occupy the same box the skeleton did.

Resources

Building an AI feature? Yeda AI designs, audits, and ships production LLM systems.

Talk to us · Read the blog