How do you spec the states a static mockup can’t show?

You spec the states a static mockup can’t show by enumerating them deliberately, loading, empty, error, success, hover, focus, disabled, and the transitions between, and then defining each one rather than leaving it implied. The mockup captures a single moment, usually the happy one where data has arrived and everything is full and correct. The spec has to cover the rest of the component’s life. The method is to treat every state a user can actually reach as something you owe a definition, not something the developer will figure out.

The reason this matters is that a static frame is structurally incapable of showing a lifecycle. It shows one instant, and an instant cannot contain the moment before the data loads, the moment the request fails, the moment the list is empty because the user is new, or the moment a control is focused by keyboard. Those are not decorations on the default; they are distinct conditions the interface will genuinely be in, often for real users on real days. If you only design the default, you have not designed a component, you have designed its best photograph, and the developer will improvise the rest under deadline pressure, which is how inconsistent and broken states ship.

Enumeration is the core discipline because the states you forget are the ones that hurt. Walk the component and ask what conditions it can be in. It can be loading while it waits. It can be empty when there is nothing to show, and a first-time empty differs from a search-returned-nothing empty. It can be in error, and a field-level error differs from a whole-component failure. It can be in success after an action. Its interactive parts have hover, focus, active, and disabled treatments. And it moves between these, so the transitions are states too. Listing them forces the invisible ones into the open, where they can be designed instead of left to chance.

A concrete case shows the gap closing. Take a table of search results. The mockup shows five tidy rows, and that is the only state in the file. The full spec adds the loading state, a skeleton or spinner while results come in, with a note on what triggers and ends it. It adds the empty state with its own message and guidance, distinct for no results yet versus your search matched nothing. It adds the error state for a failed request, with the message and any retry. It defines row hover and focus, the disabled look of any action that is not currently available, and how the table transitions from loading to populated so it does not flash or jump. The mockup showed one of these. The spec showed all of them, and now there is nothing left to invent.

One limit is worth stating: reachability, which keeps enumeration from sprawling. You are documenting the states a user can actually arrive at in this component, not every theoretical permutation of every combination. If a control cannot be both disabled and in error at once, you do not owe that hybrid a definition. The goal is full coverage of the real lifecycle, not a combinatorial explosion, so define the states that exist and the transitions that occur, and let impossible combinations stay impossible. Completeness means every reachable state, not every imaginable one.

To make this routine, build a small states checklist and run every component through it before handoff: loading, empty, error, success, plus the interaction states of each control, plus the transitions that connect them. For each state that the component can reach, define how it looks, what triggers it, and what ends it. Enumerate and define every reachable state instead of designing the default and trusting the rest to be obvious, and the handoff stops being a single photograph and becomes the full description of how the thing lives.