Design's Kill List

The short version

A design ritual belongs on the kill list when it exists to produce a receipt rather than a decision, and the receipt only ever counted because producing it was expensive. Nine fail that test: the pixel-perfect handoff, design review as approval theater, the component library as monument, personas as decoration, the double diamond used as a calendar, fidelity ladders, the design QA pass, the default kickoff workshop, and feedback rounds with no decision rule. Every one of them gets its replacement in the same breath, because killing without replacing is removal, and removal gets reversed inside a quarter. The protocol matters more than the list: name what the ritual protected, ship the replacement first, kill the calendar slot and not just the artifact, and state the condition that would bring it back.

Every ritual on this list was load-bearing once. That is why they are hard to kill, and why people defend them with more heat than the topic seems to deserve.

Take the annotated handoff spec. It took three days. Three days of a designer's week is a serious thing to hand across a boundary, and the document proved judgment had happened, because nothing that thorough gets made by accident. The cost was the proof.

Then production got cheap.

And the proof stopped proving anything. The ritual stayed anyway, because it had a calendar slot and a name and somebody whose good year depended on it.

Which is the test, and the test travels better than the list, since your nine will not be my nine. A ritual is a candidate when it produces a receipt rather than a decision, when the receipt was evidence that judgment happened, and when producing it is no longer expensive.

All three conditions. Plenty of design rituals pass. Calibration passes. A failure inventory passes, easily. The nine below do not.

The nine

1. Pixel-perfect handoff. Kill the redlines, the exhaustive state documentation, the annotated spec pushed across a boundary. Replace it with a constraint set plus a range spec, delivered before generation instead of after design. Engineering gets the rules and the boundaries rather than the coordinates. Faster to write, covers states nobody drew, and it survives the first product change that would have invalidated every measurement in the file. The mechanics of the range are in You Cannot Mock a Distribution.

2. Design review as approval theater. Work gets presented, reactions get collected, approval is implied and never actually stated. Killing it feels like killing craft, because it is the only reliable hour the team looks at the work together. So keep the slot and change what happens inside it. Independent scoring before, disagreements only during, one decision at the end, thirty minutes. Same calendar entry, different meeting, and now it produces something. The Rubric Is the Spec has the scoring mechanics.

3. The component library as monument. A design system maintained as a comprehensive catalogue, curated as an end in itself. It survives because it is visible, countable, and there is a team whose identity is attached to it. Replace it with a constraint layer and a much smaller set of primitives. When surfaces get assembled at runtime, the value is in the rules that govern assembly. The systems team becomes the rules team, which is a bigger job, and somebody has to say that out loud on the day the catalogue stops growing.

4. Personas as decoration. Laminated card, stock photo, first name, fictional quote. Cheap to make, comforting to point at, and nobody ever has to defend it. Replace it with an evidence register: rows with sources, strength, and expiry dates. Now when somebody asks who this is for, the answer cites a row instead of a character. Less charming, and it can be wrong in public, which is the entire point of it.

5. The double diamond as a calendar. Discovery, then definition, then development, then delivery, laid across a quarterly timeline. It survives because it makes design legible to planning software. Replace it with a weekly rhythm: one question a week, one register row, one decision. The diamond described how thinking works and got turned into a schedule, which is the failure mode of every good diagram.

6. Fidelity ladders. Sketch, wireframe, mid-fi, hi-fi, prototype, as mandatory stages. Each rung existed because the next one was expensive. Go straight to whatever fidelity answers the question in front of you. The intermediate artifacts mostly collect feedback about the wrong things, and everyone in the review knows it while it is happening.

7. The design QA pass. Design reviewing built work at the end and filing tickets for discrepancies. Defended hard, because it is the last point of control and it feels like protecting quality. Replace it with constraints checked automatically plus the rubric review. If design is inspecting output at the end of the cycle, design has been made into a QA function with better typography. Move upstream and the end-of-cycle conversation becomes ten minutes about exceptions.

8. The kickoff workshop as default. Two days offsite at the start of every initiative. It creates alignment, and alignment is real, so this one gets defended hardest of all. It also costs sixteen person-days and produces a wall of stickers nobody converts into constraints. Replace it with ninety minutes on a failure inventory with three people. Same shared understanding, plus the constraints and the eval cases, and you have the rest of the two days back. Keep the workshop for problem spaces that are actually new, which is maybe twice a year.

9. Feedback rounds with no decision rule. Circulating work for comment without stating who decides or what would change the decision. It feels inclusive and it distributes blame, which is a strong combination. Replace it with a 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 gets useful the moment it has something to push against.

The protocol

Announcing a kill kills nothing.

Four steps, and skipping the second is why most kills fail.

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, and then the argument is about whether you understand the work rather than about the ritual.

Ship the replacement first, and run both for two weeks. Overlap is the price of a kill that sticks. Kill first and promise a replacement and you have created a gap, and gaps get filled by the old ritual returning under a new name, usually within a month, usually with the same recurring invite.

Kill the meeting, not just the artifact. A ritual with a standing calendar slot regenerates its artifact. If the slot survives, the ritual survives, and six weeks later you are explaining why the deprecated spec template is somehow back. Same logic runs underneath Kill the Status Meeting on the product side.

Then 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. One sentence, and it converts the kill from an ideology into an experiment, which is what gets the skeptics to agree in the room rather than relitigate it in a DM afterward.

At Salesforce I killed the weekly review everyone quietly hated and loudly defended. Same slot, new format, both running for two weeks, and I said out loud what would bring the old one back. Nothing ever did.

Why they were there

None of these rituals were stupid. They were correct responses to a cost structure that no longer exists.

That is the uncomfortable part and also the generous read. Nobody built approval theater on purpose. Somebody built a review, the review worked, the review outlived the conditions that made it work, and no one had a reason to look at it again because it was on the calendar and calendars are self-justifying.

So the real practice is not this list. It is running the test once a quarter, on your own rituals, with the people who perform them in the room.

This week, pick the one thing on your team that everybody privately thinks is theater. You already know which one it is.

Write down what it protects and what replaces it, then run both for two weeks and announce the bring-back condition on the same day you announce the kill. Most of the argument disappears at that sentence.

All nine kills with what each protects, the four-step protocol, and a blank scorecard with a bring-back column are in The Kill List. The short version to send someone who wants the answer without the argument is Which design rituals should you kill, and what replaces them?

---

Chapter 22 of a series on the design operating model. Next: what a design organization looks like when generation is free, and the tripwires that tell you to change shape.