语音提示是以人声播报的信息。大多数语音提示应先播放一个提示音，让用户知道系统即将说话。由于两者通常配合使用，语音提示也应遵循音频焦点规则。
对于特殊交互或状态变化，例如连接丢失、结束翻译，语音提示能提供单靠提示音无法传达的明确说明。
如果用户在手机上进行的操作会影响眼镜体验，例如静音，就播放提示音，但省去语音提示。例如，用户在手机上将 Meet 通话静音。
避免：用语音打断体验
“通话已静音”这类可能打断当前体验的语音提示应少用，并尽量简短。
按需播报当前状态
如果应用已暂停，或者声音输出并不频繁，信息播报会在用户轻点眼镜时告知最新状态。这样用户不必回想应用刚才做了什么，也不会误以为应用已经停止。在无屏眼镜上，轻点触控板会触发状态播报，或控制播放与暂停。
通用语音提示
使用独特的声音并不会让通用语音提示获得额外益处；它们只为帮助用户理解音频应用的当前状态。它们使用默认的文字转语音方案。
在条件允许时，使用标准系统语音，保持一致，降低认知负担，也让体验更精致、周到。
以下是通用语音提示的几个例子：
自定义语音提示
这类声音具有独特性，也是音频体验的核心。允许对它们进行定制并融入品牌特征，对提升音频体验很重要。这类语音提示采用自定义文字转语音方案。
只在确有价值时使用品牌声音，例如体验中重要且明显的转折时刻。
怎样写好语音提示
设计和撰写应用的语音提示时，应考虑以下几点。
用日常语言，直接与用户交流
让应用的表达风格保持一致、简洁、口语化，并且真正有帮助。说明操作时，可以考虑用主动动词开头，清楚地引导用户。
例如，以“正在开始……”“正在关闭……”这样的主动表达说明动作。
建议：使用日常语言
使用用户熟悉、没有技术门槛的表达。
避免：为了简短而使用技术术语
即使为了缩短提示，也不要使用技术术语。
建议：直接对用户说话
用“你”这样的称呼，直接与用户交流。
避免：让系统成为叙述中心
不要让语音提示围绕系统自身展开，也不要用“我”或“我们”来表述。
兼顾简短与清楚
常见语音提示不应打断用户体验，因此，一条简短而有效的信息，优于准确到面面俱到却很冗长的说明。对于不常见的情况，多一点解释有助于避免认知过载，避免让用户自己猜解决办法。应考虑用户需要哪些信息，才能继续下一步。
建议：只说下一步所需的信息
只传达用户继续操作所必需的信息。
避免：让解释妨碍操作
不要用过多说明妨碍用户，也不要试图通过语音提示完成冗长的故障排查。
考虑用户当时的环境
无屏眼镜与带屏眼镜的语音提示，都需要适应用户所处的环境以及多设备使用场景。例如，某项流程可能需要在手机上开始或结束。
建议：说清操作发生在哪台设备上
考虑多设备体验，明确说明操作发生在手机上还是可穿戴设备上。
避免：默认用户只在使用眼镜
撰写语音提示时，不要假设用户只会操作眼镜这一台设备。
遵循错误提示的写作原则
语音提示应遵循通用的体验文案写作原则，尤其是错误提示。解释问题的原因，并给出可能的解决方法。如果重试有望解决问题，就引导用户再试一次。发生错误时，不要使用玩笑或嘲讽的语气。
