L3 Inquiry - Proposal

Context is the background situation that your inquiry investigated. 

A short context sets the scene so the reader understands what the inquiry is about. It helps you stay focused and prevents the proposal from drifting into a random “cool idea” that isn’t linked to the inquiry. 

Write 2-4 sentences:

• What is the situation/topic you investigated?

• Who/what is it connected to?

Context Examples

• “I investigated what makes short animations clear and engaging for a teenage audience, especially when viewers often watch on phones and may have sound off.”

• “I investigated barriers to participation in team sport at school and what supports students to feel confident, included, and motivated.”

• “I investigated how co-operative games can be engaging and accessible for teenage players with different skill levels and needs.”

This is the justification for why anything should be made at all. It anchors your proposal in evidence and makes it clear that the outcome is responding to a real need or opportunity.

Use bullet points or a short paragraph. Include:

• What is happening?

• Why is it a problem/opportunity?

• Who is affected?

• Include 1–2 pieces of evidence (source names in brackets)

Purpose is the reason your outcome should exist. It explains what change, benefit, or impact the outcome is intended to create because of the need you identified.

Purpose links the proposal back to the inquiry and helps ensure requirements are not random features — they should serve the purpose.

Write 2–4 sentences:

• What will the outcome help users do/understand/experience?

• Why is this needed (based on your inquiry)?

• What difference will it make if it exists?

Tip: Purpose is not “because I want to” - it’s the reason it should exist.

Purpose Examples

• “The purpose of my animation is to help teenage viewers understand the value of supportive team culture and feel encouraged to participate, by presenting clear, relatable scenarios that reflect real experiences.”

• “The purpose of my co-op game concept is to create an experience that is engaging for teens while supporting different skill levels through fair feedback and accessible design.”

• “The purpose of my website is to provide clear, trustworthy information for students so they can make safer decisions online.”

Digital outcomes are judged by how well they work for real people. Defining end users helps you make accurate decisions (features, tone, accessibility, complexity) and supports later testing. 

• Who is your target audience? Be specific (not “everyone”)

• Include majority users + any extreme users that matter

• Optional: describe where/when they will use it (device, time, environment)

End User Examples

• “Year 9–10 students at my school who play games casually and often play co-op with friends after school (majority users). Extreme users include beginners who rarely play games and players with accessibility needs (e.g., sensory overload, colour vision differences).”

• “Teen viewers (13–17) who consume short-form video on phones. Extreme users include viewers who watch with sound off, and viewers who need captions or clearer visual pacing.”

This is where you clearly state the proposed response to the inquiry. Describe it at a high level so the rest of the proposal can define what success looks like.

Answer in bullet points:

• What type of outcome is it? (game, animation, website, app, interactive media, etc.)

• What will it do at a high level?

• How does it answer the Big Question?

Proposed Digital Outcome Examples

• “A 60–90 second 2D animation aimed at teenagers that shows two contrasting team sport experiences (pressure vs support) and highlights practical ways teams can include and encourage people.”

• “A co-op game prototype concept with a short playable loop (tutorial + one level) that focuses on accessible onboarding and fair co-op mechanics.”

Scope protects you from overcommitting and scope creep. It helps you make something achievable and high quality. 

Include:

• What you will definitely include (MVP)

• What is out of scope (for now)

• Your constraints (time/tools/skills)

https://www.atlassian.com/agile/product-management/minimum-viable-product

Scope Example for an Animation

• In scope (MVP): 60–90 seconds, 2–3 scenes, 2 main characters, captions, original audio, simple backgrounds, one clear message.

• Out of scope: complex 3D environments, long cast, advanced VFX, multiple language versions.

• Constraints: time (X weeks), software access, rendering/export limits, skill level.

This is where you define what success looks like and how you will prove it.

Requirements (what success looks like)

Requirements describe what your outcome must achieve to meet user needs.
Aim for at least 5. Write them as “Must…” statements.

Examples:

• Must be easy for [user group] to navigate/understand

• Must clearly communicate [message/info]

• Must be accessible (captions, readable text, contrast)

• Must include attribution for external assets

• Must support [core interaction/function]

Specifications (how you will check/measure success)

Specifications are measurable checks that show whether requirements have been met.
For each requirement, include 1–3 specifications that are testable.

Step 1: Write 5+ requirements (Must…)

Step 2: Under each requirement, add 1–3 measurable specs (checked/tested) 

Step 3: Include what implication/s this requirement relates to most

Tip: A requirement is the goal. A specification is the proof.

Worked example for an animation

• Requirement: Must be accessible for a teenage audience

  • Spec: Captions provided for all spoken dialogue

  • Spec: Key on-screen text is readable on a phone screen (tested on at least 2 devices)

  • Spec: Contrast checked using a contrast checker for body text

Worked example for a game

• Requirement: Must teach players the controls without frustration

  • Spec: Tutorial takes under 2 minutes for first-time players (tested with at least 3 users)

  • Spec: At least 80% of testers can complete the tutorial without asking for help

  • Spec: Player receives clear feedback after each action (visual + audio or visual-only option)

This is the feasibility checkpoint. Show what you have access to and what you still need.

What do you have access to in order make your outcome:

• software/tools

• hardware/equipment

• skills you already have + skills you need to learn

• time available

• people/expertise you can access (teachers, mentors, experts)

Resources Example

• Software: Blender/After Effects

• Hardware: school PCs + drawing tablet

• Skills to learn: lip sync and audio mixing

• Time: 6 weeks 

• Support: teacher feedback + 2 peer testers + coach interview.

This directly targets the Merit requirement: evaluating strengths and weaknesses of the proposed outcome. It helps you identify what needs improving before you start building.

• Strengths (why this is a good proposal):

• Weaknesses/limitations (what might not work well / what could be improved):

• How I will reduce the weaknesses / next steps:

S&W Example

• Strengths: Clear target audience; achievable scope; requirements link to research; accessible by design.

• Weaknesses: Limited time for complex animation; risk of message feeling preachy; limited testing sample.

• Next steps: Keep MVP short; test storyboards early with target users; add humour/realistic moments; schedule at least 2 feedback cycles.