The most important design question is not how the screen should look.

It is how the thing should work.

That sounds obvious until you inspect how many product teams still treat behavior as an engineering detail. The designer owns the screen. The engineer owns the logic. The product manager owns the requirement. Everyone assumes the experience will emerge from the combination.

It rarely does.

A product is a set of behaviors. It responds to input. It reveals state. It handles missing information. It asks for decisions. It makes tradeoffs visible or hides them. It creates confidence or confusion through the way it moves, waits, fails, remembers, and recovers.

Those behaviors are the product experience.

A design engineer starts there. Before polishing the surface, they ask what the product is supposed to do in the user's hands. What is the moment of intent? What does the system know? What does it not know? What should be automatic? What should require confirmation? What should be reversible? What should the user understand before taking the next step?

This changes the design process.

The work becomes less about producing a set of ideal screens and more about defining a behavioral model. The designer has to think in states, transitions, permissions, loading behavior, error recovery, edge cases, and feedback. The artifact is not only a picture. It is a theory of how the product behaves.

That theory needs pressure.

A beautiful flow can collapse when real content is long, permissions differ, data arrives late, or users move out of order. A design that looks simple can be operationally ambiguous. A design that seems flexible can create too many decisions. A design that feels elegant in a deck can become slow once implemented.

This is why the design engineer needs build proximity. Working software reveals the truth earlier. It shows the designer where the behavior is under-specified. It exposes the parts of the product that were being held together by imagination.

The better question in review is not "do we like this screen?"

The better question is: does the product behave well under real conditions?

That includes boring conditions. Empty accounts. Long names. Bad permissions. Failed syncs. Half-completed setup. Partial data. Slow networks. Conflicting edits. Users who do not read instructions. Users who come back after three weeks and forget what they were doing.

Design quality lives in those moments.

The old version of design could sometimes avoid them until late implementation. The design engineer cannot. Their job is to make the behavior legible before the team commits to it.

This does not make design less creative. It makes creativity more consequential. The designer is no longer only arranging visible elements. They are shaping the user's mental model of the system.

The operator test: can the designer explain the product as a state machine, not only as a set of screens?

If they can, the team has a chance to build the intended experience. If they cannot, engineering will invent behavior under deadline pressure. Sometimes that works. Often it creates accidental product decisions that no one owns.

Design begins when someone decides how the thing should work.

This is where many design critiques become too shallow. A team debates the shape of a page while leaving the object model unresolved. It argues about whether the primary action should be blue while no one knows what should happen after the action succeeds halfway. It reviews typography while the permission model is still confusing. The visible layer is easier to discuss, so teams discuss it too early.

A design engineer keeps dragging the conversation back to behavior. What is the user trying to change? What does the system promise? What state does the user enter after the action? What does the product remember? What can be undone? What should be explained? These are not implementation trivia. They are the material of trust.

One useful exercise is to write the product in verbs before drawing it in boxes. Create, invite, approve, compare, recover, route, retry, archive, escalate. The verbs reveal the product's real shape. Once the verbs are clear, the screens have something to serve. Without that clarity, the interface may look finished while the product remains undecided.

Another useful exercise is to write the user's next sentence. After each interaction, what would the user say if they had to explain what just happened? "I sent the invite." "I need approval." "The sync failed, and I know how to retry." If that sentence is hard to write, the behavior is probably unclear. The design engineer uses that friction as source material.

This makes design more accountable. The product cannot hide behind a good-looking page if the user cannot predict what the system will do next.

The review question should change accordingly: can the team describe the product's behavior without pointing at the mock? If the answer depends on someone narrating the design, the product is under-specified. A design engineer helps turn that narration into observable behavior. The product should explain itself through state, copy, motion, sequence, and recovery paths.

That is a harder standard, but it is also a more useful one for real teams.

Evidence note: this series is inspired by Fahd Ananta's role-shift observation that designers will become design engineers: https://twitter.com/fahdananta/status/2056224470528885080

This is part 2 of 10 in The Design Engineer Era.