How would you set and uphold a standard for scenario abstraction level across many teams?

### Why this needs a standard at all Within one team, scenario style settles by osmosis. Across a dozen teams sharing a domain, it does not: one team writes drag-and-drop narration, another writes sentences so abstract that the example has evaporated, and a reader moving between them cannot tell what the product promises. The cost is not tidiness. It is that the format's entire justification — prose a non-programmer can judge — only holds if the prose is consistently at a level a non-programmer can judge. ### Name both failure modes, not one Most standards on this topic say "be declarative" and stop, which produces the second failure mode within a quarter. Steps like "a valid playlist exists" or "the editor updates it" pass every declarative style check while hiding the exact data and the exact event the rule turns on. A scenario that could be satisfied by three different behaviours is not a specification; it is a slogan with a run time. The standard must be explicit that the target is *concrete about the domain, silent about the mechanism*, and that vagueness is a defect of equal weight to narration. ### Make the standard testable Rules about vocabulary are unenforceable and get argued about. Questions are enforceable, because two reviewers usually agree on the answer: 1. **The change test.** If the interaction changed and the rule did not, would this sentence need editing? A yes means the sentence describes mechanism. 2. **The ambiguity test.** Could two materially different behaviours both satisfy this step? A yes means it has abstracted away the rule. 3. **The stranger test.** Could someone who has never used the product say whether the rule is *right*, not merely whether it is described? 4. **The incidental-detail test.** Does the rule turn on this fact? If not, delete it — a creation date on a playlist in a scenario about ordering is a fact a future reader must decide about. These four fit on a card, and they replace an argument about wording with an argument about the rule, which is the argument worth having. ### Uphold it with exemplars and vocabulary, not tooling Automated checks can catch a small tail — banned mechanical verbs, steps over a length, a scenario with more than one When — and it is worth having them because they cost nothing to run. They cannot detect the important failure, which is a well-formed sentence that specifies the wrong thing. So the real instruments are three. *Exemplars.* Two or three scenarios from the teams' own domain, published as the shape to copy, with a short note on why each step is worded as it is. People imitate; give them something worth imitating. *A shared vocabulary of domain nouns.* Most abstraction drift starts with two teams naming the same concept differently and a third inventing an interface noun to bridge them. A short glossary — owner, editor, collaborator, shared playlist, editing rights — makes the declarative wording available, and the absence of such a list is usually why steps default to mechanics. *Review by someone who is not the author.* Scenario wording is a review artefact, not a build artefact. The single highest-leverage practice is that a person who did not write the scenario reads it aloud and asks whether the rule is right. ### Allow documented exceptions A standard with no exceptions gets ignored wholesale the first time it is wrong. Mechanics belong in the text when the mechanics are the rule — reordering that must work without a pointing device, or a confirmation that must be deliberate. Write the exception into the standard with an example, and require that such a scenario says why in one line, so exceptions stay deliberate rather than becoming the drift they were meant to prevent. ### The inherited corpus Most organisations asking this question already own hundreds of interface-script scenarios. A rewrite project is almost always the wrong answer: it consumes capacity, produces no new behaviour, and is abandoned halfway, leaving two styles instead of one. Better to freeze the old corpus under the old style, require the new standard for anything written from today, and rewrite a scenario when the rule it covers changes anyway — the moment when someone must understand it regardless. Track the mix if you like, but do not manage to the number; the goal is that the scenarios people actually read are readable. ### What you are trading away Be honest in the interview about the cost. A stricter, more declarative standard widens the gap between the sentence and the mechanics beneath it, and someone has to keep that translation truthful. When a team's scenarios are read by nobody outside the team, that gap buys very little, and the right principal-level call may be to say so rather than to enforce a standard whose benefit never arrives.