Festival Branded AR Filter Requirements in Singapore

A festival branded augmented reality filter needs more than an attractive visual concept. Buyers must define where the experience will run, who should be able to use it, how it supports the festival journey and what must happen when devices, connectivity or platform behaviour vary. These decisions affect creative production, testing, publishing and live operations.

Use this guide to build a requirements brief that agencies, developers and internal stakeholders can interpret consistently. Get Out! Events can scope and deliver suitable experiences through GO Labs, with final functionality dependent on the agreed brief, selected tools and applicable platform rules.

1. Define the operational purpose

Start with one primary audience action. A filter might help guests create branded content, interact with a performer-inspired effect, reveal festival information or participate in a simple visual challenge. Combining too many purposes can make the experience slower, harder to explain and more difficult to test.

Record the intended user, location and moment. For example, specify whether the experience is designed for ticket holders waiting at an entrance, visitors near a sponsor zone or remote audiences following the festival online. This context determines the activation method, visual environment and level of staff guidance required.

• Primary action: State what the guest should do in one sentence.
• Festival moment: Identify when and where discovery should happen.
• Desired completion: Define the visible end state without assuming that every user will publish or share.
• Ownership: Name the stakeholder responsible for creative, legal, platform and operational approvals.

2. Specify access and platform dependencies

The brief should name the intended platform, supported access route and account ownership. A QR code, link, profile destination or in-app discovery route can create different user steps. Platform availability, publishing permissions and supported features may change, so requirements should distinguish mandatory outcomes from preferred implementation methods.

Define whether users need a particular application, account state, camera permission or internet connection. Buyers should also document minimum supported devices or operating-system ranges where these can be tested reliably. Avoid promising universal compatibility because performance can differ across hardware, browsers, application versions and network conditions.

Required access information

• Target platform and intended publication account
• Approved discovery routes and backup instructions
• Expected user permissions and sign-in conditions
• Supported orientation, camera mode and audio behaviour
• Fallback content if the effect cannot load
• Named owner for platform submission and approval responses

3. Translate the brand idea into functional requirements

Functional requirements describe observable behaviour rather than subjective ambition. Replace “make it immersive” with specific interactions: a graphic follows the user’s face, an object appears when the rear camera detects a suitable surface, or an animation begins after an on-screen gesture. State the intended duration, restart behaviour and response when detection is lost.

Provide approved logos, campaign artwork, typefaces, colour references, key messages and usage restrictions in production-ready formats. Include performer, sponsor and venue approval dependencies where relevant. Music, likenesses, trademarks and other third-party material should not enter production until the buyer confirms that appropriate permissions have been considered.

For broader context on the experience itself, review the festival branded AR filter guide. If procurement is still being structured, the festival AR filter vendor selection guide covers supplier evaluation as a separate decision.

4. Set measurable acceptance criteria

Acceptance criteria should allow reviewers to decide whether a build passes without relying on personal preference. Each criterion needs a test condition, expected result and responsible approver. Creative quality still matters, but visual approvals should reference agreed storyboards, assets and brand rules.

• Launch: The approved access route opens the intended experience under documented test conditions.
• Interaction: Each trigger produces the specified response and can be restarted as agreed.
• Brand accuracy: Approved artwork, wording, colours and required acknowledgements match signed-off assets.
• Performance: Loading and interaction remain usable on the agreed test-device set, subject to network conditions.
• Failure handling: Loss of tracking, denied permissions or weak connectivity produces an understandable recovery path.
• Publishing: The final build satisfies the selected platform’s review requirements at the time of submission.

5. Include accessibility from the first brief

Do not treat accessibility as a final visual check. Avoid making audio the only way to understand an interaction. Provide readable on-screen guidance, sufficient contrast and enough time for users to follow instructions. Rapid flashes, intense motion and small moving text may exclude some guests or create discomfort.

Consider seated users, mobility aids, varied heights, different skin tones, head coverings, glasses and busy backgrounds during testing. Face or body tracking should not be assumed to behave identically for every person. Where a mechanic depends on speech, facial movement or precise gestures, provide an alternative route where technically and creatively feasible.

6. Plan privacy and content handling

Document what data, if any, the selected implementation is expected to process, retain or expose. Clarify whether recording and sharing happen through the user’s own device and platform controls, and whether the activation includes any separate form, competition or analytics component. Those additions may introduce requirements beyond the filter itself.

Privacy notices, consent language, retention decisions and compliance reviews should be assessed by the appropriate advisers for the actual implementation. The production brief should identify responsible parties and avoid collecting information that is not necessary for the agreed experience.

7. Build a realistic test plan

Testing should cover the filter and the surrounding guest journey. Use representative devices, lighting, crowd density, signage positions and connectivity conditions. A studio test cannot fully represent a dark stage environment, bright outdoor area or congested mobile network.

1. Open the experience from every approved entry point.
2. Test permissions granted, denied and previously disabled.
3. Run each interaction with front and rear cameras where applicable.
4. Check bright, low-light and mixed-light environments.
5. Interrupt the experience with calls, app switching and screen locking.
6. Test slow connections and document the agreed fallback.
7. Verify text, logos, audio, animation order and restart behaviour.
8. Repeat critical tests after platform submission or material revisions.

8. Prepare on-site operations

Define who owns QR placement, guest instructions, staff briefing, issue escalation and asset replacement. Signage should explain the first step quickly and should not block crowd movement. If the filter supports a sponsor activation, coordinate its location with queue planning, lighting, photography and nearby programme activity.

Keep an approved fallback such as a static branded camera moment or alternative content route. The fallback should preserve the campaign idea without pretending to reproduce unavailable AR functionality. Get Out! Events can coordinate the AR workstream with wider festival delivery, guest communications and on-site operations where included in scope.

Festival AR requirements checklist

• One primary audience action and defined festival moment
• Selected platform, publication account and access route
• Approved creative assets and third-party permissions
• Written interactions, triggers and recovery behaviour
• Representative device and environment test matrix
• Accessibility requirements and feasible alternatives
• Privacy, moderation and compliance responsibilities
• Objective acceptance criteria with named approvers
• Platform submission allowance and revision process
• On-site signage, staffing, escalation and fallback plan

A complete requirements brief gives creative and technical teams a stable basis for estimating, prototyping and testing. It also helps festival stakeholders separate essential outcomes from optional effects, reducing ambiguity before production and platform submission begin.