Summative project · Lessons 7–8
Interactive Outcome Challenge
Build something another person can use. Test it. Improve it. Explain the code that made it work.
Interactive Outcome Challenge
Ngā Whāinga Ako | Learning Intentions
- Design and code an interactive digital outcome for an intended audience.
- Test accessibility, usability and function against clear specifications.
- Use evidence to debug and improve the outcome.
Paearu Angitu | Success Criteria
- My project uses a start event, ordered sequence, loop and conditional.
- Another person can use it without me explaining every step.
- My log shows a test, a bug or usability issue, and a justified revision.
- I can explain one important block sequence and one design decision.
Curriculum alignment: Phase 3 Technology statements 51630 and 51629. See the verified curriculum companion.
1. Choose a purpose
Create a quiz, interactive story, simulation, tutorial or small game that helps a real audience practise, learn or explore something they value. You may use a fictional audience if privacy or permission makes a real context unsuitable.
My intended audience and their need:
Three measurable specifications:
Manaakitanga and permission check: I have used only media I made, may reuse, or have permission to use. I have not copied local stories, reo recordings, names or taonga without authority.
2. Plan the algorithm
Show inputs, ordered actions, repeated actions, a decision and outputs. Use pseudocode, a flowchart or labelled Scratch blocks.
3. Build and checkpoint
Swipe sideways to view all columns.
| Checkpoint | Evidence | Done |
|---|---|---|
| The project starts reliably. | Screenshot, block sketch or teacher check | ☐ |
| A loop controls a repeated action. | Explain what repeats and when it stops. | ☐ |
| A conditional changes the program. | Name the condition and both possible results. | ☐ |
| Instructions and controls are accessible. | Readable text, clear controls, sound alternative if needed. | ☐ |
4. User-test log
Swipe sideways to view all columns.
| What I expected | What the user did or said | One focused change | Retest result |
|---|---|---|---|
5. Explain the learning
The code sequence I am proudest of:
A bug or usability problem that taught me something:
The evidence that justified my final change:
Project rubric
Swipe sideways to view all columns.
| Dimension | Emerging | Secure | Extending |
|---|---|---|---|
| Algorithm and code | Some ordered code works with support. | Sequence, event, loop and conditional work together for the intended result. | Code is well organised and includes an additional purposeful feature. |
| Testing and debugging | A change is made but evidence is limited. | The log links a focused test to a justified revision and retest. | Several test cycles compare solutions or expose a deeper cause. |
| Audience, access and manaakitanga | Audience or controls need clarification. | A user can operate the outcome; media and local content are used responsibly. | Specific accessibility evidence shapes the final design. |
| Explanation | Names features with prompting. | Explains how key code and design choices serve the purpose. | Explains trade-offs, limitations and a sensible next improvement. |
Submit: the working project, this completed record, and a two-minute explanation.
What to submit
- A link or saved copy of the working project.
- This completed planning and test record.
- A two-minute live explanation or recorded walkthrough.
Resources already provided: this brief, the lesson examples, Scratch and a device-sharing pathway. No account or public posting is required.
Linked next step: Save the finished outcome to My Kete or adapt it in Creation Studio when your kaiako directs you.