← Summarising the development of a digital outcome

Evaluating development-process decisions (the older template's Question Two)

Some years' tasks ask directly for decisions made DURING development (choice of expert, project management, design process, testing method, or specific tools) — a distinct skill from the requirement/trade-off write-up.

The full shape of a decision write-up

• NAME THE DECISION: what specifically was decided (e.g. "I chose to test with three younger siblings rather than classmates").
• EXPLAIN WHY: what made this the chosen option over the alternative at the time.
• JUDGE HOW WELL IT WAS CARRIED OUT: was the decision executed effectively, or did something go wrong in the execution even if the choice itself was reasonable?
• STATE THE FLOW-ON EFFECT: how did this decision affect the OUTCOME itself — a feature added, a bug caught early, a design changed as a direct result.

Worked example Evaluating a testing-method decision Evaluate a decision to test a children's reading app with the target age group instead of adult classmates. THE DECISION: tested with three 8-year-olds (the actual target audience) rather than classmates, despite classmates being far easier to access during school hours. WHY: classmates' feedback on a children's app would not reflect how an actual 8-year-old reads, taps, or gets confused — the decision traded convenience for validity. HOW WELL CARRIED OUT: the testing session itself ran smoothly, but only three children were available, which is a small sample — the decision was sound but its EXECUTION had a real limitation worth naming. FLOW-ON EFFECT: two of the three children could not find the "next page" button, directly leading to it being enlarged and moved to a fixed position — a concrete feature change traceable to this decision. ✓ A complete evaluation names a REAL limitation in execution even for a good decision, and traces a SPECIFIC resulting change in the outcome — a decision write-up with no resulting change described is incomplete. ✕

Describing a decision without judging how well it was carried out

Explaining WHAT was decided and WHY, without then judging whether the decision was executed well (or naming a limitation in its execution), stops at Achieved-level description. The evaluation ("how well was it carried out, and what was the flow-on effect") is where the Merit/Excellence marks actually sit.

Step	What to write
1. Name the decision	What was specifically decided
2. Explain why	Why this option over the alternative
3. Judge execution	How well it was carried out — including any limitation
4. Flow-on effect	The specific resulting change to the outcome

Practice for this standard covers the whole topic — flashcards and quiz.