Price a defined experience
“An interactive screen” can mean an existing game with new artwork, a product configurator or a sensor-controlled experience developed from the beginning. Their budgets are not comparable until the visitor action, result and delivery conditions are specified. Start with a brief that describes the complete session and the event where it must work.
Ask the supplier to identify what already exists, what will be adapted and what must be created. Then separate work done once from costs repeated at each event. This makes it possible to discuss a smaller version without losing track of what the audience will actually receive.
Build the budget around deliverables
| Package | Deliverable to describe | Question affecting scope |
|---|---|---|
| Concept and interaction | Guest journey, control method and session rules | Is the mechanic agreed or still being explored? |
| Prototype | A test of the uncertain behaviour | Which question must it answer before production? |
| Software | Working application and agreed integrations | How many modes, users, languages and interfaces? |
| Content | Graphics, text, animation, sound or 3D assets | What usable material does the client supply? |
| Hardware and build | Displays, inputs, computers and physical integration | Which venue and mounting arrangements are confirmed? |
| Testing | Functional, user and installation checks | Which devices and difficult scenarios are included? |
| Event delivery | Transport, setup, calibration, operation and removal | Who runs the guest cycle and handles recovery? |
| Future use | Agreed handover, maintenance and adaptation scope | What is included for a second venue or campaign? |
A line called “development” should explain its boundaries. Content creation, data export or on-site operation may be separate services. List these interfaces before comparing totals.
Use a prototype to settle an expensive unknown
GOV.UK's prototyping guidance distinguishes exploring an interaction from building a production service. Its guide explains why a prototype is not automatically production-ready. For an installation, the useful question may be whether newcomers understand a gesture or whether the sensor works with the proposed product surface.
Give the prototype an acceptance question and a decision date. Ask what is included if the test suggests changing direction. A small proof can be valuable without polished artwork, while a beautiful animation may leave the difficult interaction untested.
Worked comparison: two product experiences
Imagine a hypothetical stand asking visitors to choose a product variant and see a branded result. Option A adapts an existing touchscreen experience with approved graphics and a limited set of choices. Option B creates a new spatial interaction where hand movements manipulate a custom 3D product.
For A, confirm the existing mechanic, allowed changes, supported device, language updates and the tests needed after branding. For B, add interaction exploration, 3D asset preparation, sensor integration, testing with unfamiliar users and calibration at the stand. Both options still require a clear session end, reset and operational handover.
Compare the result as well as the cost packages. If the commercial goal is a short product conversation, ask whether the added spatial interaction contributes enough to that goal. If movement is central to the campaign idea, a simple touch adaptation may fail the brief despite requiring less new work.
Make revisions and inputs explicit
Agree who supplies logos, product information, translations, audio and usable 3D files. A visual reference or engineering model may need additional preparation before it can appear in the experience. Ask the supplier to assess the actual files before treating them as ready-to-use assets.
Set review stages for the mechanic, interface, content and integrated build. Identify who consolidates client feedback and which changes reopen previously approved work. This is especially useful when several brand or agency stakeholders review at different times.
Look beyond the first event
If reuse matters, ask what can be changed by the client, what requires developer work, which licences cover the intended use and what handover is included. Confirm responsibility for software updates, replacement hardware and retesting at a new venue. Do not assume that paying for development automatically defines all future rights or support.
Compare a first-event total and a clearly scoped repeat-event option. Reusable software may still need logistics, equipment, content updates and on-site checks. Keep those items visible instead of describing the second event as a free repetition.
Before requesting a quote
Define the visitor task, control method and complete session.
List existing assets and integrations with examples.
Specify languages, stations, venue and schedule.
Separate required results from optional features.
Ask for prototype, review, acceptance and event-support scope.
Send the brief to interactive installation design or event application development. Request alternatives described through the experience and work included, so the budget decision is concrete.