合作咨询
我们的专家服务团队将竭诚为您提供专业的合作咨询服务
华为 EMUI AI 泛终端设计体验
欢迎
随着智能手机日益强大和智能,语音正在快速地成为一种普遍的人机交互方式。各年龄段的人们用语音玩游戏、及时获取新闻、控制智能家居设备。语音优先的交互方式之所以能被大众所接受,是因为它是自然的、对话式的并且以用户为中心的。优秀的语音交互体验可以理解用户表达含义和意图的各种方式。人类的语言是丰富复杂并且灵活多变的,所以语音用户界面的设计与图形交互界面的体验设计大大不同。
当面临人机交互方式重大转变的节点时,我们往往首先会从上一代的设计概念出发来审视新技术,但最终我们还是需要创造出新的设计模式,以更大限度地体现新技术的优势。当鼠标出现时,它最初的目的是为了替代繁琐的键盘指令输入;当触摸交互出现时,点按被当作与鼠标点击类似的行为,而不是直接发展出多种手势操作交互; 当更新的语音交互出现时,它又被视作键盘和点按控制的替代品,而忽略了对话式交互的潜力。
想要从简单地设计“语音键盘”转变为创造真正语音优先的对话式体验,首先你需要了解语音设计的交互原则以及各种设计开发的方法。简单地将语音交互添加到应用中并不能被称为“语音交互体验”,你需要从语音优先的角度重新构思整个体验。语音界面设计和图形界面设计不同,两者之间有着许多微妙但相距甚远的差异点。
这套AI设计规范可以帮助你理解语音优先的交互体验应该如何设计,学习基础又关键的用户体验原则,如何使用华为提供的指南和说明创造出令用户满意的语音交互体验。
当前V1.0版本主要包含以手机为主的智慧语音对话和视觉的规范,已落地于手机、电视、触屏音箱和音箱设备。
核心价值
一个小艺,一个生态系统
小艺既不只是存在于用户手机中的语音助手,也不只是单纯回复语音指令的机器人,它更像个拥有着一整套连贯技能的有机体,可以在用户使用不同设备时被调用。小艺可以预测和感知不同的使用场景,并基于场景平顺地调整以适配各种设备,同时让用户感到亲密、舒适和信任。
网站地图
网站分为四个模块,如果你刚开始接触对话式设计,建议你从头开始阅读,然后逐步完成所有的设计要求和步奏。
浏览以下模块,找到你需要的部分。你也可以网站地图的归类主题中,根据自己的需求选择并学习相应类别的知识。

一、概要简介
了解如何使用本站,以及对话式体验的关键概念。
二、基础与原则
如何架构、撰写以及设计多模态对话式体验,包含设计原则、角色设计、交互设计、视觉设计和对话设计。
三、设计指导
为设计师提供对话和视觉卡片设计的详细步骤与示例。
四、组件库
可以快速应用的对话及视觉卡片组件。
五、设计资源
走查表、视觉组件设计资源
其他资源
了解其他华为设计和开发的相关资源,更全面的理解设计规范。
(1)华为开发者联盟 :华为终端官方合作伙伴开放平台,依托终端渠道优势、全球化平台服务及产业链资源,从开发、测试、推广、变现等环节,多维度助力开发者,共建开放共赢的创新生态。
(2)华为快服务智慧平台 :华为统一的原子化服务接入和分发平台,聚合泛终端多场景的流量入口,服务一次接入多媒体分发,获取高流量。(当前仅针对企业开发者开放)。
(3)华为小艺对话开发平台 :为开发者提供创建语音技能多链路的平台支持,包含开发、测试、部署工具的提供以及多场景覆盖的对话技能发布渠道。
对话式界面设计是一种模仿人类对话的用户界面,以更自然的形式与机器达成更好的交流。在对话式界面设计里,设计师们需要确定在任务场景里,用户和小艺可能会说些什么、是否需要视觉信息等辅助交流。因此,对话式界面设计将综合了交互设计、语音设计、视觉设计等多门设计学科知识。
在这场人机对话新浪潮中,设计师的工作将面临更多机遇与挑战。离开传统界面设计,设计师需要了解人与人之间语言互动的行为模式,并结合对话设计工作原理和优劣势将自己的观察和思考融入到以下工作中:
(1)对话请求:小艺是否能在合适的时机发起对话,不断推进?
(2)建立语境:小艺是否能够记住过往的用户相关的信息作为交互的基础?
(3)构建意图:用户是否能够理解对话?
(4)对话成本:对话是否避免重复性的发问/确认?是否允许用户提供更多相关信息?
(5)对话价值:对话是否带来新知识、解决问题、带来喜悦或引起兴趣?
(6)持续互动:用户和小艺之间是否能够自然轮换对话?
语音优先
设备友好
状态清晰
在对话设计体系中,语音作为主要交互方式之一,降低了用户与设备互动的成本。对话体验的根本目标是让用户选择用更自然、高效的方式完成任务。
一致的信息体现在对话任务中,视觉界面上应该呈现与语音流程匹配的信息,同时需使用户可以通过语音完成整个流程。
多模态的互补体现在视觉界面上的操作需要支持对应的语音指令,使用不同交互组件, 给出“支持语音交互”的提示,引导用户用语音与设备进行互动。
在以下示例中, “你想打给第几个?”的询问方式引导用户回复语音指令 “第二个”。同时展示列表卡片, 通过视觉上的反馈帮助用户进行交互。

为技能匹配合适的设备,是因为不同设备有不同的能力,对应用户使用设备的不同模态以及场景, 如音箱没有屏幕,重视听觉模态,所以更适合详细的播报或音乐播报类技能; 而车机有屏幕,兼顾视觉和听觉两种模态,但因为驾驶重视安全, 所以游戏类多互动的技能就不适合在车机上。
设计符合设备的体验体现在设备是否包含屏幕将直接影响播报的详细程度。在设计过程中,需要提供考虑详细和简单两种播报方式,以适应不同的设备。(详见 “对话设计-泛终端下的对话交互设计 ”)同时提炼对话元素成组件,根据设备和意图选择组件及布局。(详见“对话组件”、“视觉组件 ”)
在以下天气的技能示例中, 音箱匹配详细播报, 电视和手机匹配简单播报和屏幕上显示的屏幕对话以及视觉组件。

以语音为主要媒介,与用户日常使用的图形交互界面存在较大差异。
因此,对话体验简洁清晰体现在对话过程中,需要借助对话组件、视觉和听觉提示帮助用户了解目前所处的状态,以及目前应该做什么。
如下示例中, 在询问用户时,小艺展示波纹形动效, 清晰地告诉用户目前对话正在收音的状态。同时匹配卡片和推荐指令,帮助用户在进行选择。

为错误异常进行设计是因为以语音为主的对话体验中,用户会不受限制随意说出指令。此时,系统有可能无法正确理解真实的意图而导致出错。在这类情况下,不应该直接终止对话,而是需要通过引导和视觉元素,让对话从异常中恢复。(详见“对话组件-错误 ”)
为什么AI“小艺”要做角色设计?
人物角色是对话的自带属性
无论设计者是否考虑智慧语音的角色, 每一次对话都是用户重塑智慧语音形象的过程。或可爱或高冷,用户在进行对话时,或多或少都能感知到智慧语音的角色设定。
统一角色是体验一致的保证
角色设定决定对话风格,相互冲突的对话风格对于用户就像是与多个“相互冲突”的角色在对谈,降低用户对系统的信任感。因此,技能设计中也要保证回复应答与小艺角色设定一致。
(1)视觉形象: 生动直观,用于品牌传播 。
(2)声音特质:依赖听觉传递的人物画像,音色、语速、音调都会影响用户对角色的感受。
温暖、轻快、年轻的女声。
(3)性格特点:角色设计的内核,角色详细设定的基础,可以显示角色的独特性。
聪慧博闻,有亲和力,温暖体贴,有恰到好处的小幽默。
(4)互动关系: 不同的互动关系决定了人际交往中的亲密感和地位,影响对话风格和角色定位。
一个独立、亲切的智能管家,准确、高效,帮助用户达成期望 。
(5)知识技能:能够做到的事, 代表角色的智力水平和能力范围。
解放双手高效操作,百科知识一句查询, 陪你解闷讲笑话。
| 常用话术 | 小艺 |
| 应答语 | 我在、嗯、在的 |
| 口头禅(常用语、确认词) | 好的、没问题 |
| 称谓 | 你 |
| TTS音色 | 温柔,婉转 |
| 用词表达 | 更简练,更礼貌 |
| 语气词频率 | 适当使用,增加对话自然性 |
| 建议语气词 | 嗯、吧、了、的、啦 |

对话体验发生在不同设备上,每个设备都有不同的能力、使用场景和用户期望,因此,通过组件来统一各设备上的对话体验。
(1)语音播报
(2)文字气泡
(3)视觉组件
(4)推荐指令
(5)视觉形象


推荐指令通过给用户提供与当前对话或场景(如时间、地点、日程)相关的话题或问题,帮助用户更轻松地继续与小艺对话。
(1)推荐指令分为对话指令 和 技能指令。
(2)推荐指令在两种模式下展示的样式相同。
(3)推荐指令可以不依附于卡片直接展示。

对话指令是用户可以用来回答小艺问题的相关“答案”,而技能指令是结束当前对话并且开始新对话或应用的相关“任务”。
并不是每段对话都需要添加回答指令和技能指令,但是它们对于完善主题、发现相关主题、后续步骤和支撑语轮转换很有帮助。当用户点击对话指令或技能指令,所点击的文字就会变成用户对小艺的回复。

手机上的小艺在10.0有唤醒悬浮态、对话全屏形态以及服务全屏形态三种形态。
全屏态可以提供更沉浸的对话体验,以及键盘输入、视觉输入的多模态交互入口。
用户唤醒小艺时为悬浮态,表现为全屏遮罩,背景半透明。
小艺完成收音/识别后,进入全屏,背景不透明。


小艺在泛终端下以符合设备使用场景的形态出现,设计师在设计时要考虑该体验是否符合该设备下的交互方式,同时兼顾视觉组件在其中的合理应用。
如下图,不同设备的使用场景对应用户使用时的专注程度,以此搭配相应的播报原则和显示策略。




将一个终端上的体验向其他终端扩展时,考虑以下问题:
(1)设备能力如何?
(2)主要的输入和输出模态是什么?
(3)包含哪些对话组件?
(4)每个组件在终端设备上以什么形式与用户交互?
| 设备 | 手表 | 手机 | 电脑 | 智慧屏幕 | 车载屏幕 | 电视 | 音箱 | |
| 播报对话 | 详细播报 | ✓ | ✓ | |||||
| 简单播报 | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| 屏幕对话 | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| 视觉组件 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
| 推荐胶囊 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
| 助手形象 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
每种设备根据自身的硬件形态和能力,为对话体验提供触点。以下为各个设备上用户可以唤醒小艺的方式:
(1)在手表上:①说出唤醒词;②按压侧面的语音键
(2)在手机上:①说出唤醒词;②按压侧边物理键;③点击桌面上的应用图标
(3)在智慧屏幕上:①说出唤醒词
(4)在电视上:①说出唤醒词;②按压遥控器上的语音键
(5)在音箱上:①说出唤醒词
(6)在车载屏幕上:①说出唤醒词;②按压方向盘上的语音键;③点击桌面上的小艺图标
为了更好的遵守和执行交互设计原则,在创造交互设计的时候,你的设计方案必须要符合设计走查表中的所有走查点。
语音优先、设备友好、状态清晰的总原则,在视觉设计上的体现为:
(1)在带屏设备上展示一致的关键元素和信息
(2)为不同设备媒体的更优体验呈现不同的视觉样式
(3)有明确的视觉状态和主次分明的界面布局

有温度,够智能
理想情况下对话式交互体验能够让用户感觉到系统拥有“智能”,可以理解用户并使用同样的对话方式与用户进行交谈。但现实存在困难。
设计团队进行了大体量的用户问卷以及用户倾向性调研。我们发现活泼、有趣、又可靠的性格形象是大多数用户所希望的。传统冷静、严肃的机械化形象并不受欢迎。
同时,用户在不同的设备上唤醒小艺,静默、聆听、思考的状态是清晰、一致的,以帮助用户建立小艺的形象并形成整体统一的体验。




为了更好的遵守和执行视觉设计原则,在创造视觉设计的时候,你的设计方案必须要符合设计走查表中的所有走查点。
对话交互虽然有高效、自然、免手免眼的优势,但由于技术限制,不是所有场景都适合使用对话交互,因此不是最佳交互方式。
对话交互的最终目的是为用户解决问题,提高效率,任何对话交互设计不能违背这一目的,这样才是合格的设计。因此设计师应该根据对话交互的优势,选择可以解决用户痛点的场景。

当用户对小艺发出语音指令时(典型说话),小艺会判断用户想干什么(意图),并获取达成这个目标的一些关键信息(槽位)。

| 名称 | 概念说明 |
| 技能请求词 | 帮助小艺找到特定语音技能的请求词。 |
| 欢迎语 | 用户仅选择技能,没有表达意图,小艺通过欢迎语快速引出用户意图。详见对话组件-欢迎语。 |
| 典型说法 | 用户说出来的结构化句式,用来帮助小艺理解用户意图。 |
| 意图&槽位 | 意图:小艺从典型说法解析 用户“要干什么”,是说法的分类“标准”。 槽位:小艺获取的一种跟完成任务相关的信息。 |
| 对话状态 | 小艺根据典型说法的槽位进行分析,决定下一步的对话设计。 |
| 对话生成 | 小艺选择预先设计好的文字对话设计。 |
| 语音播报 | 小艺把文字对话合成语音,与用户进行对话交互。 |
对话设计主要分为任务导向型对话、查询导向型对话和开放式闲聊对话。
(1)任务导向型对话有明确的目标和需要参数化的关键信息。
(2)查询导向型对话一部分跟任务导向型相似,根据不同的关键信息给予不同的回答;另一部分则不需要把用户问话中的信息参数化,由小艺回答给定答案。
(3)开放式闲聊对话没有任何任务目标,可用于维护小艺已有的角色设定。

“合作原则”是由美国著名语言哲学家Herbert Paul Grice于1967年在哈佛大学的演讲中提出的。 Grice认为,在人们交际过程中,对话双方似乎在有意无意地遵循着某一原则,以求有效地配合从而完成交际任务。 Grice 把这些原则总结成“合作原则”(Cooperative Principle) ,用于指导双方如何能够顺利进行对话。
但由于Grice的合作原则是从人与人交互出发解释对话合作性的通用的指导方针,没有考虑由于对话设计技术带来的局限性,无法指导对话的设计。因此在这里结合Grice的合作原则,考虑对话设计的实际情况,提出了对话设计原则。
| 合作原则 | 设计原则 | 描述 | 维度 | 检查点 |
质的标准 (1)不要说自知是虚假的话 (2)不要说缺乏足够证据的话 | 建立信任 | 对话能够提供给用户帮助决策的真实信息,建立用户和小艺之间的信任 | 提供真实的信息 | 信息真实,不夸张表达 |
| 告知能力界限 | (1)小艺类人但非真实的人 (2)在能力范围内提供足够的知识和推理能力 (3)告知用户小艺的能力范围 | |||
量的标准 (1)所说的话应该满足交际所需的信息量 (2)所说的话不应该超过交际所需的信息量 | 信息足够 | 小艺根据用户需求提供贡献足够的信息帮户用户决策 | 话术简洁 | (1)有视觉组件时配合语音播报内容不应超过20秒,无视觉组件则10秒 (2)闲聊型对话可适当延长用以表达情感 (3)列表播报详见对话组件-列表 (4)确认播报详见对话组件-确认 (5)泛终端的播报详见泛终端下的对话交互设计 |
| 关系准则 (1)说话要相关 | 清晰易懂 | 使用的语言用户容易记忆,容易理解,表意清楚 | 表达内容 | (1)与任务相关 (2)统一业务下用词一致 (3)避免使用缩略词、领域内专业词汇和操作用语等 |
方式准则 (1)避免晦涩或歧义 (2)简炼并井井有条 | 表达方式 | (1)避免使用复杂句式 (2)表述清晰,避免歧意 | ||
| 表达结构 | (1)重要、常用、新增或与需要用户操作的信息放在句首或句末 (2)信息优先级详见对话组件-列表 | |||
友好准则 (1)不强迫 (2)提供建议 (3)体验友好 | 对话自然 | 小艺与用户自然交换话语 | 使用口语体 | (1)体现口语体特点 (2)避免戏剧化的表达方式 |
| 句式多样 | (1)高频场景应该设计多种播报句式 (2)不同句式对话风格要保持一致 | |||
| 对话友好 | 小艺尊重用户,认可用户的感受 | 不贬损用户 | (1)不发表有损于用户的观点,不调侃和贬损 (2)要避免粗鲁、冲突性的用词 | |
| 避免敏感话题 | (1)尊重用户所属的文化及传统 (2)可选择礼貌地回避或使用中性词汇回答敏感话题 | |||
| 谨慎处理未经用户请求的内容 | 用户尚未完成目标时不执行与任务无关的播报/其他任务 | |||
| 处理好不能完成的任务 | 详见对话组件-错误 |
1. 提供真实的信息
提供真实有效的信息,不过分夸大或欺骗用户。

2. 告知能力界限
(1)不要误导用户将小艺理解为真实的人类,过高的用户预期更容易导致对话的失败。
(2)在能力范围内提供足够的知识和推理能力。
(3)在合适的时机使用适当组件告知用户小艺的能力范围(详见对话组件-欢迎语,对话组件-错误,对话组件-提示,交互设计-推荐指令 )。

1. 传递必要信息前提下,播报时长合理
(1)播报时长感知与任务类型有关,闲聊型的播报可适当延长用以表达情感。
(2)有视觉组件反馈播报时长不应超过10秒,即保证正常人一口气可以说完。
(3)无视觉组件反馈播报时长不应超过20秒。
2. 话术简洁,避免不必要的冗长
在一些场合,如确认、列表,应该选择合适的表达方式进行播报,避免小艺说太多(详见对话组件-确认和对话组件-列表 )

1. 播报信息与任务相关

2. 使用常用词汇,不创造新概念。
(1)避免使用缩略词、领域内专业词汇和操作用语等。
(2)使用高频词汇,不要使用小众、专有概念,减少抽象概念。

3. 用词一致
标记某个物体或动作且具有文化共享含义的词汇,包括:名词、动词,和大多数的修饰语,在技能内要保持一致。

4. 避免使用复杂句式
避免使用如:被动句、双重否定(不得不…)、否定条件句(如果我不…,我就不会…)等复杂句式增加理解难度。

5. 考虑信息位置
(1)重要、新增的信息放在句首
(2)涉及用户操作的信息放在句末

6. 表述清晰,避免歧义。

1. 使用口语
(1)使用口语词汇
(2)适当省略句子的成分(主语、宾语)
(3)适当省略句子连接词
(4)适当地使用语气词
(5)避免过于戏剧化的表达方式
(6)谨慎使用成语

2. 句式多样
(1)应该设计两种以上的播报句式
(2)不同播报句式语义要保持一致

| 垂类 | 订票 |
| 意图 | 订票(获取目的地信息) |
| 模版 | 请告诉我你要买去哪里的车票? |
| 你还没告诉我你想去什么地方? | |
| 你想要买这个时间去哪里的车票? | |
| 你可以说出目的地的名字。 |
1. 不贬损用户
(1)不发表有损于用户的观点
(2)避免粗鲁、冲突性的用词
(3)闲聊中谨慎使用反问句,容易产生不礼貌的感觉

2. 避免敏感话题
(1)针对社会/文化/个体选择的话题,应该尊重用户所属的文化及传统。
(2)针对有争议的/冒犯性的敏感话题,小艺可选择礼貌地回避(“对不起,我不能回答这个问题”)或陈述客观事实,不表达个人立场。

3. 谨慎处理用户未经请求的内容
用户尚未完成目标时:
(1)不提供与任务无关的功能/技能
(2)不询问是否完成无关的功能/技能
(3)不询问与任务无关的用户个人信息
(4)不提供与意图无关的功能/技能推荐
4. 处理好不能完成的任务
需要设计策略应对因为技术限制、小艺出错导致没有完成的任务(详见“对话组件-错误 ”)。
根据设备区分播报策略

一个技能在涉及多个设备、涵盖有屏或无屏设备、需要语音播报、涉及详略播报场景时,需要配置详细和简单两种播报方式。设计师和开发者需要根据用户的模态和设备的使用场景区分并使用详细和简单播报。
详细播报的适用场景为技能是纯对话式交互(如音箱),或场景对免手、免眼操作有强烈的需求。
简单播报的适用场景为技能在有屏设备上,或场景无太强烈的免手、免眼操作的需求。
在设计播报方式时,需要注意以下3个设计关键点:
(1)简单播报时,必须播报核心信息
(2)详细播报时,建议允许用户听“更多”
(3)带屏设备上进行详细和简单播报时,通过视觉形式引导用户
简单播报只播报屏幕中的核心信息,其他信息通过视觉展示。
以下例子中,在带屏设备上小艺在展示多目的地列表卡片供用户选择,此时语音播报“找到5个目的地,导航去第几个?”即可,不必将每个列表项都播报出来。

(1)优先使用 “推荐指令”(详见视觉组件-推荐指令)告知用户与小艺下一轮交互的其他可能选项。
(2)用“选择”替代“点击”、“滚动”、“滑动”或“拖动”界面操作用语 。
(3)在带屏设备上显示视觉组件时,避免使用“显示”、“屏幕”。

详细播报时,即使技能运行在有屏设备上,用户也不一定关注屏幕的内容。技能应该提示或支持用户说“更多”转换播报方式。
在播报列表项技能场景下,小艺在播报完列表后,可以通过询问“如果你想听到更多内容,请告诉我。”允许用户听到更多内容。
为了更好的遵守和执行对话设计原则,在创造对话设计的时候,你的设计方案必须要符合设计走查表中的所有走查点。
关于本章
为了更好的设计并使用视觉卡片,本章将提供详细实用的设计指导与示例,用于三方开发者调用卡片模板或者自定义卡片。
首先,你需要了解卡片的总体构成、通用模板和槽位组件等基本组件信息。
其次,根据业务诉求你要选择是使用通用的卡片模板还是自定义卡片。
最后,在自定义卡片时,必须遵循卡片的自适应原则和泛终端卡片的适配原则。
卡片作为小艺用户体验的重要组成部分,能在带屏设备上高效完成任务并可能给用户带来惊喜。但它不是在所有任务、或某任务的执行全程都要出现。 需要在业务诉求充分后明确设备、媒体、意图三项内容,后续步骤均基于此步结果执行设计。
用户会用哪个设备交互。小艺生态下的带屏设备有手机、平板、电视、触屏音箱、手表。如果业务能在一个或多个带屏设备上进行,则可能需要卡片设计,如只在音箱上进行,则不需卡片设计。
如果业务需要在负一屏、全局搜索等非智慧语音的媒体上进行,则必然需要卡片设计;如业务需要在智慧语音中呈现信息且信息涉及的槽位不止一个,则鼓励卡片设计。
卡片需要在业务进行中的哪个或哪些环节出现,如果多次出现,则需要根据出现的场景和用户意图呈现不同的槽位内容或不同数量的槽位。为卡片出现的意图起一个简洁易懂的名字。
示例:
假设有一家提供影视名人百科信息的业务方——大艺百科,希望在手机和电视上的智慧语音展示用户查询型任务的结果,每次查询只展示一个结果。 那么需要设计一张卡片,并且主要用于展示结果的多个相关信息。

确定业务诉求后,需要定义卡片的内容。
(1)卡片内容要符合意图,把业务需要展示的内容定义完整。
(2)内容要关键,遵循语音优先的原则,不展示过多的视觉信息导致效率降低。
(3)如果内容受时间地域等有效范围限制,需要明确指出避免用户混淆。
(4)始终注意不要展示敏感信息,泄露用户隐私。
与对话设计一致,视觉卡片上每一项内容都以槽位承载,把内容量化为槽位类型,以便更好地管理和设计卡片。确定要展示的内容是文字、图片、星标、标签、交互控件中的哪类。详细槽位类型说明,请参阅视觉组件-卡片组件-槽位组件。
遵循状态清晰的原则,需要划分信息的重要等级,以指导卡片视觉设计上的主次关系。等级主要有核心信息、次要信息、辅助信息。核心信息为业务进行必不可少的部分,次要信息为核心信息的状态、描述或信息范围,辅助信息为与核心信息围绕同一事物但是不同领域的内容。一项核心信息、次要信息、辅助信息均可由单一槽位承担,也可由若干个不同的槽位成组承担。
示例:
大艺影人百科的核心信息是影人名和照片,次要信息是影人的具体职业、生日和简介,影人作品因为是百科的主打,所以也是核心信息,作品名和作品海报共同组成一项核心信息,作品年份为辅助信息。

在第1步明确业务所在的设备和媒体后,从视觉组件库取到对应设备媒体的总体构成,并确定必填槽位的具体内容。如需显示在多个设备,建议从手机开始。关于卡片总体构成和必填项,详见视觉组件-卡片组件-总体构成。
示例:
准备图标和意图名后填充可得卡片总体效果。

通用模板是围绕多种不同核心信息的卡片视觉设计,遵循EMUI的规范和卡片设计原则,具有结构清晰、主次分明的特点。各业务垂类接入时,建议优先考虑采用视觉组件库所提供的8个通用模板。根据第2步定义的核心信息和类型,选择卡片内容区通用模板:
(1)图文型:核心信息为一个事物的基本信息。
(2)宫格型:核心信息为以图片为主体的一个到多个项目展示。
(3)交易型:核心信息为项目价格。
(4)简报型:核心信息为一个关键数据或一句总结的话。
(5)日程型:核心信息为起止时间。
(6)控件型:核心信息为可交互控件(开关、调节、勾选框等) 。
(7)辅助型:核心信息为多个并列数据内容 。
上述的通用模板是以单一项核心信息为基础而提供的,如果定义的核心信息类型为不同类型或是重复结构的多项,则可以用复合模板:
(1)列表型:同类模板上下重复排列,支持语音多轮交互时,每项前自动配置序号。
(2)主副型:两类模板上下排列,上为主模板,下为副模板,副模板可重复排列。
关于各模板的具体样式和详细描述详见视觉组件-卡片组件-通用模板。
接入模板流程,详见卡片类快服务开发指南。
示例:
根据影人百科的核心信息,采用图文型和宫格型复合模板。

因为模板不针对垂类,只针对视觉,所以没有规定某个槽位必须填写的内容,给到业务设计很大的自由度。
业务设计师可以分析业务诉求,根据第2步得到的信息等级的关系,按照“核心信息>图片槽位>文字槽位从左到右>文字槽位从上到下”的顺序进行填充。
通用模板的槽位数量是各垂类综合下来的最大值,具体垂类不需要填满所有槽位。如不填充槽位,则该组件不占位,让已填充的组件有更大的展示空间。当然组件尺寸不能无限扩大,其对内容量有一定的限制。每个模板都定义了各槽位的文本行数限制和可选图片尺寸。调整规则详见视觉组件-卡片组件-通用模板的自适应能力。
示例:
按顺序填充卡片模板部分槽位后调整得如下效果,至此手机端的卡片视觉设计已完成。

当无法直接采用卡片模板时,可自定义卡片设计。注意,可定义的部分为卡片内容区,总体构成不可修改。
业务可根据业务需要自由配置在第2步各信息等级的对应的字号、字重、颜色,并组合槽位搭建卡片。但为了保证业务自定义设计符合平台规范,且在各设备上有符合人因标准的视觉体验,槽位的样式规格必须在组件库提供的槽位组件预设范围内选择(品牌色除外),即7种字号大小、2种字重、5种间距、6种图片尺寸等范围。 槽位样式的预设值,详见视觉组件-卡片组件-槽位组件。
卡片设计中,有规律的、符合信息等级的组件间距配置,能带来良好的信息层级区分和用户浏览体验。通用模板遵循了以下间距配置规则,可供自定义搭建参考:
(1)一般间距选择为XS 2,S 4,M 8,XL 16四档。
(2)判断两个槽位合适间距的因素有三个:槽位组件大小、槽位类型、横向间距还是纵向间距。
(3)文字组件的subtitle、body、caption、attribution,标签组件,图片组件的S、XS称为小组件,其他称为大组件,只要若干小组件组合为一项核心、次要、辅助信息,也称为大组件。
(4)两个文字小组件纵向间距为XS、横向间距为M, 其余两个小组件间不管是否同类,纵横间距均为S。
(5)同类大组件纵横间距均为M,不同类大组件纵横间距均为XL。
(6)两个文字大小组件纵向间距为XS、横向间距为M,不同类大小组件纵向间距为S,横向间距为M。
例如,下列为常用的组件间距效果:

业务可在选用预设样式和规范间距的前提下自定义槽位及槽位组合间的布局。在第3步定义信息等级的基础上,总体满足以下建议即可:
(1)信息按重要等级采用从左到右、从上到下布局;
(2)大组件优先横向组合、横向不超过三个大组件;
(3)非文字类小组件优先横向组合,文字类小组件优先纵向组合;
(4)结构重复的信息用分栏或列表的组合方式展示,注意支持语音多轮交互的列表,需要显示列表序号,关于分栏和列表组合,详见视觉组件-卡片组件-槽位组件;
例如,以下信息布局方式都是符合规范要求的:

详细自定义卡片设计规范,详见卡片类快服务开发指南-卡片类快服务设计规范。
根据第1步的结论,如果业务需要在其他带屏设备上展示卡片,规范提供了以下泛终端卡片适配规范。
对于使用了卡片模板的业务,只需了解下面所述的原理。对于自定义卡片,必须了解并执行下面步骤。
视觉设计遵循设备友好原则,意味着卡片要为不同设备媒体的更优体验呈现不同的视觉样式。具体表现为宽高适配、缩放适配、总体构成适配、样式规格适配、内容量适配以及布局适配。
(1)同一垂类意图卡片在不同设备上应保证槽位信息的完全一致。
(2)卡片在不同设备媒体上,总是会使自身的宽高等于该媒体提供卡片显示的宽高。如该媒体不限定卡片高度,则卡片高度跟随布局结果。
(3)不同设备的屏幕密度决定了卡片的整体缩放程度。
(4)不同设备的人因需求和视觉风格,决定了不同的卡片总体构成和不同的槽位视觉规格。
(5)不同设备不同媒体上可供卡片展示的宽高,决定了卡片的内容信息量。
(6)建议在尺寸更大的设备媒体(平板、触屏音箱、电视语音结果)上,展示与手机端相似的布局关系,在尺寸更小的设备媒体上(手表、电视首屏)展示更简单的布局关系。
在不同设备上适配卡片,首先需要知道该设备屏幕的密度(dpi)。例如,相同字号的文字在两倍密度的屏幕上显示,要占用两倍于原屏幕的像素。
当媒体要获取卡片时,会同时告知卡片显示的宽度和媒体所在设备的屏幕密度比(为屏幕当前dpi/160)。卡片根据密度比进行整体缩放后,再进行宽高的拉伸调整。

由于不同设备(手机、平板、折叠屏、触屏音箱、电视、手表)的不同媒体(智慧语音、负一屏等) 使用距离、主要交互方式、卡片展示尺寸各有不同,卡片总体构成会有所不同。与手机端设计类似,卡片总体构成的样式只能填充,不可修改。规范定义的各设备媒体的总体构成如下。

槽位、间距、颜色等组件在不同设备上,同一预设样式名对应有不同的规格。自定义卡片进行非手机端的适配设计时,需严格遵守样式对应关系,满足信息等级在所有设备上的一致性要求。
例如,手机、电视、触屏音箱上,文字槽位的Title样式、图片槽位的square样式、及颜色ColorPrimary均有不同。所有槽位组件的对应关系,详见视觉组件库。

每一个设备媒体都会决定其供卡片展示的宽度,触屏音箱和电视的首屏会同时决定卡片的宽高。卡片的宽高进而决定了卡片内容量。
根据EMUI规范,各设备媒体的视觉设计遵循EMUI栅格系统。通过与设备屏幕的水平dp比较,决定展示卡片宽度所占用的栅格数。

可见卡片在不同设备媒体上会有显著的大小差异,使同一个业务的卡片有机会承载不同的内容量。
如果在第2步定义的卡片信息中,含有多组结构相同且对展示数量没有明确要求的信息,则可以在大尺寸媒体上增加展示的数量,在小尺寸媒体上减少展示的数量。另外,在第3步中定义的重要级别较低的辅助信息,在小尺寸媒体上建议不展示。
通过把媒体提供的卡片展示宽度(需以dp为单位,dp=px/密度比)与下列的断点比较,可决定卡片展示的内容量级。
例如,宫格型模板适合内容量不限的多个图文组合,则比较断点后展示对应的内容量可以达到在对应媒体上的更佳体验。

卡片布局适配方法跟随EMUI布局规范,包括拉伸、均分、缩放、折行、延伸、隐藏。设计具体的卡片时,可根据在手机端上的设计效果和业务内容特点选择适配方法。
(1)当内容为以文本为主的一组信息且内容量有限,选择拉伸适配
(2)当内容为多组同级信息且内容量有限,选择均分适配
(3)当内容为以图片为主信息且内容量有限,选择缩放适配
(4)当内容为多组不同等级的信息且内容量有限,选择折行适配
(5)当内容为多组同级信息且内容量不限,在大尺寸媒体上选择延伸适配
(6)当内容为多组不同等级或多组同等级且内容量不限,在小尺寸媒体上选择隐藏适配
以下为各适配方法的详细说明和示例。
组件内元素的显示宽度不是固定值,而是通过相对参照物的方式来确定其开始和结束的位置,当显示大小发生变化时,元素的显示宽度随之发生改变。拉伸适配不会改变内容量。

组件内元素的显示宽度不是固定值,而是保持宽度均分(或保持宽度百分比),当显示大小发生变化,元素的显示宽度随之发生改变。均分适配不会改变内容量。

组件内元素的显示大小不是固定值(比例锁定),而是通过相对参照物的方式来确定其宽或者高的的参数,当布局的显示大小发生变化时,元素的大小随之发生改变。缩放适配不会改变内容量。

当显示区的布局横纵比大幅增大,组件的布局方式从上下布局改为左右布局;当显示区的布局横纵比大幅减小,组件的布局方式从左右布局改为上下布局。折行适配不会改变内容量。

当组件内元素横向布局,元素间的距离是固定时,布局可显示元素的数量可随着显示宽度的改变而发生变化。延伸适配会增加内容量。延伸适配会增加内容量。

当显示区有较大的宽高限制,部分次要或重复元素需要隐藏不展示。隐藏适配会减少内容量。

例如,图文型模板主要使用了拉伸,在小屏和小卡适配上同时使用了折行和隐藏。

关于本章
为了更好的设计对话式体验,本章将提供详细实用的设计指导与示例,用于创建小艺的对话设计。
首先你需要确定哪些任务应该被包含。其次,针对每个任务优先编写对话,再增加相应的视觉组件。这是为了确保在体验设计中保证“语音优先”。
人类的对话是非线形的,并且在表达同一事物时可能存在多种说法,因此,与真实的用户进行原型设计与测试至关重要。

虽然语音交互体验很强大也十分创新,但它并不适合所有的任务。因此,需要先分析和选择对话式体验的任务或特性。
如果你刚接触语音交互设计,请在了解第二章中的相关基础和原则。(详见基础和原则)
定义体验分为三个步骤:
(1)分析用户
(2)明确使用案例
(3)确定支持设备类型
为了定义对话式体验的特性和功能,你需要了解你的用户、现有技术能力并着眼于现有的特性以及相关的竞品。让我们从了解语音技能的潜在使用者开始。
当你为潜在用户考虑时,需要考虑以下方面:
(1)哪些人可能会使用你设计的技能? 这些用户的目标是什么?
(2)在何时何地他们最有可能使用你的技能?最重要的用户旅程是什么?
(3)他们是如何与你的技能交互?
确定潜在的使用案例
语音交互设计时,回顾和评价现有的应用是快速了解已有特性的快捷途径。
通常,用户使用频率最高的特性就应该被包含在对话式体验中。
当然,你也可以结合几个不同的功能,融入你的对话式体验中。
确定适合对话式体验的使用案例
为了保证使用案例适合对话式的交互体验,你可以使用以下的标准来进行选择,筛选后的使用案例就将成为设计对话的特性或功能。这个阶段可以为特性进行优先级排序(比如根据使用频率或重要性等)。
选择标准
参考以下几点来确定对话式设计是否适合作为该使用案例的交互方式:
(1)在对话场景中是自然的
(2)为用户节省时间和精力
(3)可以多任务协同

排除不适合设备类型的使用案例
使用用户分析和使用场景分析方法,决定技能将会支持哪些设备类型。由于用户对任何设备上的技能都有所期待,因此在设计时你应该考虑使用案例在所有设备类型上都尽可能支持。
如果你想重新回顾有有关设备类型之间交互差异的知识,请查看第二章中的相关部分。(详见交互设计)
应用下面的步骤,你在第一步中确定的使用案例将会成为独立的语音交互技能。在第二步中,你需要通过撰写一些示例对话来获得用户实际体验时的低保真原型。
在第二章中了解有关对话式体验的核心技术概念的更多信息。(详见对话设计)

了解更多技能请求词和欢迎语,(详见 “对话设计-对话交互工作原理”,“对话组件-欢迎语”)
为技能集取个名字
如果是现有的应用或服务,就可以用原来的名字对技能集进行命名。为方便记忆,技能集的名字应该尽量简短并且相对独特。
设计欢迎语
每个技能集只能有一个欢迎语。欢迎语应该是热情并简短的,同时又能让用户快速了解技能集里的内容;另一方面,欢迎语引导用户进行下一步操作。
撰写示例对话可以帮助你“设计”自然的对话流程。直接从流程图入手进行设计并不是最好的方法,相比流程图,正常人的对话可能会发展到各个方向。
针对一个用户角色和一个使用案例
撰写更简单的对话-主流程
专注在口语化的对话上以确保语音优先的体验,在无屏设备上也能正常运行;下一阶段,我们会增加可视的组件。用你自己以往交流沟通的经验来让对话听起来自然流畅,在这个阶段,你不用写出所有的对话细节。
把你的对话读出来并且尝试角色扮演
通过重复阅读来逐渐增加文本的复杂性
写出自然对话的小技巧:你可以尝试使用以下几种方法使对话听起来更自然。
纸面朗读
当写完对话时,可以找两个不熟悉该设计的人,一个朗读语音助手小艺的播报,一个朗读给定的用户典型说法。
测试维度:直观地感受播报的效果(是否具有代表性,是否自然)。
一口气测试
当写完对话时,大声朗读设计的对话内容。如果可以一口气读完一个对话,初步判定对话长度合适;但如果中间需要换气,就要考虑适当缩短对话的长度了。对于列表或步骤式的播报,每个选项或步骤都要单独读出。
测试维度:播报的长度是否合适,是否有可能超过用户认知负荷。
示例
我们用提醒的例子来说明示例对话的撰写,你可以在简单流程案例部分中查看最后输出的方案。
| 说话者 | 对话内容 |
| 用户 | 小艺,帮我创建一个提醒。 |
| 小艺 | 好的,没问题,你想让我提醒什么? |
| 用户 | 明天早上联系房东 |
| 小艺 | 好的,明天早上8点 “联系房东”。我记得没错吧? |
| 用户 | 嗯,能帮我换成9:30吗? |
| 小艺 | 没问题。好的,明天早上9点半联系房东,确定保存吗? |
| 用户 | OK,完美。 |
| 小艺 | 好的,已经帮你保存好了。 |
现在,你将使用示例对话来识别意图和槽位。这样一来,当用户对小艺说话时(典型说法),系统就能识别到用户想做什么(意图)以及用来处理意图的其他信息(槽位)。
在第二章中了解更多关于意图和槽位的定语及特性。(详见对话设计-对话交互工作原理)
使用撰写的示例对话、意图和槽位,继续设计对话的详细顺序。从主逻辑的流程开始写,先完成“主流程”,然后再写分支流程,通过分支流程向用户询问缺失的槽位。最后再考虑各种可能发生的错误,并针对这些错误撰写异常处理的对话。
构建对话流程:流程包含三种:主流程、分支流程和异常处理流程。
从主流程开始:主流程是最简单的流程,不需要后续的分支流程来获取用户额外的信息。在接下来的步骤中你还要撰写更多典型说法。你需要定义小艺将如何回答用户,怎样结束对话。
结束主流程:在小艺作出最后的回复后,应该提供一个结束标记来示意对话的结束。
分支流程出现在任意必选槽位信息缺失时,小艺需要向用户询问更多细节。分支流程属于“多轮对话”的一种,多轮对话还包括确认和消歧。(详见“对话组件-确认”“对话组件-槽位追问&消歧”)
在不同技能的分支流程中,存在许多典型的微对话。对话式设计系统中会提供许多这样的“对话组件”。你可以把它当作模版,这样你就不用每次都去手动地重写一次。但是你可能需要更改细节让它更适合你的技能对话。(详见“对话组件”)。
使用你在第二步中设置的槽位优先级对分支流程进行排序。最重要的槽位应该成为第一个分支流程。你可以根据人和人之间自然对话的顺序来安排这些槽位出现的先后顺序。
因为每次用户和小艺对话时都有可能出现异常,所以每段对话都需要有异常处理的机制。有关如何编写错误消息的详细信息,请参阅对话组件-错误。
(1)撰写系统错误消息
(2)撰写无信息输入以及无匹配消息
到目前为止的说明都聚焦在语音对话的详细流程上。在语音优先体验的设计中考虑只有语音对话的情况是非常重要的,因为某些设备类型只依赖语音这种单一模态。接下来,你将添加一些视觉组件、推荐指令、屏幕对话等,这些都是小艺用户体验的重要组成部分。这些组件在设计之初已经考虑到了跨设备的适配问题,方便你直接调用。(详见“交互设计-交互组件”)
在规范中,这些组件对每种设备类型的适配都有特定的样式和使用限制。在你继续阅读之前,请确保你已经熟悉了相关的样式指南。你可以在组件库查看相关组件。(详见“视觉组件 ”)
在完成每段对话的同时定义以下三个方面会对你的工作有所帮助。
定义屏幕对话
通过屏幕中的文字显示,一般来说显示对话比播报对话更短,特别是当其他可视组件同时出现在屏幕上时。所以显示对话不需要将所有东西通过纯文字来解释。
定义推荐指令
推荐指令通常出现在提示显示和其他任何可视组件下方。它们是提示用户该如何继续或运转对话的预设建议。并不是每段对话都需要添加推荐指令,但是它们对于完善主题、发现相关主题、后续步骤和支撑语轮转换很有帮助。(详见“交互设计-交互组件-推荐指令”)
定义视觉组件
视觉组件主要是出现在显示对话下方的卡片式组件。它们给用户提供了可视化信息,并引导用户通过点按输入。在设计时你可以选择不同种类的视觉组件,如果你选择的是系统默认的样式,就能兼容不同的设备类型。在为你为对话设计可视组件之前,请确保你已经了解了基本的原则和设计准则。(详见“交互设计-交互组件”“视觉组件”)
典型说法可以理解为用户潜在表达方式的“模版”。由于在自然的对话中存在各种各样的表达方式,所以在定义典型说法时,应该使用尽量多的不同表达方式。根据经验,在开始撰写对话时最少定义十个不同的典型说法。
每轮对话都需要定典型说法,这样小艺就会知道想从用户那里听到什么。你可以参考下面的提醒案例来丰富典型说法。
| 意图 {创建提醒} | |
| ✓ | “(你能) 提醒我 {内容} {时间}|{地点} {重复}” |
| ✓ | “创建一个提醒 {内容} {时间}|{地点} {重复}” |
| ✓ | “建立一个提醒 {内容} {时间}|{地点} {重复}” |
| ✓ | “我需要一个提醒 {内容} {时间}|{地点} {重复}” |
| ✓ | “告诉我 {内容} {时间}|{地点} {重复}” |
| ✓ | “通知我 {时间}|{地点} {重复} to {内容}” |
| ✓ | “告知我 {内容} {时间}|{地点} {重复}” |
| ✓ | “提醒我 {时间}|{地点} {重复} to {内容}” |
| ✓ | “提示我 {内容} {时间}|{地点} {重复}” |
| ✓ | … |
| 分支流程 确认 | |
| ✓ | “保存” |
| ✓ | “更改时间为{时间} |
| ✓ | … |
| 分支流程 编辑细节 | |
| ✓ | 改到 {时间}” |
| ✓ | “把名字改为{内容} |
| ✓ | … |
用户测试是设计对话体验时必不可少的部分。除了真实的用户测试之外,没有其他更好的方法可以得到真实的反馈。用户测试对于对话式设计尤其重要,因为人们交流和询问的方式有很多,用户测试可以帮你确定需要改进的地方。
(1)自然的对话:注意用户是如何自然地与小艺交互。他们通常会用什么样的表达方式?在某些情况下,小艺的播报是否会令用户感到尴尬或不自然?
(2)困惑:找到用户的困惑,尤其是不知道该说什么或该做什么的的地方。
(3)典型说法:记下用户与小艺对话时所有不同的说法,以便在你的设计中增加更多的典型说法;用户也可能会有超出预期的说法,记录下来以便更新设计流程图。
(4)耐心临界点:用户失去耐心时,表示交互过程过于冗长。重新回顾你撰写的对话,看看能不能把它变得更简洁。
(5)对话的掌控:在设计的对话中,用户应该感觉到他们在控制对话的走向,而不是被小艺牵着鼻子走。
你可以用现有的资源进行一个快速的用户测试,类似第一步中测试示例对话的方法。要注意,你只能用这个方法测试口语对话,不能用它来做其他相关方面的测试(比如视觉组件)。
(6)寻找测试参与者
尽量找一些不熟悉项目的人,比如朋友、家人、同事。最好找8个左右不同的人进行测试。
(7)角色扮演对话
你来扮演小艺,同时观察参与者们作为用户时的反应,然后根据设计的流程来作出相应的回复。
(8)记下任何可以改进的点
比如,如果用户的回复超出了你原先设定的脚本,你可以想想小艺会怎么说,也可以适当的即兴发挥。同时要把这些地方记下来,这样可以帮助提升设计。
迭代更新对于任何设计流程都很重要,尤其是在对话式设计中。在设计过程中,你可能需要对设计进行多次的迭代更新,直到对话体验达到预期为止。
确定改进点以及原因
从用户测试中找到你需要改进设计的地方。以下是一些常见的问题:
(1)需要增加新的典型说法?
(2)槽位缺失?
(3)流程错误?
(4)错误处理不完整?
(5)可视组件或推荐指令有问题?
(6)发现一个新的用户意图?
(1)对话组件用以表达语义、行为和意图,以推动实现用户目标,是构成小艺对话的常用元素。
(2)使用不同的对话组件可以形成不同的对话表达方式。
对于同一个用户请求,可以通过不同的对话设计组件组合,形成同一语义,不同风格的对话。

| 组件 | 维度 | 检查点 |
| 欢迎语 | 欢迎用户 | (1)亲切、简单地和用户打招呼 (2)不需要重复技能唤醒词 |
| 建立用户正确预期 | (1)简单地介绍一下技能的功能 (2)可以举2-3个高频的功能,但不要平铺细节。 | |
| 话语主导权转移给用户 | 用询问等方式把话语权转移给用户 | |
| 槽位追问 & 消歧 | 必要槽齐全 | (1)一次询问一个槽位 (2)必要槽位缺失的时候发出询问,但不是所有槽位都需要通过询问获取。 (3)如果可选槽位关系核心体验,也可以发出询问。 |
| 操作对象唯一 | (1)用户指令包含多个可能的操作对象,询问用户继续选择。 (2)可以选用特殊疑问句或选择疑问句 (3)不是所有的场景都需要语音消歧,如歌曲、地点等。 | |
| 确认 | 根据场景使用合适的确认方式 | (1)不可撤销的动作需要使用显性确认。 (2)多轮对话中的(逐步)确认、最后执行结果对象不明确,可以使用隐性确认。 (3)使用确认词(见对话组件-确认词 ) (4)不使用语音确认:可撤销动作、内容确定但非关键(用户指定听某首歌)、内容本身带信息确认(如有声书章节带标题)、有明显的其他执行结果反馈、抢断任务音频的任务,但可考虑使用有识别度的音效确认。 |
| 确认词 | 明确小艺已收到答复并在跟踪对话 | (1)不要重复使用,不要过度使用“好的”。 (2)与角色设计相符 (3)在多轮对话中与槽位追问、消除歧义、确认等连用,使对话自然。 (4)有条件地执行指令/操作有延时的任务可用确认词确认,并表明条件/延时等待。 |
| 道歉 | 不责备用户/三方 | 无法处理时,从小艺的角度说明无法处理的原因。 |
| 表明现状 | (1)无法直接满足需求时,及时告知用户。 (2)清楚传达小艺当前的情况,但不过分解释。 (3)对于业务错误导致无法执行,可以不使用“对不起”。 | |
| 表达期望 | (1)表达期望,提供现在其他可行的解决方法。 (2)如果现时不能解决,告知用户稍后尝试。 | |
| 错误 | 错误类型使用合适的策略 | 详见对话组件-错误 |
| 列表 | 容易记忆 | 查询结果/选项:一次最佳播报4±1项 |
| 辨识度高 | 不同选项之间描述具备明显差异 | |
| 容易理解 | (1)列表的组织遵循自然/逻辑顺序 (2)列表结构需要进行必要的分级,建立多个列表层级。 | |
| 提示 | 帮助/发现新功能/错误修复 | (1)常见使用句式:你可以说/试试对我说 (2)不使用命令句式 (3)提供真实可靠的实例 |
| 结束语 | 对话推进 | 可以通过询问引导用户继续澄清目标 |
| 快速结束 | 不适用对话、意图推进的,尽快结束对话。 |
欢迎语是语音技能和用户互动的第一环(用户也可以直接说出意图,跳过欢迎语),因此是技能的“第一印象”。
欢迎语的目标是快速建立用户预期,帮助用户发现技能,并把话语主导权转移给用户。
(1)使用“你好”“欢迎”等方式亲切、简单地和用户打招呼
(2)不需要重复技能唤醒词

(1)简单地介绍一下技能的功能
(2)可以举2-3个高频的功能,但不要平铺细节。

用询问等方式把话语权转移给用户

用户当前的提供的信息无法帮助小艺完成任务目标,小艺需要发起请求让用户补充/选择必要的信息。
(1)一次询问一个槽位
(2)必要槽位缺失的时候发出询问,但不是所有槽位都需要通过询问获取(如GPS定位知道用户所处的地理位置)。
(3)如果可选槽位关系核心体验,也可以发出追问。

(1)用户指令包含多个可能的操作对象,询问用户继续选择。
(2)可以选用特殊疑问句或选择疑问句进行消歧
(3)如果能根据语境等消歧,则不需要语音消歧。

对于以语音反馈为主的对话设计而言,确认每个字句的意思对于体验十分重要。确认能表明小艺是否能正确理解用户的说法,因此在每一轮用户说法后小艺都要及时确认。及时确认是提高对话效率的关键。
1. 确认方式:
对其识别的用户输入进行显性的验证(一般使用“….,对吗?”)
2. 适用场景:
即将执行关键的动作,如支付、发送信息。

1. 确认方式:
小艺在下一轮对话交互中包括需要和用户确认的信息,并继续执行任务。
2. 适用场景:
(1)多轮对话中的(逐步)确认
(2)小艺执行结果对象用户不一定明确(如随机播放歌曲)

如果对话交互涉及如下场景,可以不进行语音确认,或使用有辨识度的音效替代语音确认:
(1)可撤销动作
(2)内容确定但非关键(用户指定听某首歌)
(3)内容本身带信息确认(如有声书章节带标题)
(4)有明显(如视觉)的执行结果任务
(5)抢断音频的任务


小艺使用确认词虽然不能表示上下文之间的逻辑关系,但可以向用户明确小艺已收到他们的答复并在跟踪对话。使用确认词还可以达到对话连贯,表达自然流畅的效果。
1. 适用场景:
(1)表示确认、接受或拒绝。
(2)可单独使用
(3)在多轮对话中可与槽位追问、消歧、显性/隐性确认等组合使用,使对话自然。
(4)有条件地执行指令/操作有延时的任务可使用,并表明条件/延时等待。
2. 注意事项:
(1)不要重复使用
(2)不要过度使用“好的”
(3)与角色设计相符


在很多情况下,相比于道歉,其实会有更好的沟通方式。频繁地说“对不起”听起来很烦人,并且有可能破坏用户对小艺的信心。因此,尽量少用“抱歉”“对不起”等表示道歉的词语。如需要使用,需要同时简单地告知用户小艺当前的情况。
1. 适用场景:
(1)小艺遇到错误(除业务错误,详见对话组件-错误 )
(2)社交话语需求(如受到责备)
2. 不要责备用户/三方
(1)无法处理时,从小艺的角度说明无法处理的原因。
(2)不要使用消极词汇

3. 表达期望
(1)表达期望,提供现在其他可行的解决方法。
(2)如果现时不能解决,告知用户稍后尝试。

真实的对话过程不存在“听不懂”,因为人会采取复述或依靠经验的方式继续进行对话,但小艺达不到真实的语言理解模式。因此小艺有可能会因为 “听不懂”导致用户可能无法继续完成任务。因此,小艺需要对输入结果的有效性要进行判断;其次,小艺需要对可能出现的错误进行处理,帮助用户在出现错误时仍能重回对话,顺利完成操作。
| 错误类型 | 原因 | 对话轮数 | 修复策略建议 |
| No-input | 对话中小艺没有/不能听到用户的回应造成的原因有很多,如用户没说话、用户说话声音不够大、噪音、用户没有听到问题、用户在思考等。 | 2 | 再次提问/增加提示/提供选择(如有) |
| 不处理,结束对话 | |||
| No-match | 对话中小艺语义解释完整,但根据对话上下文,无法完成,造成的原因有很多,如打断、语音不准、用户问答文不对题等。 | 2 | 再次提问/增加提示/提供选择(如有) |
| 表明现状,结束对话 | |||
| 业务错误 | 小艺因为业务原因不能达成用户的目标 | 1 | 表明现状+其他可能解决方案,结束对话 |
1. 不处理
在以下场景,可以不处理错误:
(1)用户可以通过非语音交互方式(如点击)进行下一步操作
(2)什么也不做对话也不会中断
(3)可以快速重启对话
2. 表明现状
告知用户导致错误的原因。

3. 再次提问
希望用户重新回答小艺的问题:
(1)快速提问:能再说一次吗?/你刚刚说什么?/再告诉我一遍吧
(2)重新提问:再问一次同样的问题
(3)改写提问(详见对话设计原则-对话自然-句式多样)
快速提问与重复提问、改写提问的区别在于:快速提问一般默认用户还记得上文,没有重复小艺提问;而重复提问、改写提问会重复小艺提问

4. 提供选择
告知用户对话后续支持的具体说法。
使用形式:
(1)视觉或听觉提供选项
(2)播报形式详见对话组件-列表

5. 增加提示
告知用户在小艺当前希望获得的用户输入是什么(详见对话组件-提示)。

用于小艺展示多个查询结果,或者展示多个选项供用户选择。常用于消歧、错误修复、查询等场景。列表组件的使用意在让用户记住一些可能的选项,快速决策。
短期记忆的局限决定了语音中列表选项的数目是有限的:
(1)选项数量越少越好;
(2)一次交互中播报4±1项合理;
(3)告诉用户预期的选项数量。

除了数量,影项目间的词长,熟悉度和项目间可辨性也会影响短期记忆,因此:
(1)项目名称越简单越好
(2)项目名称名称差异越大越好

(1)列表项目结构遵循自然/逻辑顺序
(2)列表项目结构需要进行必要的分级,建立多个列表层级。

提示是小艺向用户呈现当前对话上下文的特定指令,或者告知用户完成任务的(替代)方法。
常用句式:你可以说/试试对我说
适用场景:帮助、推荐、错误(详见对话组件-错误 )。


(1)提供小艺能够理解的提示
(2)提供小艺能够执行的提示

一般技能会以确认、错误等结束对话,但若中途用户“取消”“停止”“不继续了”“退出”“再见”选择中断对话交互,需要设计结束语结束交互。无论是什么原因,用户都应该有权利决定何时结束对话。
可以通过询问引导用户继续澄清目标

如果不需要推进,尽快结束对话。
非关键操作退出前不需要二次确认

(1)视觉组件用以搭建成带屏设备每一步交互所呈现的高保真界面,以模拟交互场景,验证实现效果。
(2)视觉组件库提供不同设备下各视觉元素的规范样式。
(3)根据不同业务场景,视觉组件可根据交互规范有不同组合方式以准确呈现高保真效果。
组件库提供悬浮模式和全屏模式两种布局的典型界面,以及其对应的视觉元素。你可以在设计资源中下载相关sketch文件。

组件库含有搭建对话设计界面所需的基础组件。

小艺在手机上支持的两种布局—悬浮态和全屏态。组件库含有两态下的单轮对话的典型界面。

卡片组件结构从大到小分为总体构成、内容模板、槽位。

满足交互架构的卡片构成包含卡片背板、标题区(红)、内容区(蓝)、品宣区(黄)、文字按钮区(绿)。

(1)卡片背板:卡片背板的样式由媒体决定,业务目前不能自定义。
(2)标题区:必选,标题区包括三个槽位:
①、图标:填充应用图标或具体服务图标;
②、标题文本:垂类意图名;
③、卡片管理按钮:智慧语音统一不使用,负一屏统一使用菜单和置顶按钮,全局搜索会使用展开按钮。
(3)内容区:必选,选择内容模板或搭建自定义卡片。
(4)品宣声明区:必选,表明应用或服务来源。业务可决定是否还要展示更新状态、更新时间或责任声明。
(5)按钮区:可选,由业务决定按钮内容。智慧语音统一不展示按钮区,其他媒体最多三个按钮。
例如,航班动态意图在负一屏和智慧语音中的构成不同。

1. 通用模板是卡片内容区的模板,新业务垂类接入时,优先考虑可否直接采用。
(1)图文型:适合展示所有事物的基本信息,建议垂类意图:百科、快递、菜谱、新闻、邮件。
(2)宫格型:适合以图片为主体的一个到多个项目展示,建议垂类意图:搜图、相册、音乐、视频、电影。
(3)交易型:凸显项目价格,建议垂类意图:门票、电影票、商品信息。
(4)简报型:凸显一个关键数据或一句总结的话,建议垂类意图:导航、股票详情、步数统计、打车。
(5)日程型:凸显起止时间,建议垂类意图:日程、机票、火车票、演唱会门票。
(6)控件型:有可交互控件(开关、调节、勾选框等),细分为前后控件型和并列控件型。,建议垂类意图:音乐播放、联系人、应用推荐、代办、选择。
(7)辅助型:展示多个并列数据补充卡片内容,建议在复合模板中使用。
2. 根据业务需要,可把基本和垂类模板拼合成复合模板,规范允许以下复合类型。
(1)列表型:同类模板上下重复排列,语音多轮交互时,每项前自动配置序号。
(2)主副型:两类模板上下排列,上为主模板*,下为副模板,副模板可重复排列。
* 基于状态清晰原则,辅助型模板不建议用作主模板

槽位组件是组成卡片模板的基本元素,也是搭建自定义卡片的基本元素。槽位组件包括文字、图片、布满图片、标签、星标、控件。
规范包含了多种预设样式供各组件采用,如大小、字重、宽高、圆角、颜色等。规范也包含布局关系供选用,如间距、对齐方式、组合等。
文字
最基本的槽位组件,可被任意字符串填充。当文字槽位对应的接口返回多个字符串,则多个字符串只以一个样式展示,格式为“string1”+“ · ”+“string2”…如填充字段超过布局允许的长度,默认不换行截断并加“…”

间距和圆角
用于描述竖直和水平相对距离的参数,及配置图片槽位圆角大小的参数。

图片
固定尺寸的图片槽位,可被任意尺寸图片填充。将以较短边填满、按比例缩放并居中裁切,保证整体尺寸。

满布图片
宽度填满所在父布局的图片,可被任意尺寸图片填充。按预设比例裁切后,会根据所在布局的宽度变化而缩放,并保持比例。

标签
用于描述内容的状态、具备条件、补充说明,可填充4个全角字符或8个半角字符长度的字符串。

星标
展示评分信息,填充0-10之间的数字,组件将自动生成匹配的星标。

控件
指图标、勾选框、开关、文字按钮等可独立交互的元素。Icon需填充方形图片,Toggle可填充控件多个状态的图片,文字按钮填充字符串且不允许更改样式。

颜色
根据EMUI规范,标签、图表等设计元素上,可配置以下预设颜色。除必须用业务品牌色外不允许自定义。

组合
一个组合可由槽位组件和子组合构成,组合默认布局方式为宽度占满父组合、高度跟随子组件总高度变化。子组件/组合在组内有相互位置关系和对齐样式(槽位的默认布局方式为向左向上对齐,相互距离为零)。

分栏组和分栏复制组
分栏组是组合的一种特殊形式。同一层有多少分栏组,就会把宽度等分为以M为间距的多少栏,分栏组不与非分栏组同层级。分栏复制组的每组内容槽位结构完全相同,可配置默认状态下的重复数量,进而自适应配置在其他设备媒体上的展示数量。

列表组
列表组的每组内容槽位结构完全相同,各组间自动添加间距。在多轮语音交互场景,列表组会统一在每项前展示序号。可配置列表项数量。

组件库包含各模板的槽位定义表。展示模板中每个槽位已被定义了的样式和布局关系,并且会给每个模板定义槽位顺序和内容自适应规格。
例如,图文型模板由10个槽位嵌套在组合中搭建而成。第一第二列定义了按自上而下从左到右编号后对应的槽位,第3列定义了文字槽位的最大显示行数。

布局自适应
组件/组合之间在布局上有安全距离,当某组件/组合没被填充时,该组件不占位。则其四周的间距也应一并去掉,使卡片版式符合自适应设计要求。
例如,不填充槽位10,则槽位10不占位,根据自适应规格,其上方和左边的margin也不占位,然后与其同层级的Group,根据默认规格补满父组合的宽度。

内容自适应
文字和图片槽位根据内容自适应定义,会对所填充的内容有截断和裁切机制。
例如,百科名人垂类只填充槽位1、5、10,其他槽位及对应margin不占位。填充在槽位1中的文本较少,填充到槽位5的文本有几百字,填充到10的图片宽高比3:4。则根据自适应规格,槽位1显示1行、槽位5显示3行后跟省略号,槽位10把填充原图的居中裁切成为64*64正方形。

请参考以下关于交互设计、对话设计和视觉设计走查表,检查你的设计是否符合此规范。
| 序号 | 内容 | 是否符合 | |
| 通用 | 1 | 对话体验设计以语音体验优先,核心信息通过语音进行传递 | |
| 2 | 对话体验在不同的设备上保持一致 | ||
| 3 | 在对话过程中,能够清晰意识到当前所处阶段,并在不同设备间对于状态的指示保持一致 | ||
| 4 | 不同设备间的对话流程保持一致 | ||
| 交互组件 | 5 | 每项技能都需要撰写播报对话,核心内容通过语音进行播报 | |
| 6 | 根据设备能力选择 播报对话播报策略,无屏设备详细播报,有屏设备可根据实际情况选择简单播报 | ||
| 7 | 播报对话的文字风格倾向口语化 | ||
| 8 | 建议所有具备屏幕的设备都展示 屏幕对话,以满足多模态交互需求 | ||
| 9 | 屏幕对话传递的核心信息与 播报对话一致 | ||
| 10 | 屏幕对话的文字风格贴近书面语 | ||
| 11 | 屏幕对话的文字尽量简短,配合 视觉组件传递更多信息 |
| 序号 | 内容 | 是否符合 | |
| 建立信任 | 1 | 提供真实的信息 | |
| 2 | 告知能力界限 | ||
| 信息足够 | 3 | 播报时长合理 | |
| 4 | 话术简洁 | ||
| 清晰易懂 | 5 | 任务相关 | |
| 6 | 使用常用词汇 | ||
| 7 | 用词一致 | ||
| 8 | 考虑信息位置 | ||
| 9 | 表述清晰 | ||
| 自然友好 | 10 | 使用口语体 | |
| 11 | 句式多样 | ||
| 12 | 不贬损用户 | ||
| 13 | 避免敏感话题 | ||
| 14 | 谨慎处理未经用户请求的内容 | ||
| 序号 | 内容 | 是否符合 | |
| 语音优先 | 1 | 展示的核心信息与对话一致 | |
| 2 | 视觉组件通常不单独出现 | ||
| 状态清晰 | 3 | 卡片构成完整且模板必填项完成 | |
| 4 | 有明确的信息来源和时效说明展示 | ||
| 5 | 不展示与当前任务无关的信息 | ||
| 6 | 不展示敏感信息 | ||
| 设备友好 | 7 | 不同屏幕都要展示关键信息并保持一致 | |
| 8 | 符合不同屏幕体验的更优视觉样式 | ||
| 9 | 当屏幕尺寸允许时展示更多信息,当屏幕尺寸有限时隐藏次要信息 | ||
包含华为智慧助手形象、视觉设计、视觉组件模版等等资源。