Embedded Files
LAUNCH
LAUNCH
Delivery is about getting your finished outcome ready to be used in its intended environment. This could mean publishing a website, exporting a video for its viewing platform, preparing graphics for print, or building a game so it runs on the intended device.
Something that works in your editing software may look or behave differently once it is delivered. Checking your outcome in the setting where people will actually use it helps you confirm that it works as intended, presents well and meets their needs. This final stage brings together preparing your outcome for use and evaluating how successfully your development decisions have supported the finished result.
Task 1 - FINAL OUTCOME
Task 1 - FINAL OUTCOME
Present your completed outcome so someone can clearly see what you have created and how it works for your intended users.
Include:
At least two images: one showing your working file in the software used, and one showing the finished outcome as the user would see or experience it.
Access to the final outcome: include the appropriate files, export or working link. Add a short screen recording if images cannot show how it functions. This maybe a link to a file in your google drive folder - make sure sharing is 'Anyone with the link can view'
A brief introduction: explain what your outcome is, who it is for and what it is intended to do.
Check that your final version opens or plays correctly, that links and sharing permissions work, and that all required assets are included.
Task 2 - FILES
Task 2 - FILES
Provide a link to an organised Google Drive folder containing your project files. Check that your teacher can access the folder and everything inside it using the required sharing settings.
Include:
Working files from each sprint: the original editable files from the software you used, showing how your outcome developed.
Assets and source files: the images, audio, video, code or other content needed to open and work with your project.
Exports from each sprint: the versions you used for testing, feedback or review.
Final deliverable files: clearly label the completed version intended for use.
Use clear folder and file names so someone else can identify what each item is and which version it belongs to. Check that your working files open correctly and that any linked assets are included.
Keep earlier versions so you can show your progress and recover work if needed.
Using GitHub? Provide a link to your repository and your published website. Make sure your teacher can access both, and clearly identify the versions used at each sprint milestone. Your repository can hold your working files and version history; use Google Drive for any additional assets or supporting records. You do not need to duplicate files already accessible in your repository.
Task 3 - EVALUATION
Task 3 - EVALUATION
Evaluate both your final outcome and the process you used to develop it. Use specific examples from your project to explain what worked, what changed and why those decisions mattered.
Refer to screenshots, trials, testing, feedback and planning records already in your development document. You do not need to repeat your whole development journey.
Your final outcome
How well does your outcome meet your proposal, requirements and intended users’ needs? Support your judgement with testing results and feedback.
Which advanced tools and techniques contributed most to the outcome? Explain how you used them and why they suited the purpose.
How did you apply conventions appropriate to your media type, such as layout, typography, navigation, pacing or visual consistency? Explain how these improved the user’s experience.
How did you maintain data integrity? Give relevant examples of how you kept content and assets accurate, complete and usable when editing, transferring or exporting them.
Identify at least two relevant implications you considered, such as accessibility, usability, intellectual property, privacy or cultural considerations. Explain why they mattered for your project, what you did to address them and how successful this was.
What limitations remain, and what would you improve next? Explain the difference those improvements would make.
Your development process
How did breaking your outcome into smaller components help you plan and develop it?
What alternative approaches, components or techniques did you trial? Compare the results and explain why you selected the most suitable option.
How did testing and feedback lead to improvements? Explain what you found, what you changed and how you checked that the change was effective.
Show how your outcome improved across development. Include improvements to its quality or functionality as well as fixes to errors.
How did your project management help you make decisions? Give examples of how you changed tasks, priorities or time allocations in response to progress, trials or testing.
How did you manage versions and backups so you could track changes and protect your work?
Which tools or working methods made production more efficient? Explain how these helped you maintain quality, reduce repeated work or make changes consistently.
Bring it together
Finish by discussing how information from your planning, component trials and testing helped you produce a high-quality outcome. Connect the information you gathered to the decisions you made and the effect on the finished result.
Avoid general comments such as “testing helped” or “my planning went well”. Explain the connection:
“Testing showed that users missed the instructions. I added a task to trial two different placements, then selected the version users noticed before starting. Retesting showed that they could begin without help, making the final outcome easier to use.”
Page updated
Report abuse