C06 · Topic 1.3 · 40 minutes · CRD-2.E, CRD-2.F, CRD-2.G, CRD-2.H
Iterating, documenting and evaluating
By the end you can:
- Use test evidence to prioritise a revision.
- Write documentation for users or collaborators.
- Evaluate whether a change meets its requirement.
Before this lesson: topics 1.2.
- Requirement
- A condition the solution should satisfy for its intended users.
- Iteration
- Revising a design through repeated development and evaluation.
Understand
A useful revision has a reason linked to evidence. Record what failed, the proposed change, the expected effect and how to evaluate it. Changing unrelated features at the same time can make it harder to know what caused an improvement or a new problem.
Documentation serves an audience. A user guide explains how to perform a task and recover from errors; internal documentation explains decisions, interfaces and code purpose for collaborators. Comments that merely repeat a statement are less useful than explaining a non-obvious reason or constraint.
Worked example
After a visible booking action is added, five new fictional testers all find it; one still misreads room status.
- The discoverability evidence improved for this small test, but it does not prove success for all users.
- The status requirement still needs attention; do not hide that failure in an overall success claim.
- Document the remaining issue and retest a text/icon design with affected users.
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.
- Requirements and prototypes
- Incremental versus iterative work
- Comments, documentation and acknowledgement
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
- Development approachiterateWaiting
- Documentation audienceuserWaiting
Ready to explore: Iterative development and documentation
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
- 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: Passing one test means the whole design is finished.
A test provides evidence for its conditions, not every requirement or future use.
Guided practice
Write a short user instruction for a failed booking because a room just filled.
Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.
Independent transfer
Write an internal note explaining why status uses text as well as colour.
Exit check
What evidence is needed before claiming the status revision works?
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
Your practice so far
Check an answer to see its rationale.