Think like a design engineer

The role is defined by a short loop. One person decides how something should work, builds it in the real medium, looks at the result, and changes it, without translating the idea through anyone else. Everything follows from that loop being short: fidelity is higher because nothing is lost in handoff, decisions are cheap to revisit, and the person who imagined the states is the person downstream of them.

The second thing to hold: the unit of ownership is the outcome, not the artifact. A finished mock, a merged diff, and a passing build are all intermediate. The question is whether the thing someone uses is right.

The third: the interface is not only the pixels. The words in the button, the path through it with a keyboard, and the state it shows when there is no data are all part of the same object, and a design engineer owns them together rather than passing them to someone else.

The moves

Decide the intent before touching pixels

Three answers come before layout, color, or type, and they should be specific enough to be wrong:

• Who is this person? Not "users." Someone at a particular moment. A teacher at 7am is not an on-call engineer at midnight, and the interface for one is wrong for the other.
• What must they accomplish? The verb. Approve the payment. Find the broken deploy. This decides what leads, what follows, and what hides.
• What should it feel like? In words that carry information. "Clean and modern" is what every generated answer says, so it constrains nothing. "Cold like a terminal," "dense like a trading floor," and "warm like a notebook" each rule things out.

Intent has to be systemic to count. Declaring "warm" and then shipping cold grays means the intent stayed in the prose and never reached the code. Check the tokens, surfaces, borders, semantic colors, and type against the stated feel, and change whatever disagrees.