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

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

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

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

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

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

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

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

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

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

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

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

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