Stating interface tasks

how to put into words what you see with your eyes

What it is

The interface is the only thing in this book that you conceive visually and have to describe in text. Hence a particular difficulty: the picture is in your head, the AI gets words, and the discrepancy only shows up when you look at the result.

This article is about narrowing that gap.

What to tell the AI

Four parts, as everywhere

The same parts as in article 3.2, but with their own content:

Describe states, not appearance

The chapter's key technique. Any screen with data has at least four states, and by default an AI builds only one — the happy one.

A subscriptions list screen. Four states:

1. Loading — a skeleton of three cards
2. Empty — the text "No subscriptions yet" and an "Add" button
3. Data — the list of cards
4. Error — the error text and a "Retry" button

All four must be implemented, not only the third.

Make a subscriptions list

The second request will give you only the third state. Loading, emptiness and the error turn up later — as bugs, for users.

Name the structure, not the pixels

A card 320 pixels wide, 18 of top margin, a 17px heading

A card: the city's name, the temperature large underneath,
a "Remove" button at the bottom. Cards in a row, and in a
column on a narrow screen. Spacing from the existing
variables, don't introduce new values.

Pixels are magic numbers (article 8.3): fitted to one screen, they fall apart on another.

Give a signature

For React the signature is the props interface, and it works just as it does in articles 6.5 and 9.5:

A component to this interface:

interface SubsListProps {
  subs: City[] | null;        // null = still loading
  error: string | null;
  onRemove: (name: string) => void;
  onRetry: () => void;
}

All four states are visible from the types — implement them.

That is the most compact form of a task: the types describe the possibilities by themselves.

Ask in parts

A whole screen in one request is five tasks in one (article 3.16). Better in steps:

1. the card component with prop types;
2. the list with loading and empty states;
3. error handling and retry;
4. responsiveness.

After each step, look at it. That is cheaper than taking apart a finished screen in which something is wrong.

What to look for

Only the happy state is built. Easily checked: turn off the network and see what is on the screen.

Invented spacing and sizes. If the project has variables or a spacing scale, new values are a mismatch.

The component doesn't reuse the existing ones. An AI will happily write its own button instead of the one already in the project. That is reason 2 from article 3.1 — it simply hasn't seen it.

Invented wording. "Sorry, something went wrong" instead of text in the voice and style the rest of the interface uses.

Accessibility forgotten. The same divs instead of buttons, no labels on fields (article 8.2). React doesn't fix that.

Cheat sheet