• Present prototypes clearly, avoiding over-explanation or defensiveness.


• Gather specific feedback to improve the design.


• Differentiate preferences from usability issues.


• Identify the top three changes for the next iteration.


• Foster team alignment around the prototype's goals.

• Actionable feedback for prototype improvement.


• Clear distinction between critical issues and minor improvements.


• Prioritized change list for the next iteration.

Presenters often want to defend every criticism. Shut this down. The goal is to gather feedback, not win arguments. Defensiveness blocks learning.

'I don't like it' is useless. 'I didn't understand which button to click' is useful. Push for specific, behavioral feedback. Ask: 'What were you trying to do when you got confused? What did you expect to see?' Feelings are valid, but actionable observations are better.

People tend to be too nice, avoiding conflict. Explicitly ask: 'What's one thing that confused you, even briefly?' Give permission to be critical. Frame it as helping the project, not attacking the designer.

If showing rough wireframes, expect comments on visual design. Head this off: 'The visual design isn't done—focus on the flow.' Repeat as needed. Low-fidelity prototypes invite the wrong feedback without clear expectations.

The 10-minute sharing round can drag if people start debating. Keep it moving: 'Great point, stick it up there. Next person.' Discussion comes later. Debate during sharing wastes time and silences quieter voices.

Someone new to the project spots things the team misses. Their confusion is valuable, even if due to lack of context. Include at least one outsider.