The most useful question in a crit is whether the work should exist at all.
The most useful thing said in a crit this week had nothing to do with the design on the screen. The work was a feature that let people reorder a set of actions in a tool, drag them around, tuck the less-used ones into a menu. The design was early and the interaction was reasonable. We could have spent the whole session on it, the grabber affordance and the edit state, and we’d have left with a better-looking version of the same idea.
Instead, the strongest contribution in the room was a question about the idea itself. Is reordering actually what people need, or is the real need just being able to hide what you don’t use? How thin is the research behind the requirement? And given that engineering time is finite, is this the highest-value thing that time could be pointed at right now? Somebody also caught a sneaky problem folded inside the interaction: if people can rearrange and hide actions freely, they can accidentally bury the features they’re paying for, which is a business risk wearing the costume of a UX detail.
The reflex in a crit is to improve the thing in front of you. That reflex is good and most of the time it’s the right one. But it’s the second question, and we reach for it because it’s the comfortable one. Making a proposal better feels like progress and rarely makes anyone defensive. Asking whether the proposal should exist at all is the harder thing to say out loud, and it’s the thing a crit exists to make safe. A crit that only ever polishes the proposal has been quietly captured by the proposal. It’s agreeing, expensively, one suggestion at a time.
There’s a detail in this one that runs against intuition and is worth keeping. The pressure to build the thing wasn’t coming from scarcity. It was coming from the opposite, a team with available capacity looking for the next thing to work on. That’s the sneakier version of the trap. When you’re short on people, you ration hard and you question everything because you have to. When you’ve got the dev time free, “we have the capacity” slides into “so let’s build it,” and those are not the same sentence. Available time is a reason you can build something. It is not a reason you should.
The teachable part
In a crit, ask whether before you ask how. The most valuable critique in the room is rarely the one that makes the proposal better, it’s the one that asks whether the proposal earns its place against everything else that same effort could go toward. Polishing something that shouldn’t ship is just an expensive agreement. And be most suspicious of the build-it reflex when you have capacity to spare, because spare capacity is the easiest reason in the world to make the wrong thing well.