Design critique

A one-pass adversarial review of a design that does not exist yet. The output is ranked findings, each of which names a way this fails in practice.

This is not interrogation — there is no dialogue, and the author is not in the room. It is not code review either; the code has not been written, which is exactly why this is the cheapest moment to find the problem.

1. Restate the design before attacking it

Write two or three sentences describing the design in your own words, and check them against the document.

Do this first, every time. A large share of critique findings are misreadings — the reviewer attacked a design nobody proposed — and every one of those costs the author's trust and makes the real findings easier to dismiss.

If you cannot restate it, that is the first finding: the design is not legible.

2. Attack the design, never the author

"This won't work under concurrent writes" is a finding. "This wasn't thought through" is a mood. The second one is also unactionable, which is the practical objection to it.

Every finding is a statement about the artifact.

3. The passes

Work through these deliberately. Each finds a different class of problem, and skipping one is how a category gets missed entirely.

4. Every finding names a concrete failure

A principle is not a finding. Convert it into a scenario with actors and values:

Weak:   This doesn't handle concurrency well.

Strong: Two editors open record 88 on Monday morning. Both save. The
        second write overwrites the first because the update is a full
        document replace keyed on record id, with no version check. The
        first editor's 40 fields are gone and nothing logs it.

The strong version is arguable, testable and fixable. The weak one generates a defensive reply and no change.

If you cannot construct the scenario, you have a suspicion. Say so explicitly and keep it in a separate list — suspicions are useful, but not if they are dressed as findings.

5. Rank by cost of being wrong

Not by confidence, and not by how interesting the finding is.

Labelling taste as taste is what makes the blocking findings credible. A review that presents ten things at the same volume gets all ten discounted equally.

6. Hunt in the gaps, not in the text

The findings that matter are usually about what the document does not mention:

• The state nobody listed — the half-finished record, the deleted user who still owns rows, the tenant with zero of everything.
• The second actor — a second user, a second device, a second tab, an admin doing it from the back office.
• The unhappy exit — the user closes the laptop mid-flow. What is left behind?
• The thing outside the boundary — a report, an export, a cache, a search index that also reads this data and was not mentioned.
• The assumption stated as a fact — "the file will always be under 5MB".
• The number with no source. Every figure in a design should be traceable to a measurement or labelled as an estimate.

7. Offer a direction, not a redesign

For each blocking and significant finding, add a sentence on what would resolve it. Not a full alternative design — that hijacks the author's work and usually misses context you do not have.

"Version check on update, reject on mismatch" is enough. If the fix needs three paragraphs, the finding is that the design needs a decision, and that is what to write.

8. Say what is good, briefly and specifically

Not for morale — for signal. "The decision to keep submissions immutable is right and removes a whole class of problem" tells the author which parts are settled and stops a later revision quietly undoing them.

Two or three lines. Specific, or leave it out.

Output

## What I understand this to be
<2–3 sentences, in your own words>

## Blocking
**B1 — <one-line claim>**
Scenario: <actors, values, the wrong outcome>
Direction: <one sentence>

## Significant
**S1 — ...**

## Improvements
- ...

## Taste (take or leave)
- ...

## Suspicions — could not construct a scenario
- ...

## Settled, and worth keeping
- ...

Checklist

• Design restated in your own words and checked before critiquing
• Every pass run, including operations, migration and reversal
• Every finding attached to a concrete scenario with actors and values
• Suspicions separated from findings
• Ranked by cost of being wrong; taste labelled as taste
• Gaps hunted: missing states, second actors, unhappy exits, unmentioned readers
• Numbers without a source flagged
• A direction offered for each blocking and significant finding
• What is settled and good stated specifically