Skip to main content
AP CSP course

C02 · Topic 1.1 · 40 minutes · CRD-1.A, CRD-1.B, CRD-1.C

Reviewing a collaborative solution

By the end you can:

  • Evaluate feedback against a shared purpose.
  • Document a reasoned decision.
  • Design a follow-up test rather than claiming success.

Start here; no earlier topic is required.

Collaboration
People working together on a shared problem, with communication and coordinated responsibilities.
Perspective
A person’s experience or viewpoint that can reveal a different need or assumption.

Understand

Collaborative review compares a proposed solution with a purpose and explicit criteria. Feedback can conflict because users have different contexts. Preserve the disagreement in the decision record, identify whose task is affected and explain the trade-off instead of erasing the minority view.

A revised prototype is a hypothesis about improvement. Test the relevant tasks again, including users affected by the change. Documentation should record the requirement, evidence, decision and unresolved questions so future collaborators understand why a choice was made.

Worked example

The team can spend one day on either a hidden booking action or a decorative animation. Three of five testers missed booking; one requested animation.

  1. The purpose is successful room booking, so the hidden action blocks the core task.
  2. Prioritise visible booking and retain the animation request as a lower-priority preference.
  3. Retest independent booking completion; the old feedback does not prove the revision works.

Explore each concept

Choose a concept, change its inputs and follow the explanation. Each example models the stated rule or scenario; completing it is practice rather than evidence of mastery.

  • Diverse perspectives
  • Driver and navigator
  • Shared tools and conflict resolution
Open this example on its own

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to explore: Pair programming and shared review
  1. Team approachpaired-reviewWaiting
  2. User evidencecolour-vision-barrierWaiting

Ready to explore: Pair programming and shared review

Why: Change an input, predict the first effect, then advance one step.

Try this: Change one input or choose another listed case. Predict the effect, reset and compare the states and governing rule.

Step through and experiment

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to experiment
  1. Input 1visible-and-labelledWaiting

Ready to experiment

Why: Predict the first change, then advance one step.

Try this: Compare text-only with visible-and-labelled. Which barrier remains?

Check a misconception

Claim: The most common suggestion must always be implemented.

Frequency matters, but relevance, severity and affected users also matter.

Guided practice

Write a decision record for this prioritisation.

Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.

Independent transfer

A tester using a screen reader still cannot book after the visual change. What should the team do?

Exit check

What is missing from “We changed the button, so the problem is solved”?

Write your reasoning before comparing with a classmate. If your teacher assigned this task, submit it through My classes to save your work and receive feedback.

Check yourself

  1. Question 1 of 2Which record best supports future collaboration?

    Select one answer.

  2. Question 2 of 2A minority user group cannot complete the core task. What follows?

    Select one answer.

Your practice so far

Check an answer to see its rationale.

Teacher guidance and scoring