# Design's Kill List > Rituals that survive because they have a meeting attached. Nine kills, each > with its replacement in the same block, because killing without replacing is > just removal and removal gets reversed within a quarter. Plus the protocol for > running a kill so it actually sticks. --- ## The test for anything on this list A ritual belongs on the kill list when: - It exists to produce a receipt rather than a decision, and - The receipt was proof that judgment happened, back when producing it was expensive, and - Producing it is no longer expensive, so it no longer proves anything. Everything below fails that test. Yours may differ, and the test travels better than the list. --- ## 1. Pixel-perfect handoff **Kill.** The annotated spec, the redlines, the exhaustive state documentation handed across a boundary. **Why it survives.** It was the artifact that proved design did its job. It also took days, which made it feel substantial. **Replace with.** The constraint set plus a range spec, delivered before generation rather than after design. Engineering gets the rules and the boundaries, not the coordinates. Faster to write, covers states nobody drew, and it survives the first change that would have invalidated the redlines. --- ## 2. Design review as approval theater **Kill.** The recurring meeting where work is presented, reactions are collected, and approval is implied but never stated. **Why it survives.** It is the only reliable time the team looks at the work together, and killing it feels like killing craft. **Replace with.** The thirty-minute rubric review: independent scoring before, disagreements only during, one decision at the end. Same slot on the calendar, different meeting. You keep the ritual and change what it produces. --- ## 3. The component library as monument **Kill.** The design system maintained as a comprehensive catalogue of every component, curated as an end in itself. **Why it survives.** It is visible, measurable, and there is a team whose identity is attached to it. **Replace with.** A constraint layer plus a much smaller set of primitives. When surfaces are assembled at runtime, the leverage is in the rules that govern assembly, not in the count of pre-built components. The systems team becomes the team that owns the rules and the checks, which is a bigger job, not a smaller one. --- ## 4. Personas as decoration **Kill.** The laminated persona with a stock photo, a name, and a fictional quote. **Why it survives.** Cheap to make, comforting to point at, nobody has to defend it. **Replace with.** The evidence register. Rows with sources, strength, and expiry dates. When somebody asks "who is this for," the answer cites a row rather than a character. --- ## 5. The double diamond as a calendar **Kill.** Discovery phase, then definition, then development, then delivery, laid out on a quarterly timeline. **Why it survives.** It makes design legible to planning software. **Replace with.** The weekly cadence: one question a week, one register row, one decision. The diamond was a description of how thinking works, and it became a schedule, which is the failure mode of every good diagram. --- ## 6. Fidelity ladders **Kill.** Sketch, then wireframe, then mid-fi, then hi-fi, then prototype, as mandatory stages. **Why it survives.** It managed the cost of production. Each rung existed because the next one was expensive. **Replace with.** Go straight to the fidelity that answers the question. When production is cheap, the ladder is pure ceremony, and the intermediate artifacts mostly collect feedback about the wrong things. --- ## 7. The design QA pass **Kill.** Design reviewing built work at the end and filing tickets for discrepancies. **Why it survives.** It is the last point of control, and it feels like defending quality. **Replace with.** Constraints checked automatically, plus the rubric review. If design is inspecting output at the end, design has been made into a QA function with better typography. Move upstream and the end-of-cycle review becomes a ten-minute conversation about exceptions. --- ## 8. The kickoff workshop as default **Kill.** The two-day offsite workshop at the start of every initiative. **Why it survives.** It creates alignment, and alignment is real. It also costs sixteen person-days and produces a wall of stickers that nobody converts into constraints. **Replace with.** Ninety minutes on the failure inventory with three people. It produces the constraints, the eval cases, and the shared understanding, and you have the rest of the two days back. Keep the workshop for actually new problem spaces, which is maybe twice a year. --- ## 9. Feedback rounds without a decision rule **Kill.** Circulating work for comment with no statement of who decides or what would change the decision. **Why it survives.** It feels inclusive and it distributes blame. **Replace with.** Named owner, named constraints, and a stated question. "Here is the decision, here are the constraints that produced it, tell me which constraint is wrong." Feedback becomes useful the moment it has something to push against. --- ## The kill protocol Announcing a kill does not kill anything. Four steps, and skipping step 2 is why most kills fail. **1. Name what the ritual was protecting.** Every surviving ritual protects something real. Handoff protected the specificity of the built result. Review protected quality. Say it out loud, or the people who value it will assume you did not notice. **2. Ship the replacement first, and run both for two weeks.** Overlap is the cost of a kill that sticks. Killing first and promising a replacement produces a gap, and gaps get filled by the old ritual coming back with a new name. **3. Kill the meeting, not just the artifact.** A ritual with a recurring calendar slot regenerates its artifact. If the slot survives, the ritual survives. **4. Say when you would bring it back.** Name the condition. "If quality drops on the rubric for two consecutive reviews, the old review comes back." That sentence converts the kill from an ideology into an experiment, and it is what gets skeptics to agree. --- ## The scorecard | Ritual | What it protects | Replacement | Overlap ends | Bring-back condition | |---|---|---|---|---| | | | | | | | | | | | | --- ## The one thing to do this week Pick the one ritual on your team that everybody privately thinks is theater. Write down what it protects and what replaces it, then run both for two weeks. Announce the bring-back condition when you announce the kill, and the argument mostly disappears. --- _From "Design's Kill List", chapter 22 of The Design Operating Model._ _falkster.com/design/designs-kill-list_