A one-word change to how you run crit: ask the room to break a working prototype instead of reviewing flat screens. The mechanics, the precedent, and a starting point for your team.
Here’s the idea I’m planting with our leads this month, and y’all are welcome to steal it: change the ask that starts a crit. Instead of “review this,” make it “break this.”
The mechanics are simple. The presenting designer brings a working prototype instead of mounted flat screens. The room spends the session throwing edge cases at it: the weird account states, the largest customer you support, the shared account with 2 profiles and no clear owner. You log the session, and afterward you point AI at the logs to see what held up and what fell apart. GitLab and GitHub both run versions of this practice, and I’d argue it shows in how robust their releases tend to feel.
The shelf
Why it works: reviewing flat screens invites opinions about aesthetics and layout, the things that are easy to see and easy to have a take on. Breaking a prototype surfaces behavior. What happens on the 2nd tap, what the empty state does, where the flow strands you with no way back. Those are the findings that cost real money when they surface in production instead of in a conference room.
The lift moves the cost of failure earlier, where it’s cheap.
We got a small preview of this energy in our own crit this week. The best moment of the session was a stress test, a tricky account scenario doing exactly this job against a static design, and it reshaped the solution on the spot. Now imagine that same instinct pointed at something that actually responds when you tap it.
Worth naming the honest cost: this asks more of makers. A working prototype is a heavier lift than a board of screens, and even with AI prototyping tools closing that gap fast, the lift is real. My argument is that the lift moves the cost of failure earlier, where it’s cheap. Paying for robustness in prototype hours is the best deal in product development, and it keeps getting cheaper every quarter.
A starting point, if you want one: pick a single crit next month. Ask the presenting designer to bring the prototype they probably already have (most teams are prototyping in some form anyway, even if it never leaves their desk). Give the room one instruction: break it. Write down what breaks and what surprises you. That’s the whole play, and one session is enough to tell you whether it fits your team.
The teachable part
Flat screens invite opinions; working prototypes surface behavior. Ask the room to break the work, log the session, and mine the logs. Failure gets cheaper the earlier you buy it.