Interaction Design

Structure decisions are cheap before code and expensive after. This skill is the pass between "we know what we're building" and "we're choosing colors": flows, screens, states, wireframes. A wireframe change after code exists costs ten times the same change before.

Know which level you're working at

If the evidence points above the level you were asked to work at (the flow is wrong, not the screen), say so before continuing. Don't silently redesign the product while restyling a page.

Model the domain before drawing anything

A flow drawn before the object model encodes guesses. Four lists first:

1. Objects: the nouns users think in (Invoice, Deployment, Member). When the UI's nouns differ from the users' nouns, the mental model breaks at the front door.
2. Relations: which object belongs to, contains, or references which. This is the navigation skeleton.
3. Actions × roles: per object, what each role can do to it. This matrix is the permission model; a screen showing an action the role can't perform is a designed error.
4. Placement: where each object lives in the information architecture, and the one path a user takes to reach it.

A flow is a role performing an action on an object. Flows come from this model; wireframes come from the flows. Skipping to wireframes is how you get five screens for one object and none for another.

One primary action per screen

Every screen has exactly one action the user came to perform. If you can't name it, the screen isn't ready to wireframe. Everything else on the screen is either input to that action or navigation away from it.

Every failure names its recovery. A journey where an error state dead-ends is unfinished, whatever the visuals look like.

Entities are sets of representations

A domain entity (Invoice, Deployment, Patient, Order) is not one component. It's a set of representations, one per context:

For each entity, list which representations it needs and on which screens. Representations nobody scans, browses, or picks don't get built. The same entity as a card on one screen and a row on another is normal; the same card pasted everywhere is a smell.

Wireframes: ASCII, cheap to throw away

Low-fi, in markdown. No color, no fonts, no spacing values. Boxes are zones; numbers are hierarchy order (1 = where the eye lands first). A wireframe you hesitate to throw away is too expensive.

Screen: Deployments — list
Flow: Dashboard → Deployments → deploy detail
Entities: Deployment(row), Project(badge)
Primary action: New deployment

+--------------------------------------------------+
| [logo]   Deployments (1)          [New deploy] 2 |
+--------------------------------------------------+
| [filter: env] [filter: status]         [search]  |
+--------------------------------------------------+
| ● api-prod      [proj]  2m ago   Live       ...  |  <- Deployment row 3
| ● web-staging   [proj]  1h ago   Failed     ...  |
| ● worker-prod   [proj]  3h ago   Deploying  ...  |
+--------------------------------------------------+
| (empty: "No deployments yet — connect a repo")   |
+--------------------------------------------------+

Wireframes carry real labels, real error copy, real domain data, never lorem: writing the actual words is how the structure gets tested, and the content-design skill works in parallel here, not after. An error message that needs three sentences won't fit the toast the flow assumed.

Every wireframe carries four annotations: screen name, the flow it belongs to, entity representations used, the primary action. Get the wireframe agreed before any token, component, or code work. For click-through fidelity, grayscale HTML with zero styling is the acceptable step up; a design tool is for iterating with a human, not for skipping the ASCII pass.

The state matrix — declared, not assumed

Generated UI ships the success state only. The fix is not a fixed checklist; it's a declaration. For every feature, walk the full vocabulary and mark each state designed or not applicable, because.... An unmarked state is an undesigned state the browser will design for you, badly.

Data states: initial, loading, populated, empty, partial (some items failed or are still coming), stale (shown data is old; say so). Outcome states: success, error (inline, attached to the failing element, names the recovery; not a toast). Availability states: disabled (with the reason when it isn't obvious), unavailable (feature off for this plan or context), permission-denied (what the role lacks and who to ask), offline.

Rules that hold across the matrix:

• Loading gets a skeleton matching the final layout shape, not a generic spinner, and reserves the space the content will take.
• Empty states speak domain language and offer the next action.
• filtered to zero results is not empty: different message, different action.
• "Not applicable" is an explicit decision someone can challenge, never a blank.

Interactive elements additionally always carry their interaction states, no declaration needed: hover (subtle, no scale(1.05)), active (translateY(1px) or scale(0.98)), focus (visible ring, 3:1 contrast), disabled.

Evidence discipline

Claims about users cite a source: analytics, support tickets, issue history, an actual test. A cognitive walkthrough is labeled as your assumption, never presented as a user test. No invented personas, no invented KPIs.