<!-- Generated from applied-computing-au vic/unit3-4/sat/C08-2026/C08-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
# Modifying Designs with Annotations

*C8-2's first rungs: identify the design that needed changing (1–2) and annotate the before/after (3–4). The **why** is what lifts you higher — capture it as you go.*

## Ideation vs representation

Brainstorming, mind maps, mood boards and sketches **generate** ideas. Mock-ups, data dictionaries, object descriptions, IPO charts and pseudocode **document** designs. C8-2 modifications happen to the representation methods — the five below.

## The five design representations you can modify

| Method | Purpose | A modification looks like |
|---|---|---|
| **Mock-up / annotated diagram** | how the interface looks and works | layout, controls or navigation changed, with notes |
| **Data dictionary** | every data element: name, type, size, scope, purpose | a variable's type, range or purpose revised |
| **Object description** | classes/objects: properties, methods, relationships | a property added, a method split, a relationship changed |
| **IPO chart** | input → process → output for one function | a step added or an output redefined |
| **Pseudocode** | the planned logic | a branch or loop restructured before recoding |

## What a good annotation shows

- The **before** and the **after**, side by side — a screenshot of only the final version is not an annotation; the change has to be visible.
- **What** changed, marked directly on the design (arrow, highlight, callout).
- **Why** — pinned to the specific test result or feedback that triggered it.

## The change log

Track modifications as they happen:

| Date | Design element changed | Reason for change | Impact on project | Evidence |
|---|---|---|---|---|
| 15/03 | Added right panel for grades | Better UX — see individual results | Improved usability, clearer data display | Screenshot in OneNote |

**Evidence examples:** git commit, OneNote page, photo of a sketch, annotated screenshot, design file save.

## The causal chain (where 7–8 lives)

> test result → design problem → modification → improvement

In the viva you will be asked for the **specific test result** that drove each change, and it has to line up with your git history, dev log and C8-1 testing table. "I changed the layout" is 3–4; "TC004 showed the update silently failing, which meant the form design hid the save state, so I added the confirmation panel — now the failure is impossible to miss" is 7–8.