It's tempting to open the design tool and start laying out screens. Screens are satisfying, they look like progress. But for any product with real complexity, the screen is the last thing that should be decided, not the first.

Underneath every interface is an interaction model: the set of states the system can be in, the decisions a user can make in each, the feedback the system gives back, and what happens when something goes wrong. Get that right and the screens almost design themselves. Get it wrong and no amount of visual polish will save the experience.

What the interaction model actually defines

Before a single screen exists, these are the questions worth answering:

The interaction model
01States. Every distinct condition the system can be in, loading, empty, partial, error, success, low-confidence.
02Decisions. What the user can do in each state, and what the system decides on their behalf.
03Feedback loops. How the system tells the user what happened and what it's doing now.
04Control. Where the user can intervene, correct, undo or override.
05Confidence. How certainty is communicated, and how it changes what the interface should do.
06Failure modes. What a good experience looks like when things go wrong, not just the happy path.

Why screens-first quietly fails

When you design screens first, you implicitly design only the states you happened to draw. The "perfect result" screen looks great. Then engineering asks: what about when there are zero results? Partial results? When the user disagrees? When it's still loading after five seconds? Each of those is a state you never designed, bolted on late as an afterthought.

The result is a product that's beautiful in the demo and brittle in real use. The cracks are always in the states nobody modelled.

The interface is a projection of the interaction model. Design the model and the screens become obvious. Design the screens and the model becomes accidental.

How to model before you draw

The tools here are deliberately low-fidelity, because their job is thinking, not polish:

  • State inventory. List every state the system can be in. The boring ones, empty, error, partial, are where the real design lives.
  • Decision map. For each state, what can the user do and what does the system do automatically? This surfaces the control model.
  • Feedback pass. For every action, what does the user see, hear or feel in response? Silence is a design decision too.
  • Failure walk. Walk each path assuming it breaks. The dignity of your failure states is most of your product's perceived quality.

Only once that skeleton holds together do I move to screens. And when I do, the screens are fast, because every hard decision has already been made. The layout is just dressing a structure that already works.

This is why prototypes beat specs

An interaction model is much easier to validate when it behaves than when it's described. A clickable prototype that moves through real states, including the ugly ones, tells you in minutes what a 40-page spec can't. The model is the thinking; the prototype is how you pressure-test it.

Start with the logic. The interface is the easy part once the model is sound.