Blame
|
1 | # C04 → C05 — Choose, then Detail |
||||||
| 2 | ||||||||
| 3 | The Hamilton and Alexandra College · Year 12 · 2026 |
|||||||
| 4 | ||||||||
| 5 | C04 and C05 sit back-to-back in the SAT and share the word *design*, so they're easy to blur. The distinction is simple once you see it: **C04 decides *which* idea; C05 specifies that idea precisely enough to build.** |
|||||||
| 6 | ||||||||
| 7 | --- |
|||||||
| 8 | ||||||||
| 9 | ## The one-sentence rule |
|||||||
| 10 | ||||||||
| 11 | | Criterion | In one sentence | The question it answers | |
|||||||
| 12 | |---|---|---| |
|||||||
| 13 | | **C04** — Generating Design Ideas & Evaluation Criteria | Explore *several* rough design ideas, then use evaluation criteria to choose one | "Which design should proceed — and why?" | |
|||||||
| 14 | | **C05** — Producing Detailed Designs | Take the *chosen* idea and detail it until someone else could build it | "Exactly how is this built — every screen, field and step?" | |
|||||||
| 15 | ||||||||
| 16 | The shift is **breadth → depth**: C04 is *divergent* (many options, then a decision); C05 is *convergent* (one option, fully specified). |
|||||||
| 17 | ||||||||
| 18 | --- |
|||||||
| 19 | ||||||||
| 20 | ## One picture |
|||||||
| 21 | ||||||||
| 22 | C04 fans *out* into options and funnels *in* to a decision. C05 takes that single decision and fans it back *out* — but this time into detail, not alternatives. |
|||||||
| 23 | ||||||||
| 24 | ```mermaid |
|||||||
| 25 | flowchart LR |
|||||||
| 26 | I1["Idea A"] --> M{{"Evaluation matrix<br/>C04 · choose which"}} |
|||||||
| 27 | I2["Idea B"] --> M |
|||||||
| 28 | I3["Idea C"] --> M |
|||||||
| 29 | M ==>|"the chosen design"| D["Detailed design<br/>C05"] |
|||||||
| 30 | D --> T1["Mock-ups"] |
|||||||
| 31 | D --> T2["Data dictionary"] |
|||||||
| 32 | D --> T3["IPO charts"] |
|||||||
| 33 | D --> T4["Pseudocode"] |
|||||||
| 34 | D --> T5["Object descriptions"] |
|||||||
| 35 | ``` |
|||||||
| 36 | ||||||||
| 37 | --- |
|||||||
| 38 | ||||||||
| 39 | ## Side-by-side |
|||||||
| 40 | ||||||||
| 41 | | | **C04** | **C05** | |
|||||||
| 42 | |---|---|---| |
|||||||
| 43 | | What you produce | Several rough ideas + an evaluation matrix | One detailed design of the chosen idea | |
|||||||
| 44 | | Mindset | Explore, then **decide** | Commit, then **detail** | |
|||||||
| 45 | | Key tools | Mood board, brainstorm, mind map, annotated sketches | Mock-ups, data dictionary, IPO charts, pseudocode, object descriptions | |
|||||||
| 46 | | Output's job | **Justify a choice** | **Be buildable** | |
|||||||
| 47 | | Leans on | Your SRS (C03) and design brief | Your C04 decision | |
|||||||
| 48 | ||||||||
| 49 | --- |
|||||||
| 50 | ||||||||
| 51 | ## The trap |
|||||||
| 52 | ||||||||
| 53 | C05 is **not** "make the C04 sketch look nicer." A rough idea becomes a *detailed design* when another person could build from it **without asking you what you meant** — exact data types in the data dictionary, real logic in the pseudocode, every control annotated on the mock-up. That buildable precision is the whole point of C05. |
|||||||
| 54 | ||||||||
| 55 | > [!TIP] |
|||||||
| 56 | > **Architect's analogy:** C04 is sketching three concepts and arguing for one. C05 is drawing the construction blueprints for the concept that won. You can't blueprint what you haven't chosen — so C05 depends on the C04 decision. |
|||||||
| 57 | ||||||||
| 58 | --- |
|||||||
| 59 | ||||||||
| 60 | ## Check Your Understanding |
|||||||
| 61 | ||||||||
| 62 | 1. In one phrase, what does C04 decide that C05 then assumes? |
|||||||
| 63 | >| *Which* design idea proceeds. C05 details that already-chosen idea — it doesn't re-open the choice. |
|||||||
| 64 | ||||||||
| 65 | 2. Breadth or depth — which word fits C04, and which fits C05? |
|||||||
| 66 | >| C04 = **breadth** (several ideas, then choose). C05 = **depth** (one idea, fully specified). |
|||||||
| 67 | ||||||||
| 68 | 3. A student repolishes the colours and fonts of their C04 sketch and submits it as their detailed design. What's missing? |
|||||||
| 69 | >| Buildable detail — data dictionary, IPO/pseudocode logic, annotated controls. "Looks nicer" is not "detailed enough for someone else to build." |
|||||||
| 70 | ||||||||
| 71 | --- |
|||||||
| 72 | ||||||||
| 73 | ## See also |
|||||||
| 74 | ||||||||
| 75 | - [Efficiency vs Effectiveness](/sd/C04/Efficiency%20vs%20Effectiveness) — the key distinction *inside* C04's evaluation criteria |
|||||||
| 76 | - [Design Principles vs UX Characteristics](/sd/C05/Design%20Principles%20vs%20UX%20Characteristics) — a distinction *inside* C05 |
|||||||
| 77 | ||||||||
| 78 | --- |
|||||||
| 79 | ||||||||
| 80 | ← [C04 Home](/sd/C04/C04-home) · [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
|||||||
