Iterating the user experience of a public kiosk

Kiosks meet people in places where attention is brief, queues move and faults are visible. The process of iterating on a user experience for a kiosk should begin with one observed encounter rather than a feature list. Every revision should address a practical obstacle encountered by a visitor.

A useful kiosk explains its purpose quickly, accepts imperfect input and offers an obvious route through the content. It should support wheelchair access, keyboard operation, captions and assistive speech tools. Accessibility, privacy and maintenance belong in the first brief, not a final compliance pass.

Experimental project archives show that a kiosk can be an instrument, archive or gateway, provided the interface supports the encounter rather than competing with it. Clear project descriptions and credits also document how an idea, its makers and its technical decisions fit together.

Frame the encounter

Begin with the service moment, not the hardware. Is the kiosk giving directions, registering an event, browsing an archive or prompting a creative response? Define one primary job, two secondary needs and a realistic completion time. This prevents every interesting capability from becoming an equal priority.

Translate those goals into observable constraints: traffic, dwell time, ambient light, staffing, connectivity and cleaning. A council venue may prioritise durability, spare parts and accessible servicing, while a festival prototype may value quick assembly and weather resistance. These constraints keep critique tied to deployment.

Watch how visitors approach

Watch how visitors approach before changing the screen. At a Melbourne gallery or Sydney transport precinct, some stop because the display is visible; others read from a distance and keep walking. Note hesitation, body position, the words used, and whether they wait for a prompt. These clues locate the first uncertainty.

Other people shape the interaction. A visitor may step aside rather than interrupt someone already using the kiosk, turning the queue into part of the experience. Test an unobtrusive “please wait” marker and a single-user flow. Observe respectfully, seek consent before recording identifiable images, and avoid collecting faces or audio unnecessarily.

Local conditions matter too. Strong sun can reduce screen contrast around Sydney or Brisbane, while reflections vary under Melbourne’s changeable sky. Heat, humidity, dust and rain can affect sensors and screen life. Location and weather should shape the brief.

Prototype the risky moments

Prototype the moments most likely to fail: recognition, orientation, input, error recovery and completion. Paper cards, printed mock-ups and cardboard enclosures can test language and sequence before software is built, making a confusing task visible without the cost of a finished installation.

Use materials and behaviour to test the idea, not merely its appearance. The ITP 30 Show account of a recycled musical instrument shows how sound, touch and construction can become inseparable in interactive work. A kiosk mock-up should reveal whether its controls invite curiosity and whether its feedback matches the promise made by its housing.

Raise fidelity only after the structure survives contact with users. A coded prototype can test a branching flow; a physical one can expose reach, glare, vibration and sound leakage. Record what each version changes and why, so development remains evidence-led.

Test with local participants

Recruit a mix of likely users through the venue rather than relying only on colleagues. Include people who use the kiosk differently, first-time visitors and regular patrons. Short sessions at different hours can reveal how time pressure, crowding and unfamiliarity affect completion.

Reflect Australia’s linguistic diversity without assuming one “correct” accent or vocabulary. Offer clear plain English and test translated content with speakers. Where an experience touches culture, language or Country, involve relevant Aboriginal and Torres Strait Islander communities early, with appropriate protocols and payment. WCAG 2.2 AA is a practical baseline, not a substitute for human testing.

Give participants realistic tasks but avoid leading them through every step. Watch where they pause, what they reread and how they recover from an error. Ask about confidence and comfort after the session, then compare those answers with observed success. Document consent and store only the data needed to improve the experience.

Simplify the interface and content

Simplify the interface around the primary job. Reduce choices, enlarge meaningful targets and make the current state visible. Give immediate, forgiving feedback after every input, with a straightforward way back. Audio, vibration or animation can reinforce actions, but each should carry meaning rather than decorate the screen.

Write interface copy with a public-service mindset: short sentences, concrete verbs and no unexplained technical terms. Provide captions and transcripts for sound, ensure focus order works with keyboards, and maintain strong contrast. If several languages are needed, avoid cramming them into one screen; use a deliberate path that preserves the task.

Pilot, measure and maintain

Pilot in the real venue before a full launch. A small run in a council library, independent gallery, museum foyer or Melbourne laneway pop-up can expose operational gaps. Observe queue spillover, staff interventions, network dropouts and cleaning access. For temporary work, assign owners for setup, shutdown, packing and storage.

Measure a small set of useful signals: successful completion, time on task, abandonment points, recovery rate and requests for help. Review them with venue staff and participants, not just analytics dashboards. Protect privacy under the Australian Privacy Principles, apply short retention periods, and publish a plain explanation of what is logged.

A practical iteration checklist

Use this sequence to keep each cycle focused and comparable:

• Start with one measurable public task and a fixed iteration goal.
• Test paper, physical and coded prototypes in that order.
• Recruit varied users through the Australian venue or community.
• Log usability evidence, operating costs, privacy impacts and failures.

Revisit the plan after every pilot, but archive rejected ideas and the reasons for rejection. Those decisions prevent the team from repeating work or losing the rationale behind a choice.

Explore the ITP 30 Show, select a project that reframes how people interact with technology, and carry its experimental curiosity into your next kiosk test. Share the prototype with a local venue and invite one real visitor to reveal what the screen cannot show.