# The Design Operating Rules > Six rules for running a design practice where generation is cheap and judgment is > the constraint. Print it, fill in the blanks, hand it to your team on Monday. > Nobody needs to read the chapter first. Work top to bottom, and stop when you have > two rules with real owners. Two adopted beats six admired. --- ## How to use this Each rule has four parts: the rule, the failure condition that makes it checkable, the check itself, and a blank for your product. The failure condition is the part people skip and the part that does all the work. A rule without one is a principle, and principles have never stopped anyone from shipping anything. Fill the blanks against one real surface you are working on right now. Not the whole product. One surface. --- ## Rule 1. Write the constraint before anything gets made **Rule.** Every feature gets its constraints written down before generation starts. **Failure condition.** A constraint is only real if you can say what breaking it looks like. "Delightful" has no failure condition. "Any suggestion the user can accept in one click has an undo that is equally cheap" does. **Check.** Hand the constraint to someone who was not in the room. Ask them to point at the moment it was broken in a real output. If they cannot, rewrite it. **Yours.** | Constraint | What breaking it looks like | Who checks it | |---|---|---| | | | | | | | | | | | | Three is enough to start. Ten means you wrote principles. --- ## Rule 2. Design the range, not the screen **Rule.** For anything with generated output, specify three states instead of drawing one: the best case, the worst case you would still ship, and what the product refuses to do. Everything between the second and third is allowed and does not need review. **Failure condition.** If a reviewer cannot tell whether a given output is inside the range or outside it, the range is not specified yet. **Check.** Take ten real outputs. Sort them into best, acceptable, refuse. If two people sort them differently, the boundary is where you have work to do. **Yours.** | Surface | Best case | Worst acceptable | Refuses to | |---|---|---|---| | | | | | --- ## Rule 3. Put the judgment in a rubric so it executes without you **Rule.** The taste currently living in your Thursday review moves into something written, scored, and versioned. **Failure condition.** If quality decisions still require you in the room, the rubric does not exist yet, no matter what the doc is called. **Check.** Two people score the same five outputs independently. Compare. Where they disagree, the rubric is vague. Where they agree and both feel wrong about the score, the rubric is measuring the wrong thing. **Yours.** | Dimension | What failing it costs | Pass / fail test | |---|---|---| | | | | | | | | | | | | Three or four dimensions that each hurt when they fail. Not eight that measure vibes. --- ## Rule 4. Own the wrong path as a first-class surface **Rule.** Recovery, disclosure, confidence, correction, and trust repair get named owners and get designed before launch, not after the first incident. **Failure condition.** If the unhappy path was designed by whoever had capacity that sprint, this rule is being broken right now. **Check.** For your next feature, write the wrong-path spec before the happy path. If the team resists the order, that resistance is the finding. **Yours.** | Wrong-path surface | Owner | Designed before launch? | |---|---|---| | What the product does when it is unsure | | | | How the user sees what already happened on their behalf | | | | Undo, and the window before it expires | | | | What gets said in the thirty seconds after the system is confidently wrong | | | --- ## Rule 5. Spend the freed hours on evidence, not on more options **Rule.** Time recovered from production goes into knowing which direction is right, not into producing more directions. **Failure condition.** More untested options this quarter than last, with no corresponding increase in decisions closed. That is speed converted into noise. **Check.** Count two numbers for the last month: options generated, and questions answered with evidence. Write both down. Watch the ratio, not the absolute numbers. **Yours.** - Options generated last month: _______ - Questions closed with evidence last month: _______ - Which number do you want to move: _______ --- ## Rule 6. Move design upstream of generation **Rule.** Design sets the bounds before things get made. Review becomes a conversation about exceptions. **Failure condition.** If your design review is a tour of finished work, you are inspecting output. That is a QA function, and it is the most expensive place to find a problem. **Check.** Time your next two reviews. Upstream reviews run short because most of the argument already happened in the constraint doc. **Yours.** - Last review length: _______ - What percentage was spent on work already built: _______ --- ## The adoption plan Six rules adopted at once is six rules adopted badly. 1. Pick the two rules that matter most for what you are building this quarter. Circle them. Ignore the other four for now. 2. Give each of the two a named owner. Not a team. A person. 3. Give each owner one deliverable and a date inside the next two weeks. The constraint doc, or the rubric, or the wrong-path spec. Something a stranger could read. 4. Put a thirty-minute review on the calendar for the end of week two. The only agenda item is whether the deliverable exists and whether it is checkable. Anxiety about where the practice is going dissolves fastest when there is a specific piece of it somebody has been made responsible for. That is what this page is for. --- ## The one thing to do this week Take the last design decision you had to argue for. Write the three constraints that would get a competent stranger, or an agent, to that same decision without you in the room. Send it to your team. That document is the first page of the spec your practice runs on next. --- _From "Design Just Got Promoted", chapter 1 of The Design Operating Model._ _falkster.com/design/design-just-got-promoted_