How do you tell a declarative scenario step from an imperative one?

### Two ways to say the same thing Take one rule from a music-streaming service: an editor of a shared playlist may reorder it, and every collaborator sees the new order. Written imperatively, the scenario opens a sign-in page, types a name and a password, presses a control, waits, opens a playlist by clicking a card in a grid, drags row nine to the top, and asserts that a confirmation appears. Written declaratively, it says a shared playlist holds 14 tracks, an editor moves the ninth to first position, and the order starts with that track for every collaborator. The second version has six fewer steps and one important property the first lacks: nothing in it mentions the product's current design. ### How to recognise which one you are reading *Nouns.* Imperative steps name interface parts — page, field, dialog, row, tab, control. Declarative steps name domain concepts — playlist, track, collaborator, editing rights, subscription tier. If you can delete the interface nouns without losing the rule, they were incidental. *Verbs.* Mechanical verbs — opens, clicks, types, drags, scrolls, presses — describe how a human drives a machine. Intent verbs — shares, reorders, removes, invites, revokes — describe what the actor is trying to achieve. The same underlying automation can sit behind either sentence. *The change test.* Would the sentence need editing if the interaction changed but the rule stayed identical? Replace drag-and-drop with a move-to-position menu: the imperative step is now false, the declarative one is untouched. This is the sharpest test, and it is the one worth saying out loud in an interview, because it explains the preference without appealing to taste. *The stranger test.* Hand the scenario to someone who has never used the product. Can they say whether the rule is right? A declarative scenario invites that judgement. An imperative one only lets them confirm that a path was described. ### Why the preference exists A scenario's audience is wider than a unit test's. It is meant to be readable by the people who decide what the product should do, which is the whole reason for the extra translation layer between prose and code. Imperative steps forfeit that benefit while keeping the cost: you now pay for a prose layer that only its author can review. Worse, the rule becomes invisible. A reader of the imperative version cannot tell whether the promise is "collaborators see the new order" or "a confirmation appears" — the assertion drifted to whatever was easiest to observe on screen. There is also a maintenance argument, though it is weaker than it looks. Declarative scenarios survive redesigns; imperative ones are rewritten every time a layout moves. But the mechanics still exist somewhere beneath the step, so a redesign still costs work — it is the *specification* that stops churning, not the automation. ### Where the line actually sits Declarative does not mean vague. "When the listener does the right thing" is not declarative, it is empty: two different behaviours could pass it. A good declarative step is concrete about the domain and silent about the mechanism. "When an editor moves the ninth track to first position" names an exact, checkable event without naming a gesture. Some incidental detail is worth keeping when the rule turns on it. If the rule is about ordering, positions belong in the text. If the rule is about permissions, the actor's role belongs in the text and the positions do not. The judgement is per rule, not global, which is why review matters more than a style rule here. ### When imperative wording is the right answer Three cases come up honestly. First, when the interaction is the subject: a rule about keyboard-only reordering, or about a confirmation step that must be dismissed deliberately, is genuinely about mechanics, and hiding them would hide the rule. Second, in a small number of thin end-to-end paths kept deliberately to prove the assembled system responds at all — but those are better written as ordinary automated checks than as business-facing scenarios. Third, temporarily, while a team is learning the format: a first imperative draft that gets rewritten in review teaches more than a rejected blank page. ### The failure this prevents The damaging version is not merely ugly. In an imperative scenario the assertion tends to slide toward whatever was easiest to see, so the suite ends up proving that the interface reacted rather than that the promise was kept. That is a suite that stays green while the promised behaviour is broken — the specific reason interviewers ask this question rather than treating step wording as a style preference.