This canvas exists to make one thing true: your team decides what "good" means before it sees any options, not after. Follow these steps in order. The order is the point.

1. Lock the date before you write anything else. Fill in the date box top right. This is the moment your criteria stop changing. Don't touch the four bands until this box is filled in. Can you change this later? Sure…but you had better have a great reason to do so PLUS acknowledgement from the entire team.
2. Write every line as something you can check, not something you feel. "Delightful" fails this test. "Loads in under 2 seconds" or “drives meaningful revenue gains of >10%” passes it. If you can't picture an option failing the line, rewrite the line.
Example: swap "Must feel trustworthy" for "Must show a named human contact within one click of checkout." Same intent, but now an option can actually fail it.
3. Fill in Must. Non-negotiables only. One fail here and the option is out, no matter how good it looks otherwise. Keep this short. If everything's a Must, nothing is.
Example: "Checkout must complete in 3 steps or fewer on mobile."
4. Fill in Should. Important, but survivable. A strong option can miss one Should line and still win. I have found that Shoulds are often the Musts that are on the line…or when there are just too many Musts. If you do find that there are too many musts, a good exercise is to stack rank them in order of importance, then move some meaningful percentage of the Musts (>10%) to Shoulds.
Example: "Should cut support tickets on this flow by 20% or more."
5. Fill in Could. Nice if true. These should never be the reason an option wins or loses.
Example: "Could support a dark mode toggle."
6. Fill in Won't. What's explicitly off the table. Just as non-negotiable as Must, pointed the other direction. Sometimes, if I know I am going to co-create a polarizing set of criteria, I’ll move straight to Won’ts right after Musts.
Example: "Won't require creating an account to complete a purchase."
7. Tag each line V, U, F, or C. Viability, user-truth, feasibility, or cost-later, depending on what the line is actually defending. When you're done, look at the tags across all four bands. If one letter never shows up, you've found a blind spot before it cost you anything.
Examples:
"Must convert at 4% or higher within 60 days" — tag V.
"Must let a first-time user complete a return without contacting support" — tag U.
"Must ship using our existing payments provider, no new vendor contracts" — tag F.
"Won't collect a customer's precise location without a real-time reason for it" — tag C.
8. If a line is tagged U, back it with a real transcript. Not a synthetic panel, not a paraphrase, not a guess at what a customer would probably say. A real person, actually asked. This is the one rule on the canvas with no exceptions.
Example: "Must resolve a billing question without a phone call" pairs with actual exit interviews from customers who called billing last quarter, not a simulated panel run the same afternoon.
9. Generate your options (i.e., IDEATION!) after this point, not before. This is the whole reason the date box exists. Criteria written after you've already seen the options aren't criteria. They're a justification wearing a criteria-shaped costume.

That's the state your canvas should be in before a single option shows up: every line filled, every tag circled, every checkbox still empty.
10. Score each option against every line. Use the checkbox grid on the right. One column per option, letters A through E. Go line by line, not option by option, so you're not unconsciously grading your favorite first and reverse-engineering the rest.
Example: the line "Must complete checkout in 3 steps or fewer" gets checked against options A through E one at a time. Options B and D pass. A, C, and E fail and are done, regardless of how they score anywhere else.

11. Any option that fails a Must line is out. No exceptions, no "but it's so close." That's what Must means.
12. Use Should and Could to break ties among what's left. This is the only point in the process where a close call is actually appropriate.
That's the whole thing. If you want the reasoning behind why this replaced a wall of sticky notes and a gut-feel vote, that's what the Design Shift article on criteria walks through.
A worked example, checkout redesign, all four bands together:
Band | Line | Tag |
|---|---|---|
Must | Checkout completes in 3 steps or fewer on mobile | F |
Must | A first-time user can complete a return without contacting support | U |
Should | Cuts billing support tickets by 20% or more | V |
Could | Supports a dark mode toggle | — |
Won't | Requires creating an account to complete a purchase | C |
Five lines. Every one of them is checkable. The Must lines can each end an option on their own. The Could line can't decide anything by itself, which is exactly what a Could line should do.