Give Critique in a Code or Design Review

It helps you practice giving critique on a specific piece of work during a live review meeting. The scenario centers on a checkout flow design with concrete issues you can point to, including a buried call-to-action, an unclear error state, and an extra mobile step. The goal is to keep your feedback focused on the work, not the person, while still being direct. It is useful when you want feedback that sounds precise, useful, and respectful.

This template fits designers, engineers, product managers, and anyone who needs to give feedback in a review setting. It is especially useful for people who tend to soften critique too much or, on the other side, come across as blunt. The persona is a teammate presenting work, so the practice feels like a real peer review rather than a formal evaluation. It also works well for new managers who want to model constructive feedback.

Use it whenever you are preparing for a review meeting, onboarding into a new team’s critique style, or trying to improve how you give feedback under pressure. It also works as a recurring practice exercise after real reviews where you felt your comments were too vague or too sharp. Repeating the scenario helps you build the habit of naming the issue, explaining the impact, and offering a concrete alternative. That repetition matches deliberate-practice research: realistic reps with immediate feedback build skill faster than passive learning.

Ad hoc feedback often skips one of the three things that make critique useful: specificity, impact, and a next step. This template gives you a repeatable situation, a defensive but realistic persona, and scored criteria so you can see exactly where your delivery breaks down. It also lets you retry the same conversation until your critique is clear and steady. That makes it easier to transfer the skill back into real reviews.

Yes. You can swap in a different artifact, such as an API change, a landing page, a dashboard, or a component library update, while keeping the same critique structure. You can also adjust the persona’s temperament, the learner objective, and the rubric criteria to match your team’s expectations for review comments. If your team uses a specific framework like accessibility checks or design-system standards, you can add those as rubric items. The template is meant to be adapted, not used as a one-size-fits-all script.

Avoid vague comments like "this feels off" or "I don’t like it" because they do not give the presenter anything to act on. Do not frame the feedback as a judgment of the person’s skill or intent. Another common mistake is jumping straight to a solution without explaining why the current version creates a problem. The strongest attempts stay grounded in observable behavior, user impact, and a concrete next step.

Avery is thoughtful and proud of the work, so the conversation does not stay easy if your critique is vague or overly harsh. That makes the roleplay more realistic because real review meetings often include some pushback. If you acknowledge the work first, explain the issue clearly, and stay steady when challenged, the persona softens and the conversation becomes productive. If you dismiss the work or speak too broadly, Avery should push back, which helps you practice recovery.

Yes, but the current scenario is written around a design review of a checkout flow. The same structure also works for code review if you replace the artifact and adjust the critique points to match code quality, maintainability, or test coverage. For code review, you would usually make the learner objective more specific to implementation concerns and change the rubric to reflect technical clarity. The core skill remains the same: critique the work with enough detail that the other person can improve it.