The Death of the Static Mockup: Designing in the Final Medium
Keep the visual frame, then specify what happens next. Try one preview across idle, loading, interrupted and ready states.
Published Updated
A static mock-up is excellent at making a visual decision discussable. It can establish hierarchy, composition and tone without the cost of a working application. The problem begins when we treat that frame as a complete description of the experience. A screen is one arrangement of information; an interface also has to explain what happens next.
The missing frames are often the important ones
Consider a project preview. The finished view is easy to present: an image, a title and a link. But someone first has to open it. They may wait, encounter an interrupted load, retry or leave before the response arrives. If the specification only includes the successful frame, those decisions still get made—just later, with less attention.
In this portfolio, the real image viewers and embedded previews have loading, failure and recovery behaviour. The smaller example below isolates that idea. It is a teaching interaction with a controlled timer, not a reconstruction of a shipped client flow or a test of your connection.
Try the same task in four states
Local interaction example. An 800 ms timer stands in for a response; no request is sent.
Ready to open the Pure Chocolate project preview.
Start with Available and open the preview. Then select Interrupted and run it again. The failure message should explain what happened, preserve the selected project and offer a next step. Change the response back to Available and retry. Reset returns the example to its starting point and cancels a pending timer.
Scroll sideways or focus the table and use arrow keys →
| State | What the interface owes the reader |
|---|---|
| Idle | Name the selected project and the action. |
| Loading | Acknowledge the action; prevent duplicate starts; allow reset. |
| Interrupted | Explain the problem without losing context; offer retry. |
| Ready | Provide the promised destination and a clear next action. |
Use the browser to expose a design question
The example keeps the primary button in the document through every state. Its label changes, but keyboard focus does not need to jump to a new control. Status text sits in a polite live region. The choice controls are native radio buttons, so selection and keyboard behaviour do not depend on a hand-built tab interaction. These are design decisions made visible in the medium where they have to work.
A timed example cannot cover a real request’s security, timeout policy, caching or failure modes. Nor does a live region alone establish assistive-technology compatibility. The WCAG explanation of status messages is a useful starting point for deciding which changes need an announcement without moving focus. Real browser and assistive-technology checks still matter.
Keep the mock-up; broaden the deliverable
I do not need every early idea to become production code. A prototype should resolve a question: does a loading state preserve confidence, can an error be recovered from, or does the composition survive real text at a narrow width? Build only enough fidelity to answer that question, then record what remains untested.
The static frame still contributes art direction. A state table contributes completeness. A working slice contributes observable behaviour. Together they offer a stronger handover than any one of them alone. The packaging viewers show how that principle translates into the actual site: finished imagery, close inspection, a way out and a recovery path when the asset cannot load.