GUI与VUI融合设计的八大原则

为了解决GUI和VUI融合时存在的问题，我们整理了在工作实战中总结出的八大设计原则，大家可以相互交流学习。

01

交互是一种行为，它具有目的性。

这句话是整个GUI和 VUI融合的核心。要知道用户每操作一个控件，每跳转一个页面，这些行为的背后都是有目的的。例如用户在GUI中打开空调界面开启空调、手动将温度调到20℃，这些行为背后的目的就是“打开空调并调到20°C”，这可以被VUI一句话实现。用户在意的是系统和应用能不能帮助他们达成目的，操控GUI的控件和页面只是辅助用户完成他们目的的手段之一，同理VUI的剧本也一样。

02

每种交互方式都能持续工作。

在座舱中仪表盘和中控屏幕基本处于常亮状态，用户无须对其开启就能直接交互。但是对于VUI来说，如果每一次语音交互都需要唤醒语音识别能力，这会影响整个操作流程和用户体验。所以VUI和GUI融合的前提是系统/应用拥有全双工语音交互的能力，系统/应用能持续一段时间倾听用户所说的话。

03

每种交互方式统一以 GUl为参照对象。

在车载系统中，无论是眼动操作、隔空手势操作、实体按钮还是GUI，都应该以GUI为参照对象进行设计，因为视觉通道接收的信息占全部感官的83%，如果以听觉为主的VUI为参照对象，该交互框架能输入和输出的信息量会直接锐减。其次，GUI显示的内容可以维持静止状态，VUI无法做到这一点；第三，GUI中有着丰富成熟的控件和组件，可以跟各种交互方式进行绑定。

04

每种交互方式相互配合，取长补短。

VUI的第一个短板是交互状态不明显，所以VUI的交互流程中建议配合GUI强化VUI的状态表示。VUI的第二个短板是受限于工作记忆，所以语音播报的内容句式和语法结构需要保持简单，内容播报尽可能控制在10s以内(中文和数字约为40字以内)，包含的信息尽量在3项以内。

那么，GUI上的所有信息是否相应地只显示3项内容呢？答案是否定的，因为这些内容并不是短暂地显示在屏幕上，它们可以被眼睛来回地扫视和重新阅读，所以用户在交互过程中没必要记住全部信息。

对于选项过多的菜单或者列表，VUI可以优先播报对用户来说重要的前三项，然后询问用户是否继续播报，与此同时，用户还可以通过触控的方式从GUI获取信息。

GUI的短板很明显，它需要用户看着屏幕才能正常交互。在驾驶过程中，司机开车低头很容易发生事故，因为在2s的时间内一辆时速100千米的汽车就能开出54米的距离。因此在驾驶场景下，让用户不看界面也能和系统交互的VUI变得越来越重要。为了解决GUI的短板以及提升驾驶场景中用户和系统的交互安全， GUI和 VUI可以这样配合：

1. VUI可以操控GUI的界面和功能，尤其文本输入功能；
2. GUI显示的文本内容允许 VUI播报相关内容；
3. 由VUI播报完整信息，GUI通过排版显示重点信息；
4. 基于VUI的声纹识别能直接省略用户在GUI输入密码的交互步骤。

05

以用户当前操作对象为目标发起交互流程。

在多模交互中最重要也是最麻烦的是操作对象的切换，因为它有可能意味着任务和上下文发生变化。例如，在空调界面中，用户说“调到25℃”，系统应该将空调温度调到25℃，而不是将音量调到25。

在语音交互中主语或者宾语即是操作对象；触屏GUI中手指触碰的地方即是操作对象，视线追踪、空手势、方向盘按键显示的焦点即是操作对象，在设计过程中我们应该如何考虑操作对象切换的问题呢？操作对象不一定只是控件和组件，它可以是一个页面，甚至是一个任务流程。

GUI和VUI融合的关键是将VUI意图中的主语/宾语和GUI里的控件组件/容器进行绑定，系统通过操作对象的对照就能知道GUI和VUI是否在操作同一个操作对象。以GUI为参照对象的好处是能让操作对象显性化，用户通过焦点的切换就知道自己的交互操作是否被系统正确识别，在多任务/多窗口里也能知道现在哪个任务/窗口被激活。

06

明确告诉用户当前的交互流程到达哪里每种交互方式都具备“选中目标”“执行过程”“结果反馈”三种属性。

相信大家对GUI中各种控件的按下态、加载态都很熟悉，但是在无法感知的交互过程中，例如VUI执行过程中的聆听、识别和加载状态，没有数字刻度的旋转按钮。这些细节很容易被设计师忽略。

“选中目标”能让用户和系统清晰知道当前操作的对象是谁;“执行过程”能让用户知道当前的交互进度到哪，避免用户产生焦虑:而“结果反馈”应该考虑“成功执行”和“无法执行”两种情况。“成功执行很好理解，但“无法执行”会比较特别。

GUI的好处是每一个控件的状态都能被用户看到，用户每一步交互都是围绕控件、组件和容器进行的。它们能引导和限制用户的交互流程，例如一个滑动条，用户滑到最左就不会而且不允许继续滑动了但是VUI做不到，因为用户看不到滑动条的上下限在哪里，而且他发出的指令不一定在系统支持的指令集中。

所以“无法执行”应该包括“业务支持失败”和“听不懂(没法分类)”两种情况。如果缺乏了“业务支持失败”这个细节，VUI只懂得跟用户说“不好意思我听不懂”或者“不好意思我无法执行”，这样会引起用户的反感。

07

GUI控件/组件应支持多种交互方式，如有差异建议增加说明。

在多模交互下，不同类型的操作控件/组件应由不同的VUI意图和流程来支持，文本类型的控件支持语音播报能力。在自然的多模交互中，用户在不同场景下有可能通过不同的交互通道完成相同的任务，所以设计多模交互体验时应该做到完整的冗余设计。

有些交互操作确实不太好实现冗余的设计，尤其是一些基于纯图标的按钮，或者全是复杂文字的链接，这时我们应该想办法在图标上增加文字以及在链接前面增加数字，但如果因为各种因素无法修改设计方案，建议通过其他方式告知用户暂时无法支持其他通道的交互操作，这样能有效避免用户觉得这是一个漏洞。

08

由交互管理器统一管理多种交互方式之间的操作和状态，包括容错管理意图/界面切换。

由于多通道之间的信息输入/输出存在着不同效率、同步/异步以及兼容/斥的差异，构建交互管理器有助于管理多模态交互之间的状态。简单理解的话，我们需要通过一个交互管理器来管理所有操作对象以及交互通道之间的关系，它的主要作用是监控不同操作对象以及交互通道产生操作数据时的先后顺序，然后将这些信息操作同步给所有交互通道，从而实现交互通道的管理。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！