Critique Lives in the Arrows

There is a moment I recognize in every project. An idea shows up — I just thought of something — and minutes later I am already writing code. The jump feels productive. It is almost always expensive.

It is expensive because between I just thought of it and I am already building you skip the only question that matters: what exactly does this piece prove? Without that question answered, what you build has nothing to measure itself against. And what cannot be measured against a goal ends up measured against taste — yours, the client's, whoever spoke loudest in the room. Taste is an unstable judge. It shifts with fatigue, with the hour, with the volume in the meeting.

At my studio I built a mechanism to stop that jump. It is not a tool or a new board; it is a decision discipline that mounts on top of the workflow I already have. I am writing it down because I think the part that is actually mine can help other people who build things — and because the best way to find out whether a method holds is to expose it.

The thesis

Critique is not an event at the end of the process; it is the gate that controls every transition. That is the whole reframe, and it changes where you put your attention. Most people treat critique as a step: you build, and at the end someone reviews — so critique arrives late, after you have invested, after you have grown attached, after changing course hurts. If instead it lives in the transitions and not the states, nothing advances without passing through it, and it always arrives on time: before you overbuild.

Put the way it stuck with me: a piece is never in critique. It is in a state, waiting to cross a gate. Critique lives in the arrows, not the boxes.

How it works

A piece — a module, an endpoint, a contract, a feature, a document — moves through four states, and critique is the mechanism of the arrows between them. Each arrow carries a question, and it is answered against the stated goal, never against preference.

In divergence the idea spins and judgment is deferred — the gate asks whether we explored enough or are closing out of fatigue. In reduction to thesis the idea collapses to one sentence the piece has to prove; if it does not fit on a line it is not ready, and this is also where you declare whether it aspires to generalize. In proof of life you build the minimum that proves that one thing — the evidence of the feature, not the whole feature — and a piece that passes here and aspires to nothing more closes here, because staying scoped is a valid ending. And in graduation the solid piece generalizes, if and only if the contract you declared in the thesis survives the second case without being rewritten.

Under all of it sits one non-negotiable lock: nothing advances without a written goal. The verbal version — I have got it crystal clear in my head — does not count. Writing the thesis takes two minutes and is the first action, before design, before code. Without it, critique has nothing to measure against and decays into taste.

Where it comes from (and what is not mine)

I would rather say up front what I borrowed, because nearly everything above is borrowed. Separating generating from evaluating — deferring judgment during divergence — is classic design thinking, from IDEO. Reducing to the inevitable, holding a strong point of view, and critiquing the built object rather than the abstract idea is the design method Apple made famous under Jony Ive. And the vocabulary I use to classify feedback is lifted straight from Discussing Design by Adam Connor and Aaron Irizarry.

There are closer neighbors still. Writing the thesis before opening code is the same discipline that holds up a design doc or an RFC on any serious engineering team. And shaping a piece before committing to build it was developed far better than I could by Basecamp in Shape Up. Being honest about this does not weaken me: it lets me point precisely at the two things I do think I added.

One: feedback gets classified before it gets executed

Connor and Irizarry distinguish three forms of comment. Reaction is visceral: I do not like the blue. Direction starts with a solution: make it multi-format. Critique analyzes against the goal: this does not prove the thesis because X. Only critique graduates a decision.

My contribution is not the taxonomy — that is theirs — it is applying it as a mandatory gate over my own work, and over the entire batch of comments, no exceptions. The failure this method exists to stop is concrete: faced with a batch — make it blue and have it generate PDFs — instinct translates the color, the provocative comment, and executes the PDF with no gate, on the excuse that it is just new scope, it does not touch the thesis. If it does not touch the thesis, it does not belong to the minimum: it goes to out-of-scope or to its own piece. Every item gets classified. The provocative one cannot smuggle the other in through the back door.

The real work is translating. Whoever asks almost always gives reaction or direction; turning that into critique-against-goal is the craft. And for feedback to land as critique instead of reflex, I declare the goal before showing the piece. I never present it cold hoping for applause. Applause is not information.

Two: graduation is declared from the thesis, and it has teeth

This is the one that cost me most and that I use most. A piece declares from its thesis whether it aspires to generalize, and the test is concrete: can you name two distinct uses consuming the same internal contract? Not two clients, not two instances of the same case — that proves nothing new — but two distinct consumers: another surface, another pipeline, another system.

The distinction has consequences. A genuinely generalized piece is a contract three real consumers already use without it ever being rewritten. I have one: a single brand-identity contract — colors, type, logos — read today by three unrelated surfaces, the studio's public site, an internal design tool, and a brand-deck generator. Three distinct consumers, one contract, zero rewrites. A piece that aspires well named its two uses from the start, even if the second does not exist yet. And what this method hunts to kill is the third category: disguised debt, the piece that pretends to be generic with no second use named.

We will generalize it later is not a declaration. It is the retrofit that guarantees the abstraction will not hold, because you designed it against one case and asked it to serve cases you never looked at. Graduation is not added afterward. It is designed from the start, or it is not designed.

Why I saw it

A strong point of view is a rare advantage. It converges fast, does not relitigate what it already knows, cuts noise. I work with one, and it has let me build in months what a committee would take years to argue through.

But a strong point of view has an exact shadow: the criterion you do not debate can become the criterion you do not review. Converging fast and converging well are not the same thing, and late at night, tired, wanting to never reopen a topic, they feel identical. That is where I make the decisions I later struggle to undo.

I built this method, at bottom, as a counterweight to myself. Not to stall the work — that kills it — but so that something sings, clearly and exactly once, when an irreversible decision looks like it is being born of fatigue rather than judgment. The distinction is fine but decides everything: executing while tired is fine; deciding something irreversible while tired gets flagged and left for a fresh head. The counterweight's rule is flag, never block: it says the thing once, offers to do the executable part now, and lets me decide. A small studio does not get the luxury of the committee that forces you to justify yourself. The counterweight has to be built. This method is mine.

The close

It is not a methodology asking you to abandon yours. It is a decision discipline that mounts on top of the PR, review, and demo flow you already run — four questions on four arrows, and one lock that says write the thesis first. Take it, adapt it, argue with it. If you try it on your own work and one of the two rules of my own saves you a refactor, it was worth writing.