3. Content and curatorial approval
Content readiness affects the schedule. A developer cannot finish a translated activity while its wording is still awaiting approval.
Plan a museum touchscreen, digital exhibit or visitor companion. Agree the audience, content, hardware, accessibility, budget and handover before commissioning development.
Use this checklist with your curator, learning team, access lead, IT team and chosen developer. Start before requesting proposals, revisit it at prototype review, and agree the acceptance worksheet before full production.
For a gallery touchscreen, focus on visitor flow, reset behaviour and daily operation. For a visitor companion, also agree supported devices, connectivity and use beyond the museum. If you are replacing an existing exhibit, first establish what source files, assets and accounts you can recover.
Tick a decision once it is agreed, or record why it does not apply. Add unresolved questions, owners and next actions in the notes. This is a planning aid, not an installation approval.
Your entries stay on this page until you leave or reload. Download or print a copy to keep them. No sign-up required.
0 of 40 decisions recorded
Start with the visitor experience. A short gallery activity and a companion used at home need different briefs.
Name who supplies each physical component. Include the museum's IT and facilities teams before agreeing installation dates.
Content readiness affects the schedule. A developer cannot finish a translated activity while its wording is still awaiting approval.
Agree requirements with the museum's access team and involve disabled visitors in testing. Consider the physical installation alongside the software.
Ask suppliers to price the same scope. Compare the complete installation and its ongoing costs, with assumptions clearly stated.
Write acceptance criteria before production. Use the worksheet below to record the required behaviour, test evidence and sign-off owner.
Make the handover usable by the people on the gallery floor. Include a plan for the end of the exhibition.
Adapt these examples to your installation before agreeing them with your supplier. Replace unspecified durations and requirements with your agreed values, then record who will test and approve each item.
Suggested evidence: A complete walkthrough on the installation hardware with the network disconnected.
Suggested evidence: Test abandonment at each main activity and record the reset behaviour.
Suggested evidence: A dated test log covering repeated sessions, faults and recovery.
Suggested evidence: Results from access checks and representative visitor testing, with unresolved issues recorded.
Suggested evidence: A witnessed staff walkthrough and a copy of the final operating guide.
During earlier employment at fish in a bottle, our director worked on rebuilding the Museum of London's Great Fire of London game from Flash to HTML5. The original source code was unavailable, so the behaviour had to be reconstructed from the playable experience.
For a new commission, turn that lesson into a handover requirement: agree which source files, assets, build instructions and account access the museum receives, where they will be stored and who will maintain them. Read the Fire of London case study or explore legacy modernisation.
For web-based interactives, W3C's accessibility planning resources explain how to assign responsibilities and involve users throughout a project. Agree the physical installation requirements with your museum's access team too.
Our museum interactive development page covers how we can help. Use the development cost guide for wider budget context and the brief builder to organise your project requirements.
Use your completed checklist to shape the conversation. Tell us about the experience, available hardware and decisions you need help making.
Discuss your museum brief