Building a voice and identity

Research question. How can Grounded sound clear and adult when airport information changes, while still feeling welcoming and offering spoken guidance for people who choose it?

This page develops the voice research after the brand synthesis in GDE751: Week 18: Brand research. The audience is autistic adults travelling independently. The Critical Report includes ten self-declared autistic adults; participants described independence and control, late or changing information, sensory environments and fragmented systems. Those findings explain why clarity and choice matter here. They do not show that every autistic adult wants the same tone, pace, voice or amount of help. The words and audio below are therefore design hypotheses, not participant-approved language.

Why voice changes meaning

“Voice” has two connected meanings in this project. Brand voice is the character carried by words and visual expression. Spoken voice is information heard through a system voice, a recorded speaker or a character. The same sentence can feel different when its order, punctuation, pace, pitch and context change. A smiley mascot or a warm voice can soften a message, but it can also make a serious alert seem less reliable. A formal voice can feel authoritative, but may sound distant or leave a person to work out the next step.

The key design question is not “How do I make everything sound friendly?” It is “What does the traveller need to understand at this moment, and what tone helps without adding assumptions?” During an urgent change, the current fact and action should lead. A less time-sensitive preparation screen can offer more explanation. A support prompt can feel warm while leaving the decision with the traveller.

Three voices to compare

Reference voice How it communicates Useful learning What does not transfer
Apple interface writing Apple’s Human Interface Guidelines say to set a consistent voice and vary tone by context. Their examples contrast a direct fall notification with a light, congratulatory activity message. Apple also recommends clear words, important information first and action-led labels. Keep core wording consistent, then let the situation set the tone. A gate change should state the new gate and action. A completed task can be more celebratory. Apple’s examples are not specific to autistic travellers or airport changes. Following a style guide does not prove that the copy is understood.
Therapeutic and wellbeing apps Headspace uses short, named activities and an illustrated, recognisable identity. Finch describes its bird as a gentle, encouraging companion and frames goals as small steps. These brands use reassurance and companionship as part of an ongoing self-care relationship. Offer support in an approachable way; name what the support is for; make the product recognisable across different moments. Airport directions are operational information, not a therapy session. “You’ve got this” or “take a deep breath” could distract from a gate change, presume a feeling or sound childish when repeated.
Public service and accessible information NHS England guidance asks for communication that is personal and direct, understandable when spoken aloud, respectful and empowering. W3C cognitive accessibility guidance recommends familiar, literal wording, concise content and one instruction at a time. Write for a real person, say what is known, and make the next action explicit. Plain language can remain adult and informative. These are broad guidance sources. They do not decide the app’s exact personality or replace testing with the intended audience.

This comparison suggests a direct core voice with optional warmth. It can use the clarity of an operating system or public service for time-sensitive facts, then take the therapeutic-app lesson of approachable support in optional moments. The brand should not imitate a clinician or speak as if it knows the traveller’s emotions. The companion can express the identity; it should not deliver the only version of essential information.

Accessible language without talking down

Plain language is not childish language. It means removing unnecessary work from the sentence: use familiar words where they preserve the meaning, explain unavoidable terms, keep sentence structure straightforward and place one instruction at a time. An adult reader should still receive the full fact and enough context to make a decision. Avoid babyish praise, excessive exclamation marks, diminutives and commands that sound like a teacher addressing a child.

The W3C guide for people with cognitive and learning disabilities is supplemental guidance, not a substitute for WCAG conformance or user research. It recommends including people in design and testing because cognitive accessibility needs vary. Its clear-content guidance includes using literal language, simple sentence structures and separate instructions. NHS tone guidance makes a related point for public communication: write personally and directly, avoid jargon and make complex subjects understandable. Neither source says that all readers need the same amount of detail. The design should give the essential instruction first and let a traveller open more detail if they want it.

For this app, “Your flight has been reassigned to gate A04” is grammatically formal and hides the useful word “changed.” “Gate changed. Go to A04.” is shorter and action-led, but still adult. The message should also identify the former gate if that context matters: “Previous gate: B12.” A traveller should not need a warm introduction before reaching the fact.

Avoid language that labels or diagnoses the user. “You seem stressed,” “we know this is hard,” and “calm down” are not grounded in what the app can know; they may feel intrusive or patronising. Prefer an offer that describes the feature: “Would a step-by-step route help?” with a clear “Not now” option. The wording respects the person’s choice without suggesting that they are unable to manage the journey.

Written and spoken information

The app’s auditory option needs to be considered separately from VoiceOver, Apple’s screen reader. VoiceOver speaks interface labels and content for people who use that assistive technology; it should receive a logical reading order and useful labels. An in-app “listen” control is a separate, optional way to hear the current travel instruction. Decorative mascot content should not be announced as if it were operational information.

The W3C’s 2026 cognitive accessibility research module for voice systems is a draft note, so its recommendations remain under development. It describes how speech interfaces can place demands on memory, processing speed, attention, listening and the ability to answer in real time. It also discusses user control, simpler prompts and fallback paths. This matters even if Grounded does not become a conversational assistant: spoken instructions can disappear as soon as they are heard, and a traveller may be in a loud terminal, using headphones, processing other announcements or unable to listen at that moment.

For a first version, the most grounded exploration is one-way, on-demand spoken guidance, not a voice chatbot. A traveller could tap a clearly labelled speaker button to hear the same current instruction shown on screen. The text remains visible and is not replaced by speech. Audio would not autoplay. The listener could pause or replay it, and the app would respect the device’s speech settings where possible. A short phrase and pause between steps may be easier to follow than a long paragraph. No route should depend on hearing the instruction, and no essential information should exist only in audio.

The distinction between in-app speech and system accessibility also matters technically and ethically. The app could use the device’s built-in text-to-speech voice to read a structured text string; this is consistent with current platform settings and avoids recording a fixed “mascot voice.” A recorded human voice could sound more natural but is harder to localise, update when information changes, and personalise for different listening preferences. These are implementation options to investigate, not a decision that the app already supports them. W3C guidance on audio control recommends giving people control when audio plays; its cognitive-accessibility guidance also stresses that audio can compete with screen-reader speech. A tap-to-play model avoids many interruptions, but still needs testing with VoiceOver and common airport noise.

Same gate change, different meanings