L2 - Proposal

Context - the circumstances that form the setting for the idea.

The context is the background information. It's the situation that forms the setting for your idea. You should be able to copy and paste the context from your inquiry and depending on where your inquiry lead, you may need to adjust. Remember this can be a story, a sentence, a paragraph, a statement.

Write 2-4 sentences:

• What is the situation/topic you investigated?

• Who/what is it connected to?

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.

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)

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.

You may need to justify why your product is a good idea. Some possible ideas you can use to justify why it is could be:

• What feedback did you get

• Expert Opinion

• Market Analysis

• Academic Research

• Similar Products

• How it relates to the requirements

For example:

"I am going to make a science fiction top down shooter game because ..."

• The people that I asked for feedback thought the idea of playing a giant space squid was a cool and original idea.

• Extra Credits said that top down shooters are one of the easiest genres to make.

• Games like Nuclear Throne and Helldivers are very popular games with millions of copies sold