Give Critique in a Code or Design Review

This template is for a live code or design review where you need to critique a draft and keep the conversation constructive. The built-in situation focuses on a mobile app onboarding flow, so the learner practices commenting on the work itself rather than the person. It is a good fit when you want feedback that leads to a revision, not just general opinions.

It works for both, as long as the learner objective is to give specific, actionable critique on a teammate’s work. The scenario is written around a design artifact, but the same feedback skills apply to code review comments, architecture notes, or UX copy review. If you want a code-specific version, you can swap the artifact while keeping the rubric and persona behavior.

A manager, team lead, peer coach, or facilitator can run it, but it also works as self-practice. The key is that the person running it should score the attempt against the rubric and push the persona to react realistically when feedback is vague or personal. That makes it useful for onboarding, manager training, and peer-feedback practice.

Use it whenever someone is preparing for a review meeting, has struggled to speak up in critique sessions, or tends to soften feedback too much. It is also useful as a recurring practice exercise for new hires who need to learn the team’s feedback style. Repeating the scenario with different attempts helps build the habit of naming the issue, impact, and revision clearly.

Ad-hoc feedback often stays vague, gets too personal, or skips the reason the issue matters. This template forces a realistic attempt with a specific situation, a responsive persona, and scored criteria, so the learner can practice a cleaner structure before the real review. It helps turn a nervous comment into a usable revision request.

They should point to a concrete part of the onboarding flow, explain the user impact, and suggest a specific change. For example, they might note that extra fields on screen two add friction and propose moving them later or making them optional. The goal is to land on at least one revision the author agrees to make.

Yes. You can swap the onboarding flow for another artifact, change the persona’s temperament, or adjust the rubric to match your team’s review norms. You can also tailor the situation to mobile, web, internal tools, or even API design, while keeping the same critique structure.

It often reveals feedback that is too vague, too personal, or too solution-heavy without explaining the problem. Learners also tend to skip the impact, which makes the critique feel like a preference instead of a useful review comment. The persona is designed to respond differently depending on whether the learner is specific and respectful.

Maya starts open to feedback because she is proud of the work, but she becomes slightly defensive if the critique is vague or sounds like a judgment of her as a designer. If the learner names the issue clearly and explains why it matters, she softens and is more likely to accept a revision. That makes the roleplay feel like a real review conversation instead of a scripted checklist.