基于文字描述来设计一个界面对于一些新手来说通常是一个棘手的问题。而这也是我分享设计这些不同的任务对话界面的详细过程的原因。
这篇文章中，我会叙述如何从第一次遇见到最终版本逐步地处理界面。全文约3700字，阅读约需要10分钟。
就像其他任何项目一样，设计语音或任何其他对话界面的过程不是线性的，而 是一个迭代的过程。但是，我们仍然可以在开发过程中找到一些可以帮助我们构建工作的步骤。
01
步骤1：产品设计
在我们开始之前，我会使用术语“ 产品”来表示完整的项目和更大开发项目的一部分特定功能。在我看来，产品的组成帮助人们从头到尾地解决需求。
在产品开发的第一阶段，我们需要定义项目范围和产品将要处理的情况。这通常需要开发团队、设计和业务员的共同努力。最终结果是对产品的一个高级的定义。
为了此定义成为一个成功的概述，每个利益相关者都需要深入了解其领域，明确团队其他用户的期望、技术可行性、可用资源和商业模式。以下列表是一些每个团队应当完成的任务，但是不完全详尽：
设计
团队使用用户体验研究工具来了解用户的需求和期望。例如，如果我们正在开发一个电影推荐助手，那么设计就会使用以下不同的策略来弄清用户想要获得什么。
如来自其他推荐电影的语音和图形界面的产品为基础；用户在寻找电影推荐时对于他们习惯的采访；在过去处理过相同情况的第三方文档。
从所有这些研究中，设计团队将提供潜在用户要求提供的且产品应该提供的功能列表。
业务
与设计团队密切合作，定义好功能列表……这都会使最终产品概述更加清晰。商业视角也会为不同可能选项的资源可用性和投资回报提供了一个更有见地的视角。
开发团队
开发团队是技术所有者。他们理解我们在可行性上努力地构建。它们帮助团队根据目标和预期结果了解一个解决方案是否值得追求。
如果这些团队中的任何一个工作失败，产品的成功就会受到影响。功能优先级需要三个团队之间的共同努力，我们可以使用不同的工具来做到这一点。
我个人推荐 精益创业法，并从第一天开始使用问题、客户和解决方案假设。
在精益创业法中，验证假设将指导我们如何对不同的开发项目进行优先级排序，或者指导我们从产品中删除哪些项目。
产品设计阶段的可交付成果
第一个产品设计步骤的结果是产品定义。如何记录该结果取决于公司和团队，但我喜欢使用清晰的用户旅程图和故事板。我用他们来表示用户如何处理产品、可用的不同选项以及他们可以获得的结果。在这个阶段，我通常不包含示例对话，而是更加关注功能和逐步的用户体验。
02
步骤2：创建脚本
一旦我们对产品有了一个高度全面的了解，我们就可以开始起草特定的用户交互了。在这一步骤最好的工具是记事本，我们可以在这里记录我们的脚本。
我们将处理的第一个脚本是 Happy Path。它代表了测试人员和被采访人员之间的最理想的对话。此人可以被定义为一个完美用户，他的行为总是符合预期，且交互上十分成功的。
作为设计师，我们的工作是为对话创建一个有意义的结构，确保不同的部分尽可能 有用且简洁。作为这项工作的一部分，我们需要了解我们添加和删除的每个句子的 目的，所有不能帮助用户获得成功体验的句子都要删除。
我个人回顾了我在三个不同的验证层中编写的所有提示，它们的工作原理如下：
- **每个句子的用途是什么？**这种验证有助于理解每个句子的目的。
- **整体体验需要这个目的吗？**据此我们可以评估我们在追求的目标是否正确。此时，我们可能删除一些句子，但不造成任何影响。
- **我们可以简化措辞吗？**即使目的正确，我们也需要检查是否有更简单的方式来表达想法。有时我们可以缩减句子，或者将几个表达相似想法的句子合并。目标是减少信息的长度，但减少的同时不能增加其复杂性。
在这一阶段，我们需要充分利用对话设计模式来帮助我们创建易于交互的体验。
脚本步骤的可交付成果
我们为交互的不同部分创建不同的对话，来展示客户将如何面对可能的不同情况。但是在这一点上，我们不处理错误或其他可能偏离正常路径的细节。
03
步骤3：测试与改进
一旦我们有了第一个设计方案，我们就可以开始从潜在用户那里获得反馈，验证Happy Path中列出的不同交互。我们虽然受到一些来自已有的用例和详细程度的限制，但我们仍然可以对我们的方法进行验证。
我们在这个阶段可以设定的目标也是有限的。
我们需要回顾我们的假设并验证一些关键方面，例如：这是该技术的正确用例吗？我们是否使用了正确的声音和语气？信息对于用户来说是否清晰，是否触发了我们期望从他们那里得到的答案？
对于这些最初的原型，我们可以使用任何可用的对话界面工具，如Botsociety、Fabble、Voiceflow等。将这些工具用于原型的最好的事情是我们可以获得一个更接近最终产品的测试版本。
我们也可以在几秒钟内创建一个原型。这无需任何外部工具，只需向潜在用户大声读出我们的消息。然后记录下测试人员间的互动，以便评估设计的性能。
测试和改进步骤的可交付成果
从这个阶段开始，你将获得有关你的交互的改进列表，包含你未计划在内的一些情况。
回顾你的测试笔记，并决定你是否需要处理此版本或未来版本中的潜在问题。你可以在表格或电子表格上记录所有内容。
04
步骤4：定义所有可能的场景
在前面的步骤里我们明确了产品的关键方面之后，就可以更深入地了解所有可能的交互情况。在这个阶段，我们将要处理：预期的、可能性很大的和存在可能性的情况、以及错误处理与对话的上下文环境。
预期的情况
预期的情况 是最直接的情况。
在这里，我们需要根据助手提供的选项来设计助理的行为方式。例如，如果我们提出“是/否”问题，如“你想再玩一次吗？”，我们将为两个预期答案中的每一个执行的提示和行动。
可能性很大的情况
可能很大的情况 涵盖不属于预期答案但可能发生的情况。
例如在游戏语音交互中，会提供一些详细的指示，一个号召性用语会提供不同的跟进选项。
大多数用户将继续使用号召性用语中提供的选项之一，但一些首次使用的用户会被要求再次阅读说明。
存在可能性的情况
存在可能性的情况 指的是一开始就没有被检测到，但是存在一些用户需要。它们通常以某种方式与具体用例相关，即使它们超出了我们的开发范围。
例如，在提供篮球运动员统计数据的语音交互中，用户可以获得对特定比赛结果的请求。
作为设计师，我们的工作之一就是尽可能发现这些可能的情况，在用户请求时，定义这些情况的处理办法。
错误的处理
错误处理 在一定程度上与前两种情况（很有可能的和存在可能的情况）相关，但不局限于它们。
我们需要发现并分类我们的用户可能面临到的所有错误。一旦我们确定了错误，我们就可以为这种情况定义提示和辅助行为。
对话的上下文环境
最后，我们需要考虑对话的上下文环境（背景）是如何在所有前面提到的场景中产生影响的。对话环境可以由各种变量定义，我们需要跟踪那些与我们的交互相关的变量。
例如，无头设备（headless device）和多模式设备上的交互是否相同？体验会随着时间的变化而变化吗？在需要地理定位的交互中，没有地理定位的设备的体验如何？在仅限于特定用户（例如儿童）的体验中，不同用户的体验如何？
详细定义步骤的可交付成果
第四阶段的结果是一份详细的文档，其中包含开发团队将用于编码解决方案的所有交互。完成这项工作做出来的产品可能会因团队而异，但它们通常是脚本、流程图或表格。
05
步骤5：测试我们的对话界面
在我们将这份设计文档交给开发团队之前，重要的是要进行新一轮的产品测试，验证方法和项目假设。
请记住，最好的设计不是只按照设计师考虑的来，而是帮助用户实现目标的设计多亏了许许多多的用于对话界面的设计和原型工具，让我们将能够在不涉及代码的情况下创建高保真交互。
使用这些工具中的任何一个来创建您的原型，并与不同的用户一起测试您的解决方案。记下测试人员的表现，特别注意每一个可能出现的问题。
测试步骤的可交付成果
完成测试后，我们可能需要将一些工作返回到之前的步骤，并重新定义一些交互内容。
有些解决方案不会像原计划的那样执行，并且由于测试原型，会出现一些情况和错误。不过，电子表格是记录所有不同问题和改进的最佳工具。
06
步骤6：交互性能分析和改进建议
在成功完成前面的 5 个步骤之后，是时候编写和发布我们的解决方案了。与任何其他项目一样，设计工作不会随着项目发布而完成，而是需要不断完善。
在产品公开前一秒钟，我们的性能数据完全基于有限的信息。助手应用上线后，它将开始吸引真正的用户，这些用户会发现我们没有考虑过的极端情况。
为了保持领先，设计需要在 KPI 定义上进行协作，跟踪我们认为对产品性能至关重要的特定交互。
分析步骤的可交付成果
从这项跟踪和分析工作中，我们将获得我们产品的问题和需要改进的列表。
我们将与产品团队的其他成员一起对列表进行优先级排序，并为下一个版本进行修复。设计会话界面的过程与任何其他图形界面没有太大区别。
本文提出的 6 个步骤使用了产品设计中常用的许多工具（精益创业、故事板、调研……），以及其他特定于对话世界的工具（脚本、语音原型工具……）。
设计过程将根据您工作的团队和每个项目的独特情况而有所不同。如果您在工作流程中使用不同的方法，可以在评论区和我们交流讨论。