Feedback on the work,
not on the designer.

Five moves, in order. State the stage of the work, so nobody critiques polish on a wireframe. Have the designer ask one specific question rather than what do you think. Collect written feedback silently before anyone speaks, which stops the first or most senior voice anchoring the room. Group the feedback into themes and spend the discussion on the ones where several people independently noticed the same thing. Then record decisions: what changes, what deliberately does not and why. Sessions that skip the last step produce the same feedback again the following week, usually from the same people.

Because whoever speaks first sets the frame for everything after, and in most teams whoever speaks first is either the most senior person or the most comfortable talking, neither of which correlates with having the most useful observation. Silent writing removes that entirely: everyone commits their reaction independently, so you find out whether three people separately noticed the same problem, which is a genuine signal, or whether one person had a preference and four others agreed with them out of politeness. It also gets the quiet reviewer's observation onto the board, which in a talking-only session is simply lost.

Not during early access. Storyflow is paid-only right now, with plans starting at $9.99 a month, and a Free plan for solo use launches before the end of 2026. Anyone a paid member invites to a board joins free today, which matters here because critique participants frequently include people outside design, engineers, founders, clients, who would otherwise need a licence. If you need free this minute, Figma's free tier handles comments on work well and FigJam is free for most teams. Both are honest options; neither will lay out the session structure or hold the decisions record for you.

Put the brief, the constraints, and the target user on the board beside the work, and ask that every piece of feedback reference one of them. This sounds bureaucratic and it changes the session immediately, because I do not like the blue is very hard to write when the brief says the product must read as calm and clinical, and the reviewer either connects their reaction to that or notices they cannot. Also ask for observations rather than solutions. I would move the button hides the problem; the primary action was the third thing I looked at gives the designer something to work with.

Yes, and the written feedback is usually better than what a live session produces. Post the work with the context and the question two days ahead and let people write when they have actually looked properly. You get contributions from people in other time zones, people who think slowly, and people who are better writers than speakers, which is a large fraction of any design team. Then hold a short live session, often twenty minutes rather than an hour, covering only the themes where the written feedback disagrees. Everything with clear agreement does not need a meeting at all.

You post the work and describe what it is, what stage it is at, and what you want feedback on. The AI lays out the board from that: a context panel holding the brief, constraints, and stage, silent feedback areas for participants, a themes region for grouping, and a decisions panel for the close. After the silent round it can read the whole board and group the written feedback into themes, which is a useful first pass before the discussion. It organizes the session; it does not judge the work, which is a judgement that needs the users, the brand, and the constraints behind it.

A critique examines work in progress to make it better; a review approves finished work to let it ship. Confusing them is one of the most common causes of bad sessions, because a designer bringing rough exploration to what turns out to be an approval meeting will get defensive, correctly, and a stakeholder expecting to sign something off will be frustrated by unfinished work. State which one you are running at the top of the board. Both work on this canvas, and both benefit from written feedback first and recorded decisions, but the framing and the expected outcome are genuinely different.

Yes, and it is one of the main reasons to run critique outside the design file. Send a view-only link and a client, a founder, an engineer, or a marketing lead opens the whole board in a browser with no account, sees the work with the brief and constraints beside it, and signs in to comment directly on the specific piece they are reacting to. If someone should genuinely contribute, invite them to the canvas and they join free as a collaborator. Sharing, commenting, and reviewing work on every paid plan.

Three lists, and the second is the one everyone forgets. What is changing, with an owner. What is deliberately not changing, and the reason, because unrecorded rejections come back as the same feedback in a fortnight and the designer has to relitigate a decision they already made. And what is still open, needing more information or another look, so it is visible rather than quietly dropped. Keep it on the board rather than in meeting notes, so the next critique opens on the previous decisions and the conversation starts from where it actually finished.