WDD15 - Evaluation: fitness for purpose and usability
- I can evaluate a website against fitness for purpose.
- I can evaluate a website against usability.
- I can support an evaluation judgement with specific evidence from testing, not just opinion.
- I can explain what fitness for purpose and usability each mean for a website, and how they differ.
- I can write an evaluation citing a specific piece of test evidence for each criterion.
- I can explain why WDD's evaluation uses only two criteria rather than more.
WDD15's evaluation is only possible because of WDD1's requirements and WDD14's testing.
Key vocabulary
Two evaluation criteria, not five
WDD's evaluation stage is deliberately narrower than SDD's
The SDD unit evaluates a finished program against five criteria: fitness for purpose, efficient use of coding constructs, usability, maintainability, and robustness. WDD's evaluation stage is narrower, and deliberately so - it assesses a finished website against only two of those: fitness for purpose and usability. There is no WDD equivalent of evaluating code efficiency, maintainability, or robustness, because WDD's own spec draws the evaluation boundary there specifically, not because these ideas are unimportant in general.
Evaluating fitness for purpose
Fitness for purpose asks a direct question: does the finished website actually do what its functional requirements, identified back in WDD1's analysis stage, said it should do? A genuine evaluation checks each requirement against the finished site's actual behaviour - not a general impression of whether the site "seems fine," but a specific comparison between what was required and what was delivered.
Evaluating usability
Usability asks whether the site is easy and pleasant for real users to use - can a persona actually complete their scenario without confusion or difficulty? This is exactly why WDD14's testing exists before WDD15's evaluation: usability is evaluated using the evidence testing produced (which test cases passed, which devices and browsers worked correctly), not from a personal opinion formed independently of any testing.
a form that technically works
Worked examples
A navigation bar's links all lead to the correct pages (confirmed by WDD14's link testing), but usability testing found several pupils could not tell the links were clickable because they looked identical to plain text. Evaluate this feature against both criteria.
Fitness for purpose: met - the navigation correctly leads to every intended page, confirmed by link testing.
Usability: not fully met - pupils in testing could not identify the links as clickable, a genuine usability problem despite the underlying links working correctly.
- Giving one vague overall impression instead of two named judgements. "The website is good" evaluates nothing specific - fitness for purpose and usability should each be judged individually.
- Confusing fitness for purpose with usability. A site can correctly do what it is required to do while still being difficult or unpleasant to use, and vice versa - they are genuinely separate judgements.
- Evaluating from opinion instead of cited test evidence. A strong evaluation names a specific test result (a passing or failing test case, a device compatibility finding) rather than a general feeling.
- Assuming WDD evaluates the same five criteria as SDD. Efficient coding constructs, maintainability and robustness are SDD-only criteria - WDD's evaluation is deliberately limited to fitness for purpose and usability.
Name fitness for purpose and usability as the two distinct criteria, and always support each judgement with a specific piece of cited evidence from testing - a named test case result or a specific device/browser finding - rather than a general impression. Do not list SDD's other three evaluation criteria (efficient coding constructs, maintainability, robustness) for a website evaluation question - they are not part of WDD's scope.
Task Set A - Core questions
Task Set B - Extension
File this in OneNote under:
Higher Computing Science > Web Design & Development > WDD15
Timing: content is scoped for a single period but this lesson lands on a double (Mon 14 Dec 2026, per WDD.md §2a/§4 table) - same "extra time" pattern as WDD6/8/9/12. Core pace: 6 min warm up, 15 min two-criteria notes + context box, 15 min Examples 1-3, remaining time on Task Set A. Use the spare second period for Task Set B and, if time allows, for pupils to draft a real evaluation of their own WDD1-14 practical work ahead of the Assignment.
Scope control: deliberately limited to fitness for purpose and usability only - per WDD.md §"WDD's evaluation stage is deliberately narrower than SDD's", confirmed against both course-spec.html and the SQA PDF directly, with no maintainability, efficiency or robustness criterion. If SDD22's five-criteria evaluation-table component is ever reused visually for this lesson, it must be rebuilt with two rows, not five.
This is the lightest-content lesson in the WDD unit by design - Chris teaches this content as half of a single lesson (L14) alongside all of WDD14's testing content. Giving it a full lesson here is deliberately generous, not padding, and the spare time from landing on a double period should go toward genuine practice evaluating pupils' own work rather than new content.