Critique 101: Standards, Evidence, and Acceptance Criteria

Session 10 teaches the learner to turn a design option into a reviewable product standard. The output is not a list of likes and dislikes. It is a critique and acceptance sheet: strengths, issues, severity, evidence, assumptions, top fixes, acceptance criteria, Given/When/Then scenarios, accessibility criteria, and Definition of Done checks.

This session matters because product teams need more than ideas. They need shared language for what is working, what is risky, and what must be true before work is ready. Critique creates that language.

The tone should be rigorous but not harsh. A strong critique protects the user, the team, and the work. It is specific, evidence-aware, and directed at the artifact, not the person who made it.

The learner should leave this session with critique vocabulary: scope, standard, observation, inference, evidence, assumption, issue, severity, recommendation, acceptance criterion, scenario, accessibility criterion, and Definition of Done.

The core distinction is between feedback and readiness. Feedback says what to improve. Readiness standards say how the team will know the work is good enough for the current stage.

The learner should practice speaking in product language: this issue is major because it blocks the user from understanding why the recommendation fits the task; the acceptance criterion is that the reason must be visible before the save action.

Critique is not personality. It is not a chance to sound clever. It is a method for protecting the user goal and improving the work.

The tutor should repeatedly ask: what goal or standard does that feedback refer to? If the learner cannot answer, the feedback may be a preference rather than a critique.

A helpful critique sentence usually has four parts: observation, user impact, severity or priority, and recommended next step.

Critique without scope gets messy quickly. A learner reviewing an entire app will either stay vague or become overwhelmed. A learner reviewing one screen for one task can be specific.

Scope protects the conversation. It tells reviewers what kind of feedback is useful. It also protects the designer from receiving feedback about everything at once.

In this course, the default scope is one chosen option or AI-generated screen from the product recommendation project.

The user story gives critique a target. GOV.UK guidance stresses actor, narrative, and goal. The goal is especially important because it helps the team decide when the story is done.

If the learner cannot write the user story, she should not begin detailed critique yet. She may be reviewing against taste rather than user need.

A useful story for this session might be: As a first-time student, I want to compare recommended laptops using criteria I understand, so that I can choose one that fits my study needs and budget.

Heuristics give the learner a vocabulary for likely usability issues. They are broad rules of thumb. They are useful for a first pass, especially when formal user research is not yet available.

The lecturer should not ask beginners to memorize all ten at once. Instead, cluster them into practical questions: does the user know what is happening, understand the language, control the process, avoid mistakes, recognize what to do, and recover when something fails?

NN/g is clear that heuristic review complements user research. A heuristic issue is a hypothesis about likely user friction until tested or supported by other evidence.

Severity helps the learner move from feedback to priority. NN/g frames severity around frequency, impact, persistence, and broader market or product effect.

The learner should not use severe language casually. Calling everything major or blocker destroys trust in the critique. The goal is to match priority to user harm and product risk.

Severity is not the same as effort. A blocker may be hard to fix or easy to fix. The team still needs to make a product decision about what to do now.

A critique should separate what is visible from what is inferred. This protects the learner from overstating certainty.

The learner can say: I observe that the confirmation is only a color change. I infer that some users may miss it. We need evidence from a quick prototype test or accessibility review.

This discipline is especially important with AI output. AI may write confident critique that invents user behavior. The learner must lower confidence when evidence is missing.

AI is useful in critique because it can apply a checklist, spot missing states, propose acceptance criteria, and rewrite vague feedback into clearer language. But AI is also prone to generic critique.

The prompt therefore gives scope, user, task, evidence, constraints, and an explicit output structure. It asks AI to separate facts, assumptions, and open questions so the learner can check the output.

The tutor should ask the learner to reject any AI critique that sounds polished but cannot point to a visible issue, a user goal, or an evidence gap.

Accessibility criteria should be specific to the thing being built. Generic statements such as make it accessible are too weak.

Use WCAG principles at a beginner level: perceivable, operable, understandable, and robust. Then translate them into the current feature. For a shortlist action, this means the saved state should not rely on color alone, should be keyboard reachable, should be announced clearly, and should be reversible.

The GOV.UK accessibility acceptance criteria guidance is useful because it treats criteria as records of accessibility decisions, not just compliance notes at the end.

Acceptance criteria are the bridge from critique to action. GOV.UK describes them as outcomes that confirm the service has done its job and meets the user need.

A weak criterion says: make the recommendation clearer. A stronger criterion says: it is done when each recommendation shows a plain-language reason before the save action.

Criteria should make the work inspectable by a teammate. If no one can check whether the criterion is true or false, it needs to be rewritten.

Given/When/Then is useful because it keeps acceptance criteria grounded in examples. It is not just a testing syntax; it is a way to make expected behavior concrete.

A beginner-friendly example: Given a student has three recommended laptops, when she opens comparison, then each laptop shows price, battery, weight, required software fit, and a recommendation reason.

The lecturer should warn against scenarios that describe implementation details. The scenario should describe observable behavior and user outcome.

Acceptance criteria and Definition of Done are related but not identical. Acceptance criteria describe what this story or improvement must achieve. Definition of Done describes the broader quality measures work must meet.

The Scrum Guide treats Definition of Done as a shared quality description for a completed increment. In this course, the learner can use a small version of it: reviewed, tested, accessible, responsive, documented, and ready for the next handoff.

This distinction helps the learner avoid writing acceptance criteria that are too broad or a Definition of Done that is too vague.

Use the course project for a worked example. The learner reviews a recommendation screen created from Session 9. The screen helps students compare laptops, but the reason for each recommendation is visually weaker than the price and badges.

The critique should say: observation, why it matters, likely severity, evidence basis, and improvement. This keeps the feedback grounded.

The recommended improvement is not simply make it bigger. It is: make the recommendation reason visible before the save action so students can understand why the option fits their study needs.

After critique, convert the improvement into criteria. The criteria should be observable and tied to the user story.

Then convert the most important criteria into scenarios. Example: Given a student is viewing recommended laptops, when she saves one to the shortlist, then the card confirms the saved state without relying only on color.

Finally, add a small Definition of Done checklist: reviewed against criteria, tested in prototype, accessibility checked, responsive behavior considered, open questions logged.

The studio output is one critique and acceptance sheet. It should be specific enough that a teammate could understand the issue, act on the recommendation, and check the criteria.

For home study, the learner should critique one familiar screen and write three acceptance criteria for the main task. This repetition is important because critique improves only when learners practice moving from observation to standard to action.

Close by previewing Session 11. With standards in place, the next lesson turns a chosen, critiqued direction into a 3-screen flow and feature brief.