The Hamilton and Alexandra College · Year 12 · 2026

The C5-2 Annotation validation is a 30-minute written test under **no AI, no internet** conditions. You bring in only your printed design log / photo journal. You receive a 6-slot sheet, and each slot is locked to a rubric band by a single verb. The problem most students don't see coming: they write confident-sounding notes that secretly stay at "identify" level — and only discover this during the timed session, when it is too late.

This page teaches the ladder by showing you one concrete design-log entry rewritten up all four rungs.

---

Each rung adds something the rung below does not have. You cannot skip rungs.

---

The example entry: **high contrast on the login button** (a real design-log entry — Design Log #3, 15 April).

| Rung | Band | The annotation |

|------|------|----------------|

| **Identify** | 3–4 | "I applied contrast to my login button." |

| **Describe** | 5–6 | "I applied contrast (design principle) by changing the login button from light grey to a high-visibility blue (#1A73E8 on white). This affects appearance by making the button stand out from surrounding text, and affects functionality by directing user attention to the primary action on the screen." |

| **Document** | 7–8 | "I applied contrast as above. In Design Log #3 (15 April), I recorded that during a user test, two of three testers initially clicked the wrong element; after increasing the colour contrast ratio to 4.8:1, all three testers clicked the correct button on the first attempt. The iteration from grey to blue was a direct response to that test note." |

| **Explain** | 9–10 | "I applied contrast as above (Design Log #3, 15 April). If I removed the high-contrast blue and returned to grey, the button would lose its affordance (UX characteristic) — users would not perceive it as the primary interactive element, increasing error rate and reducing usability (UX characteristic). There is a trade-off: high contrast dominates the visual field, potentially reducing balance (design principle) on the page. I accepted that trade-off because the primary function of the login screen is a single action, so guiding attention outweighs distributing it evenly." |

Notice what each rung adds:

- **Describe** adds: *how* (appearance + functionality), not just the name.

- **Document** adds: a *specific journal entry reference* with a user-test result or iteration.

- **Explain** adds: *what would break* without the choice, or a *named trade-off* between two principles/characteristics.

---

Your annotation sheet has six slots with fixed verb targets:

| Slot | What you write | Target band |

|------|----------------|-------------|

| 1 | **Identify** a design principle visible in one journal entry | 3–4 |

| 2 | **Identify** a UX characteristic in a different entry | 3–4 |

| 3 | **Describe** how a principle is applied — appearance AND functionality | 5–6 |

| 4 | **Document** how a UX characteristic is applied — citing journal evidence | 7–8 |

| 5 | **Explain** how a *selected* principle AND UX characteristic combine in one design choice | 9–10 |

| 6 | **Explain** a tension between two principles or characteristics, and the trade-off you accepted | 9–10 |

---

Aim for **4 or more entries** before the validation. Every entry is a potential annotation source — you can only cite entries that exist in your printed journal.

Each entry should include:

- The date and which design artefact you were working on

- The design principle or UX characteristic you applied (use the exact study-design name)

- A before/after description (sketch, screenshot, or written description)

- Any user-test result, feedback, or constraint that influenced the decision

---

This names the principle but says nothing about how it was applied (appearance or functionality), cites no journal entry, and gives no reason. It scores at most band 4.

Generic statements without a specific entry reference do not score under the document or explain bands. The marker needs to know *which* entry — date, entry number, or both.

This describes a visual feature. An annotation must name the *principle or characteristic* the feature demonstrates and explain *why* that principle is at work — not just what the feature looks like.

---

**🎯 Watch for:** how the same design-log entry sounds completely different at each rung — and what one specific addition takes you from "identify" to "explain" in your annotation.

---

1. A student writes: "I used alignment to organise my navigation bar." Which rung is this on, and what is the single most important thing they need to add to reach the next rung?

>| **Rung: Identify (band 3–4).** To reach Describe (band 5–6), they need to say HOW alignment was applied — what changed in the appearance of the navigation bar, and how that affects functionality (e.g. "users can scan menu items in a single left-to-right sweep").

2. Slot 5 requires both a design principle and a UX characteristic in one annotation. Write the names of all 7 design principles and all 4 UX characteristics from memory — then check yourself against [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics).

>| **Design principles (7):** alignment, balance, contrast, space, text formatting, usability, navigation. **UX characteristics (4):** affordance, interoperability, security, usability. Note that **usability appears in both lists** — they mean different things in each context.

3. You are writing a Slot 6 "explain" annotation about a trade-off between contrast and balance. What two things must your annotation include that a "describe" annotation would not?

>| (1) A **specific journal entry reference** showing where the decision was made (date / entry number / artefact). (2) An argument about the **trade-off** — what you gain from high contrast, what you sacrifice in balance, and why you chose to accept that cost. Simply saying both principles are present is not enough.

---

- [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics)

- [C05 Resources](/sd/Resources/C05-Resources)

---

← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)