What you will learn
- How audio guides differ from tours and wall texts
- Script writing: length, tone, and stop structure
- Languages, voices, and accessibility options
- Offline playback, triggering, and battery use
- Routes for adults, families, and school groups
- Updating scripts when exhibitions change
What an audio guide actually does
An audio guide answers the question a visitor asks in front of an object: what am I looking at, and why does it matter. The best stops run short — a minute or two of plain, vivid commentary — and then stop, leaving the visitor to look rather than listen. Wall text serves readers; audio serves visitors whose eyes are on the object, whose hands are full, or who prefer listening. A guide that reads wall text aloud adds little; a guide written for listening adds a voice, a story, and a reason to pause.
Delivery on visitors' own phones has largely replaced hired handsets, but it brings its own demands. Playback must work in galleries with patchy signal, so content should download before the visit or at the entrance. Triggering should be simple: a numbered stop, a QR code, or a list, rather than indoor positioning that fails in thick-walled galleries. A guide that needs constant signal or precise location will frustrate visitors at the exact moment they want it.
- Short stops written for listening, not wall text read aloud
- Playback on visitors' own phones, no hired handset required
- Download-before-visit or entrance download for patchy gallery signal
- Simple triggering: numbers, codes, or a plain stop list
Core features visitors actually use
The stop list is the product. Visitors browse stops by number, gallery, or route, and each stop shows its length before playing, so a visitor can choose a two-minute story over a six-minute one. Language selection must be obvious at the start, not buried in settings, and switching languages mid-visit should keep the visitor's place. Transcripts help visitors who are deaf or hard of hearing, visitors in quiet galleries, and anyone whose connection drops mid-stop.
Routes turn a pile of stops into a visit. A highlights route for first-timers, a family route with questions for children, and a deep route for enthusiasts serve different visitors without tripling the content. Progress tracking — which stops have played — helps visitors pick up after a break. A simple feedback prompt at the end of a route tells the museum which stops visitors skip, which is the most useful editing signal available.
- Stop list by number, gallery, or route, with lengths shown before play
- Language selection up front, with place kept when switching
- Transcripts for every stop, for access and for quiet galleries
- Routes for highlights, families, and enthusiasts, with progress tracking
How the build runs, phase by phase
Script writing starts the project, not the app. Curators and writers agree the stops, the route structure, and the length limits, then write and edit scripts before any recording. Recording follows, with consistent voices per language and a quiet recording environment; re-recording a single stop later is cheaper than re-recording a whole route because one voice changed. Testing then happens in the galleries, with real visitors, background noise, and phones of different ages.
Development runs beside content production: the app shell, the stop player, downloads, and language handling. Content should be managed through an editor, not baked into the app, so a corrected script or a new stop can ship without an app update. Launch includes entrance signage and staff briefing, because visitors adopt a guide they are told about at the door far more than one they must discover alone.
- Agree stops, routes, and length limits, then write scripts first
- Record with consistent voices per language in a quiet setting
- Test in real galleries with noise, old phones, and weak signal
- Manage content through an editor so corrections ship without app updates
Tech considerations that shape the result
Offline playback is the key technical decision. Audio files should download as a pack per language or per route, with clear progress and storage size shown before download. Streaming-only guides fail in basement galleries and thick-walled buildings, and visitors blame the museum, not the network. Battery use matters too: continuous playback, screen-off support, and modest file sizes keep a guide running for a full visit.
Content structure should separate scripts, audio files, translations, and routes, so a corrected translation does not require touching the rest. Analytics should track stop starts, completions, and skips per route, which tells editors where scripts lose listeners. Accessibility covers transcripts, adjustable playback speed, and controls usable without looking at the screen.
- Downloadable audio packs per language or route, with size shown
- Screen-off playback and modest files for a full-visit battery life
- Scripts, audio, translations, and routes managed as separate pieces
- Stop completion and skip data to guide script editing
Challenges that slow audio guide projects down
Script volume surprises teams. A guide with sixty stops in four languages is two hundred and forty recordings, each needing writing, checking, recording, and quality review. Translation and voice consistency multiply the work, and a language added late can delay the whole launch. The workable approach is to launch with fewer stops in the languages visitors actually use, then add languages from visitor data rather than from ambition.
Exhibition changeover is the second challenge. Stops tied to a temporary exhibition expire when it closes, while stops tied to permanent galleries last for years. Planning which stops are permanent and which are temporary — and budgeting re-recording for the temporary ones — prevents a guide full of dead stops six months after launch.
- Stop and language counts matched to writing and recording capacity
- Permanent-gallery stops separated from temporary-exhibition stops
- Re-recording budgeted for exhibition changeover
- Visitor language data used to prioritise the next language added
Who it is for, and where it stops
This project fits museums where visitors spend time looking at objects and where language diversity or accessibility needs are real. It fits less well for museums whose visit is mostly interactive or outdoor, where audio competes with the experience rather than supporting it. Daily users are visitors on their own phones, plus the content team that maintains scripts and recordings.
It does not replace wall text, a virtual tour, or a printed guide. Audio serves looking and listening; it does not carry images, maps, or long reference text well. Budget and schedule depend on stop count, language count, and recording quality — confirm both with a quote before committing.
- Fits object-focused museums with language or accessibility needs
- Daily users: visitors listening, content team maintaining scripts
- Does not replace wall text, virtual tours, or printed guides
- Interactive or outdoor-heavy visits may suit audio less well
Frequently asked questions
How long should each audio stop be?
Most stops work best at one to three minutes. Longer stops lose listeners, especially in busy galleries. A deep-dive option can sit beside a short stop for visitors who want more.
Do visitors need to download an app?
Not necessarily. A web-based guide avoids an install step and works on more phones, while a native app suits museums that need robust offline packs. The choice depends on gallery connectivity and visitor habits.
How does the guide work without signal in galleries?
Visitors download the audio pack before entering the galleries, or at the entrance over wifi. Playback then runs from the device, so patchy gallery signal does not interrupt a stop.
Can the guide include sign language or audio description?
Yes. Signed video stops and audio-described stops are separate content types with their own production needs, and they should be planned from the start rather than added as an afterthought.
Who writes and updates the scripts?
Curatorial and education staff write and check scripts, usually with a writer or editor for listening tone. The content editor should let them update a script or stop without developer help.