了解叙事设计

见贤思齐

Collection原文引自DaveVronay的文章《UnderstandingNarrativeDesign》，该译文并非完整原文，内容已做删减和调整。叙事设计是一种比较少见的设计方法，不借助常用的设计软件、设计师也可完全以只用文字来描述方案。当设计方案与视觉元素完全剥离，或许反而能引导我们更加专注地去探索与构建核心流程。1为什么需要叙事设计设计师的工作是为难题提出优雅的解决方案，我们从广泛的想法中探索出可能性，再逐步深入、完善细节。但如何才能恰当地平衡我们在探索设计方向和推敲方案细节上所花的时间？我们所用的设计工具会在很大程度上影响我们思考的细致程度。设计师往往通过手绘、草图来进行初期的设计探索，然而草图对于用户和其他团队成员来说却难以理解，他们也无法将草图与实际产品联系起来。当然，由Sketch或Figma一类的设计软件所完成的高度细节化的设计是很易懂的，但这些高保真原型制作耗时，这也意味着设计师通常无法尝试太多不同的设计方向。此外，当这一类像素级完美的设计图被展示给潜在用户时，人们往往倾向于批评小细节，例如按钮的间距或颜色，反而会花更少的时间考虑整体流程。缺失样式细节时，用户才更容易从整体设计方向上提供更高维度的意见。更复杂的是，现代应用程序要为多个终端、多个系统设计。在草图上工作时，我们通常只是被困在其中一个形式里，我们所探索的解决方案也很可能冒着只是针对单一终端优化的风险。真正理想的情况是，有一种设计方法比草图更快，且维度足够高，以至于我们不会把设计方案与任何特定的样式细节绑定，且这种方式足够落地，能便于我们分享和展示设计方案，与用户进行快速验证。2进入叙事设计叙事设计是一种完全用文本描述设计方案的方式。它不需要借助任何特定的平台和图像，只以讲故事的方式描述用户如何完成任务。我们可以设想你正在为一家银行工作，你正要为银行新增一项转账功能，以允许用户直接向另一个人打款。叙事设计会这样描述整个过程：▲ 一个关于转账的简单叙事如你所见，叙事设计的的确确就是一个故事。你会发现，叙事里会用到一些特定的语言，例如决定、指定、选择一类的动词。▲ 把「言语行为」标蓝的叙事这些标蓝的词语其实就是「言语行为」，每个词语都代表了一种独特的互动类型。例如，“选择”是从一组选项中进行选择，而“指定”对应的是开放性输入，这些相同的言语行为在不同的系统上有不同的实现方式。在网站上，选项可能被展示在「选择」按钮里；在手机上，它可能出现在弹窗列表中；甚至在语音助手上，他可能会从一系列编号列表里被读出。然而这些行为本身是一致的，无论在哪种平台上，执行这些特定言语行为所需的认知负荷也是相同的。这种固定的复杂性使我们能简单快速地评估一个叙事设计的复杂程度。在用户界面里，每一个UI元素最终都是为了实现某种「言语行为」，这些也可以被归纳总结为确认、同意、警告、提醒、道歉、建议、通知等一系列固定词汇。因此，选择合适的「言语行为」，是帮助我们改进设计的第一步。以从银行的ATM机取款为例，我们知道纸币的面额是有限的，用户其实也并不会在意取的钱要具体到几元。那么我们只需要让用户从不同的常用数额中选择（轻触一次即可），而不必让用户指定他们想要的具体金额（使用数字键盘输入）。我们也可以把这两者合并，以“用户可以从5个常用金额中选择，或者选择‘其他’来自定义金额”来叙述这件事。3叙事和概念除了言语行为，叙事也可以被用来分析概念。概念是用户需要理解的词汇，理解这些才能让用户顺利地跟上流程里的所有步骤。还是以为银行增设新功能为例，图中标绿的词语就是我们设计的「概念」。▲ 把「概念」标绿的叙事用户理解了支付、账户、付款、收件人、地址簿、电子邮件地址、电话号码和金额，我们设计的整套流程才能够被使用。明确地列举出概念可以确保在设计师能清楚地追踪到自己引入的所有新概念，这些概念也可以通过被识别和归纳属性来开发，比如，对于一个帐户来说，它只会对应一个所有者、一个帐号和一个余额。列举并提取概念后可以找到用户进行概念验证，看他们是否能理解，以确保所有内容有效、易懂。理清楚概念其实就是在构建产品内容所构成的核心术语词典。作为设计师，我们要小心地控制我们所设计的「概念空间」。尽量重复利用用户已知的词汇，限制并谨慎地引入新概念，是保持设计简单易用的最佳方法之一。在使用图形化的工具进行设计时，我们很容易在无意中引入新概念，但在叙事设计中，这些却很容易识别。4修改叙事从用户处获取反馈梳理完叙事以后可以把它展示给用户，快速收集意见与反馈，以迭代更合适的版本。叙事设计对用户来说很好理解，你可以让他们浏览不同的叙事，询问他们更倾向于哪个；也可以让他们自己写一份叙述，以此与设计团队所创作的叙述进行比较。例如，在我们的银行付款案例中，我们发现，大多数用户谈论付款时，首先指定的是人，其次指定金额，最后才考虑账户（除了收款人有多个帐户的情况）。基于此，我们可能会改变我们设计的流程，调整叙事框架中第2、3、4项的顺序：▲ 根据用户反馈修改并调整顺序的叙事评判风险点与满意点与其他设计呈现方式相比，叙事修改起来要更加高效，因为它提供了一个简单的框架以评判设计中的风险点和满意点，并把这些与实际界面样式所引发的问题分离开。在叙事设计中，我们可以逐字逐句地打磨文案，寻找威胁。例如，在目前的叙事中，我们的希望让“用户指定收款方”，这里可能就会出现问题：如果用户不知道他们应该使用电子邮件还是电话号码，该怎么办？如果用户知道电话号码，但输错了怎么办？如果收款方不想提供给汇款人他们的电话号码，但仍然想得到付款，该怎么办？这些都是可以用叙事来评估和应对的风险。我们可以通过让用户从通讯录中调取号码、检查邮箱和电话号码是否有效、提示用户他正在向一个不在通讯录里的新对象汇款等方式来降低风险。这样一来，整个叙事可能就会被调整为：▲ 调整后的叙事，增加了对风险点的应对措施当然，并不是所有的风险点都需要被解决的。即使有些用户可能不想提供他们的电话号码来接受转账，但只要大多数人都能同意，我们就不会特地再调整叙事来满足这个边缘案例。相反，如果我们认为这是一件重要的事，我们也可以设计新的叙事来处理这个问题，比如让收款人访问一个特殊网站，在那里生成一次性收款码，再分享给转账发起人。归根结底，设计师需要在这个过程中判断风险的严重性，以此决定对风险点的处理方式。类似地，我们也可能从用户的转账行为中发现他们常对同一个人进行相同金额的转账，例如给孩子的零花钱、给园丁每周的酬劳，这些内容也可以作为满意点，被添加到叙述中。叙事与开发者验证叙事设计的另一个大优势是，它对开发团队验证和预估工作量非常有用。如果设计师只描述我们正在设计转账功能，开发者可能认为他们只需要一个简单的支付API。但是看到上面的叙述，他们会立即明白这背后还需要更多的后端支持。要判断用户以前是否有付款记录，就需要在用户付款时存储信息，并支持快速检索。要能展示出给某个收款人的默认转账金额，就需要能先存储这个信息。清晰的叙述可以让工程师了解主要需求，并在团队沿着某条设计小路走得太远之前把大家拽回来（例如存储付款信息太昂贵、难以负担，甚至可能出于法律原因而受到限制）。此外，其他团队也可以为构建叙事做出贡献。假设安全团队提出了“用户可能会上当受骗，向不法分子付款”的风险，而他们已经实现了一种安全验证服务，可以根据金额和收款人身份来判断转账是否可疑，但该服务可能需要5秒或更长时间才能执行。那么基于这一点，以及不法分子在转账中的小体量占比，我们可以将这项安全验证服务也添加到叙事中，并放在用户更愿意等待的最后一步。那么最终的叙事可能是这样的：▲根据其他团队意见调整后的最终叙事在有很多合规审查的、受监管的工作领域内，例如银行或医疗，叙事设计会起到很大作用。这些团队可以在叙事阶段就进行审查并提供反馈，以便于有效意见被更早地采纳，而不是等到设计终稿完成才介入。一旦完成并验证了叙事，它就可以被用来构建各个终端上的具体设计方案。相同的叙述可以在APP、网站、自动取款机、甚至聊天助手上使用。他们共用一套言语行为和概念，具备了同样的风险点和满意点，在无需特殊设计工具的情况下，叙事设计确保了用户在各个平台上的一致性体验，让每个平台能以最有效的原生方式实现我们设计好的「言语行为」。—  Theend  —如在阅读过程中发现错误与疏漏之处，欢迎不吝指出。如需转载，请注明来自WeDesign。原文链接Miao正在发芽