How to run a design critique in a small team

A design critique process asks one question: does this work do the job it was given? Preference, taste, and the designer's feelings about the week can wait outside. In a small team the founder can host this in half an hour, with the people who will live with the result, and end with a short list of changes that still serve the same job.

Without that boundary, critique turns into a tour. The person who made the work explains every choice. Everyone else reacts to whatever detail they saw last. The project collects comments and loses the plot. A small team cannot afford that kind of meeting. There are too few people and too little time to relitigate the goal on every screen.

Set the job before anyone opens the file

Send three lines the day before, or write them on the wall at the start.

• The person this is for, named as a role, not a persona novel.
• The job they are trying to finish.
• The constraint that matters this round: a phone width, a deadline, a sentence that must stay, a technical limit.

If the room cannot agree on those lines, you are not ready to critique the design. You are still scoping. Stop and fix the lines. Looking at screens before the job is shared is how a meeting becomes a vote on color.

The designer brings the work and a one-minute setup: what problem this version is trying to solve, and what is deliberately unfinished. They do not present a guided tour. A tour defends. A critique needs the work to stand where a stranger would meet it.

Nielsen Norman Group's research on page visits describes the opening seconds as a harsh judgment: people decide quickly whether a page is worth staying for, and a clear value earns a longer look. Borrow that stance for the room. The first question is whether a new person could tell what the screen is for. It is a poor question to ask after a five-minute explanation has already told them.

A thirty-minute shape

Use a clock. Small teams expand to fill whatever time is on the calendar. Thirty minutes is enough for one flow.

1. Two minutes. Read the job aloud. Confirm it is still the job.
2. Five minutes. Look in silence. Everyone writes questions and failures on paper. No reactions yet.
3. Ten minutes. Each person names one place the job breaks, and one place it holds. Start with the break.
4. Eight minutes. The host turns the breaks into changes, or into explicit "not this round" notes.
5. Five minutes. Restate the job, the changes, and who does them.

Silence at the start feels awkward and saves the meeting. The first person to talk otherwise sets the frame, and everyone else responds to them instead of to the work. Writing first gives the quiet person an equal list.

Keep the group small. The founder, the person who designed it, and one person who understands the user's day is a complete room. Invite a specialist only for the constraint they own. A critique with eight people becomes a reading of eight moods.

One flow means one flow. If you have three features, run three short critiques on three days. Stacking them into a single hour blurs the notes. By the third feature everyone is tired and the comments get sloppier, which is when preference sneaks back in dressed as urgency.

What counts as a useful comment

A useful comment points at the job. "I cannot tell which control saves the lead" is useful. "I would have used a side panel" is a different design, offered early. Park alternatives until the failure is agreed. Sometimes the failure is real and the suggested panel is the wrong repair. Sometimes there is no failure, and the panel is only a preference.

Use this test before you say a line aloud. Can you finish the sentence "This makes the job harder because…"? If you cannot, write the thought down and keep it out of the round. Taste notes are allowed at the end, in a separate minute, and they are labeled as taste. "I want this to feel quieter" is a valid taste note. It does not outrank a broken task.

Describe what you see, then what failed. "The primary button is below the fold on a phone, so the save is invisible" is something the team can check. "This feels off" creates a second meeting. If you are unsure why it failed, say the observation and stop. Other people can supply the because.

The designer may answer with a constraint. "That button is low because the error text has to sit above it." The room then critiques the pair: can the error and the button both stay visible? Constraints are part of the work. They are not a shield against the job. A legal line that must appear can still be shorter. A legacy field that must be stored can still be collapsed.

Avoid redesigning in the margin. Sketching a replacement layout while someone is still explaining the failure steals the meeting. Capture the failure. Let the person who owns the file propose the next version. If you are that person, take the note and do the sketch after, when you can hold the whole flow in your head.

The founder has a special duty here. Your taste is easy to hear as a requirement. Preface taste with "preference," and preface job failures with "the job." The team will copy your labeling. If you only speak in preferences, the critique becomes a search for your approval, and the job leaves the room.

What the host writes down

End with a note everyone can see. Three lists are enough.

• Change: specific, owned, tied to the job.
• Hold: a criticism you are explicitly not taking, and why.
• Open: a question that blocked the critique, with the person who will answer it.

"Make it pop" cannot go on the change list. "Move the save button above the fold on a 390-wide screen" can. The hold list is how you protect the work. Without it, parked comments return as new requests next week and the team thinks nothing was decided.

Send the note the same day. A critique that lives in someone's memory will be remembered as the comment that stung, not as the decision. On a small team the note can be a dozen lines. Length is not a sign of rigor. Specificity is.

If a change is large enough to threaten the date, say so in the note. "This replaces the navigation. It costs the Friday review." The founder can then choose the job over the date, or the date over the change. That choice should be visible. A critique that silently resets the schedule is how teams stop agreeing to critiques.

When to skip the meeting

Skip it when there is no job yet. Skip it when the work is an exploration of three directions and you actually need a choice, not a critique. Choosing a direction is a different meeting: compare each direction against the same job, then critique the winner next time.

Skip it when the only available comments are taste and the job is already succeeding in the last test. Ship the small correction. Do not gather the team to watch a success.

Run it when the team is about to build, when a user got stuck, or when the founder feels uneasy and cannot name why. The meeting's purpose is to turn that unease into either a job failure or a preference you can set aside.

If you want a studio in the room for that half hour, book an intro call with Hanabi. Bring the job sentence and the current screens. The call can tell you whether a critique is the right next step, or whether the brief still needs a boundary.

After the meeting, the comments still have to be given in a way that does not restart the work from zero. How to give design feedback without sending the project back to the start is the companion: what to say when you are the one responding, and how to keep the goal stable.