Interaction is about behavior
A prototype shows what things look like, not how to use them. Write the behavior down, or the builder can only guess.
Information architecture decides where things sit; interaction decides how users move across them — what a click does, what happens next, what to do on error. A prototype shows what the information and features look like, but not "how to use it." What happens when a button is pressed, when it is disabled, how many characters an input accepts — none of that is in the picture. If you do not write it down, the person building it can only guess, and so can the AI. Interaction design fills in the half of the spec that never makes it into the drawing.ixd
What you'll run into:
- You drew the screens, but every handoff turns into a Q&A about details
- It runs fine until a boundary case shows up: overflowing text, a missing required field, no network
- You hand the AI a screenshot and it reproduces the look — then invents the behavior
What it covers
Interaction notes cover three areas.
| Area | What to spell out |
|---|---|
| Page flow | How screens link, what triggers a jump, where you enter and how you get back |
| Content layout | Which modules each screen has, what form they take, what shows in each state, plus field specs (required?, type, length, default, hint text) |
| Actions and feedback | What each element can do, what feedback the system gives, what the limits are, how errors are handled |
The most commonly skipped piece is the field spec in the second row. Leave length and required rules vague, and the form falls apart on real data.
One more that is easy to forget: keep the loop closed while you draw. Every screen must explain how you arrive and how you leave. Dead ends are invisible in a prototype — after launch, the only way out is to quit and restart.
Seven things to spell out
When annotating a prototype, these seven are the ones worth writing. Cover them all and the build will not drift, whoever picks it up.
| Type | Example |
|---|---|
| Made-up terms | Define words you invented. "A shortcut is a button that jumps straight to a page." |
| Device differences | "The bottom nav is a fixed tab bar on iOS and a swipeable tab bar on Android." |
| Character limits | "Nicknames: 10 characters max, letters, digits, and underscores only." |
| Component type and priority | "Comments are multi-line and high priority — they must stand out." Single-line or multi-line, input box or search box: say it. |
| Result of an action | "After tapping Like, the button enters the liked state and the count goes up by one." |
| Page states | "The cart has three states: empty, has items, error." |
| Required fields | "Username, password, and email are required; the next step stays locked until they are filled." |
Colors, sizes, spacing, and shape do not belong here — that is the visual layer's job. Interaction notes only cover behavior and rules. Complete does not mean long: one line per item, enough to remove ambiguity. The real test is whether someone else can build it without asking you anything.
A note for AI
Put these seven into the spec and the AI no longer has to guess the behavior. The template below works for any new screen and takes about ten minutes to fill in.
PROMPT · Interaction notes
Build this page: [page name and purpose]
Screen structure: [description, or attach a screenshot]
Interaction rules — follow these strictly, do not improvise:
- Character limits: [length and allowed characters for each input]
- Component types: [single-line/multi-line, input box/search box/dropdown]
- Result of actions: [what happens after each button is clicked]
- Page states: [list every state and what triggers it]
- Required fields: [which are required, and what the button looks like when empty]
- Entry and return: [where users come from, how they get back]
Also:
- Use the project's existing design system for colors, sizes, and spacing. Do not invent new ones.
- For any behavior not covered above, ask me first — do not decide on your own.
- When done, run a self-check against the rules above, item by item,
and tell me which ones you confirmed and which ones you missed.
The last line is a cheap acceptance check: have it report against the checklist itself — faster than clicking through each one. If it nails the look but the behavior is all invented, the spec lacked behavior descriptions. Map the seven categories onto your screen and start over.