第 4 章 设立愿景：场景和设计需求
弥合研究与设计之间的鸿沟
这一过程包含四个主要活动：
- 利用故事清洁或场景剧本来设想理想的用户交互过程。
- 运用场景剧本来提取设计需求。
- 依次使用这些需求来定义产品的基本交互需要。
- 在这个框架中不断增加设计细节。
叙事是这一过程的粘合剂，是研究数据和潜在产品特性的指南针：用人物模型创造故事，让故事指明用户满意的地方。
场景：以叙述为设计工具
叙述是高效的设计工具，我们为数字产品创造的体验都有其自己的叙事结构（可能更有根据），交互设计就建立在这些叙事的基础上。
叙事在交互产品的设觉设计描述方面也很有效。交互设计首先是对不断发生的行为进行设计。因此，叙事结构结合快速、灵活的视觉工具，能够完美地激发、想象、呈现、验证各种交互概念。
在过程的最初阶段，我们只关注情节中的各个点，这使我们能在探索设计概念时保持灵活。把关键点放在叙事上，我们能够快速灵活地设计出高水准的方案，而不会在惰性和开支的泥潭中纠结。
场景对比使用案例、用户故事
场景和使用案例都是用来描述用户与系统交互的方法。不过，他们服务于不同的功能。目标导向的场景是从具体用户（人物模型）角度定义产品行为的迭代手段。其中不仅包括系统的功能，也包括功能的优先级排序，以及这些功能如何从用户所见、用户如何与系统交互的角度来表达。
使用案例通常是一种技术，基于对系统功能需求的全面描述上，具有事务性，关注低层用户行为和相应的系统反应。用例在确定极端例子及产品功能是否完整的方面用处很大，但只适用于设计验证的后期。
敏捷编程方法中会采用用户故事的方式，但通常这些故事并非真实的故事或叙事。相反，用户故事由简短的词句组成，如“作为用户，我想登录我的网上银行账户。”一般来说，紧跟着会出现另一组句子，简单描述完这一交互所需要的界面。用户故事更像是费正式的措辞要求，而不是场景。用户故事不会描述宏观层面的整个用户流程或用户最终目标。这可以删除不必要的交互，锁定用户真实需求。
基于场景的设计
场景（scenario）一般用来描述具体解决设计问题的方法：运用一个具体的故事构建并阐明设计方案。
“场景能够针对多种不同的目的，描述各级细节的情况。有助于协调所设计项目的各个方面。”
——约翰 卡罗尔
基于人物模型的场景
基于人物模型的场景是用叙事的方式简明描述运用产品或服务来实现具体目标的一个或多个人物模型。这种方式能让我们能够从一个故事作为设计的开端，这个故事从人物模型的角度描述一种理想的体验，聚焦于人及其思考和行为方式，而不是关注科技或者商业目标的实现。
三类场景
情境场景：用于在更高层次探索产品如何更好地服务于人物模型的需求。情景场景从人物模型的角度撰写，关注人类活动、感知和期望。
关键路径场景：关注最重要的用户交互，始终注意人物模型如何使用产品以达到自身目标。
验证场景：用来验证在各种情况下测试设计方案。
设计需求：交互的“什么”问题
需求定义阶段决定设计中的“什么”问题：人物模型需要哪些信息和能力来完成其目标。在进入下一个问题之前，阐明交互中需要“什么”并达成一致意见很关键：产品外观是什么样子、有什么样的行为、如何操作、感觉如何。混淆这两个问题是产品交互设计中最严重的陷阱之一。请不要跳过这一环节，否则会有陷入死循环的风险。
如果没有阐明问题并达成一致意见就提出解决方案，结果就是没有清晰、客观的方法评估设计是否适当。这又会导致产品团队和利益相关者中产生“我喜欢”对抗“你喜欢”的主观差异。
设计原则：设计产品行为前，首先定义产品会做什么。
设计需求不是特性
需求（requirement）并不指产品的特性或功能，而是需要(needs)**的同义词。需求必须满足人类和商业的需要，这是产品必须满足的目标。
设计需求不是规格说明
需求并不是产品经理输出的市场营销需求文档（MRD）或者项目需求文档（PRD）。虽然上述文档在良好的执行时是试图描述“产品是什么”问题，但也存在缺陷。
许多MRD和PRD文档容易将产品需求与实现方式混为一谈。在设计过程之前命令制定解决方案只会引来麻烦，因为这样容易导致笨拙和杂乱的交互和产品。
设计需求是战略性的
为了找到最佳的方式来满足特定的人群需求，就要从需求着手，而不是从解决方案开始。分离问题和解决方案是一种方法，这么做可以尽可能的保持灵活性。通过明确定义用户需求，设计师能够同技术人员一道，找到切实可行的最佳方案，同时保证产品帮助人们达到目标的能力不会妥协。这样的话，执行出现问题是不会殃及产品定义。同样，这样也就可能规划长期技术发展，从而能够提供日益先进的途径来满足用户需求。
设计需求来源广泛
人物模型和场景是设计需求的主要来源，但还包括其他需求。人物模型商业需求的限制，以及技术和法律的约束通常是再采访产品的商业和技术利益相关者时收集到的。
需求定义过程
把健壮的模型转化为设计方案需要经过两个主要阶段。需求定义回答了关于产品是什么以及要做什么的问题。框架定义则主要回答了产品行为方式和如何构建产品来满足用户目标等问题。
需求定义由以下五个步骤组成：
- 创建问题和愿景陈述
- 探索和头脑风暴
- 确定人物模型期望
- 构建情景场景
- 明确设计需求
这是个循环往复的过程。设计师可能要在步骤3和步骤5之间重复多次，直到需求稳定下来。这是本过程的必要环节，不能省略。
步骤1：创建问题和愿景陈述
在构思过程开始前，设计师要对前进方向有明确的指令，这点很重要。问题和愿景陈述提供了这种指令，非常有利于在设计过程向前推进之前，在利益相关者之间达成共识。
问题陈述定义了设计启动的目标。设计的问题陈述应该同时为人物模型以及提供产品给人物模型的企业，简明地反应变化。通常在企业和人物模型的关注点之间有因果关系。例如：
X公司的顾客满意率低。市场占有率去年下降了10%，因为用户执行任务X、Y、Z时工具不趁手，而用户执行这些任务其实是为了满足目标G。
把商业问题和可用性问题联系起来是推动利益相关者支持设计的关键，也是满足用户和商业目标而拟定设计框架的关键。
愿景陈述是问题陈述的倒转，是高层设计目标或委托。在愿景陈述中，将以用户需求为引领，将需求转化为如何让设计愿景满足商业目标。例如：
产品X的新设计能够提高用户执行任务X、Y、Z的准确性、效率等，避免他们当前面临的A、B、和C问题，从而帮助用户完成目标G。这能显著提高X公司的客户满意度，提高市场份额。
问题和愿景陈述中的内容应该直接从研究和用户模型中获得，用户目标和需求应该从主要和次要人物模型中得出，而商业目标则应该从利益相关者的访谈中提取。
当你重新设计已有产品时，问题和愿景陈述很有用。对于新产品或者针对尚未开发的针对市场设计的产品也有用。有了这些任务，把用户目标和挫折整理成问题和愿景陈述有助于团队建立认识，把精力专注于接下来设计活动的重点事项。
步骤2：探索和头脑风暴
在理想情况下，我们希望不带臆断地创建情境场景，而是真正地关注人物模型更可能如何使用产品。再次阶段，我们开展头脑风暴，将脑海中的想法提炼出来，这样才能把这些创意记录下来，暂时先把想法放在那里。
这里的主要目的是尽可能地剔除先入之见。这么做允许设计师保持开发灵活。另一个好处是将你的思维切换到“解决方案模式”，开始创造性设计。
探索（exploration）**一词表明，应该不受约束，不予批判。把所有的想法记录下来，妥善保留到过程的后期。或许这些想法能派上用场。
不要在头脑风暴中花费太多时间。如果发现想法已经开始重复，没什么新想法了，就是时候结束了。
步骤3：确定人物模型期望
人物模型的心理模型是其对现实的内部呈现——他自己如何思考事物、如何解释事物。心理模型是根深蒂固的，在一个人的自我意识中几乎是下意识的，往往是一生经历累计的结果。人们对产品及其工作方式的期望，心理模型透露着大量的信息。
因此，界面的呈现模型——设计如何表现和呈现自己——应该尽可能地与我们对用户心理模型的理解相契合，这点很重要。呈现模型不反应实现模型，即产品实际的内部构造方式。
为了达到这一目标，我们正式记录这些期望。这是需求的一个重要来源，对于每一个主要和次要模型，我们要确定以下几点：
- 影响人物模型的态度、经历、渴望和其他社会、文化、环境，以及人物模型认知因素。
- 人物模型对使用产品的体验可能持有的一般期望和愿望。
- 人物模型对产品行为的期待和愿望
- 人物模型如何看待数据的基本元素或单位。
研究数据仍是及其丰富的资源，运用这些数据来分析访谈对象，如何定义和描述构成对象使用模式一部分的事物和动作，以及对象使用的语言和语法。这里有需要寻找的问题：
- 访谈对象首先提到了什么？
- 使用了哪些动词？哪些名词？
- 在此过程中没有提及哪些中间步骤、任务或者物体？（这些事情对他们如何看待事物也许没那么重要。）
步骤4：构建情境场景
情境场景讲述的是某一个人物模型的故事，有着多样的动机、需求和目标，这个人物模型以自己最典型的方式，使用产品的未来版本。情境场景展现了人物模型使用场景，包括了环境和组织考量。
设计由此开始。开发情境场景时，重点是如何才能使设计的产品最有效地帮助人物模型实现目标。情境场景建立在一天或者其他有意义的一段时间中名主要和次要人物模型与系统之间（或其他人物模型之间）的主要接触点。
情境场景应该范围广而浅，不应该描述产品或者交互的细节，而应该从用户的角度专注于高层次的动作。重要的是首先制定出宏观轮廓，系统地找出用户需求。只有这样才能设计合适的交互动作和界面。
情境场景解决了以下问题：
- 产品在什么背景下使用？
- 是否会被超时使用？
- 人物模型是否经常被打断？
- 是否有多个用户使用单个工作站或设备？
- 与其他产品一起使用吗？
- 人物模型要达到目标需要执行的首要活动是什么？
- 使用产品预期的最终结果是什么？
- 根据人物模型的技能和使用频率，允许的复杂程度有多大？
情境场景不应该像当前一样代表产品行为。重点是解决人物模型的目标。最初要把设计当成有某种黑科技的黑盒子。
多数情况下，可能不只需要一个情境场景。一个主要人物模型也可能有两个或者多个不同的使用场景。
场景也完全由文字构成，仅仅讨论用户和系统的行为。“怎么做”的问题留到后面的改进阶段。
需要注意的是这里的场景还是处于较高的层次，没有涉及太具体的界面和技术。在这一阶段，现实中的细节内容不是太重要。我们希望为真正的创新方案留有余地，总能缩减。我们最终是为了描述一个最佳且可行的体验。同样要注意，场景中的活动是如何与人物模型的目标联系起来，尽量去除不必要的任务。
假装这是魔法
开发场景早期阶段的一个强大的工具就是，假装界面就是魔法。如果人物模型有目标，产品有魔法来满足目标人物模型，设计交互会多简单？这种思考方式有助于设计师跳出框架看问题。找出创意方法，用技术尽可能贴近魔法解决方案（从人物模型的角度来看）的交互。产品以最少的骚扰完成目标，在用户看来几乎就是魔法。提供魔法的目标导向的行为，而不仅仅是技术。
设计原则：设计的早期阶段，假定界面是魔法
步骤5：明确设计需求
在对情境场景初稿满意后，可以分析草稿，提炼出人物模型的需要或设计需求。这些设计需求包括对象、动作和情境。切记，我们不倾向于将需求等同于功能和任务。比如：
直接从预约（情境）中拨打电话（动作）给某个人（对象）。
如果你习惯于以这种方式提取需求，那很有效。要不然，分解成数据、功能和情景需求或许有用。
数据需求
人物模型的数据需求就是指必须在系统中呈现的对象和信息。数据需求可以被看成对象相关的宾语或形容词。
功能需求
功能需求对系统对象执行的操作或动作，通常会转换为界面控件，可以把功能当做产品的动作。功能需求也定义了界面中的对象或者信息必须显示在什么位置或容器中。
情景需求
情景需求描述了系统中对象之间的关系或依赖。这包括了系统中的对象必须显示在一起才能让工作流程变得有意义，或瞒住具体人物模型的目标。其他情境需求包括考虑使用产品的物理环境，以及使用产品的人物模型使用产品的能力。
其他需求
包括业务需求、品牌和体验需求、技术需求和顾客和合作伙伴需求等。
遵循这五个步骤你应该有了初略的创造性概览：产品如何以情境场景的形式解决用户目标，以及从研究、人物模型及场景在提取要求和需求构成简表。这些设计需求不仅指明了设计和研发的方向，还能提供与利益相关者交流的工作范围。从这一点起，以后出现任何新的设计需求都会改变工作的范围。
接下来就可以开始进行交互框架的搭建了。
