5.1 场景的划分与来源

在产品设计相关的领域，“场景化”已经不是什么新鲜词汇，很多产品在宣传时也经常用场景化来作为卖点，可见其价值。本质上说，场景化所表达的理念即是以用户为中心的产品设计思想，强调产品能够准确地匹配用户真实的业务场景和使用场景，匹配组织中不同分工的业务角色。场景从何而来，如何提炼和分析，又如何真正融入产品的设计过程，并不是一蹴而就的事情。

在产品需求分析阶段，会开展以用户为视角的用户调研，结合产品经理的分析，大量沉淀为设计资产的设计经验等，提炼和分析若干个贴近用户真实使用时的场景。这些场景将作为设计早期的核心“需求”，是体验设计的基础，有时候也会认为是B端产品体验设计事实上的起点。

5.1.1 场景的划分原则

在具体的设计过程中，我们希望把枯燥和难懂的流程图、抽象和复杂的业务描述，提炼成一些重要的公共场景，把这些场景用图和文字进行说明。这些带有具体的角色人员，具体的工作和操作目标的信息，可以让所有参与者真正理解业务，真正理解产品要在一个业务场景中所发挥的作用。

真实的B端业务场景是多种多样的。从业务场景角度出发，有工程类的现场作业场景、日常办公场景、差旅场景、特定的专业领域场景等，而这些都需要结合具体的产品、业务、用户等来综合判断与分析。如何从复杂的场景中来梳理和定义核心的业务场景呢？可以通过以下一些简单原则，作为判断和后续划分的依据：

（1）高频业务

（2）公共模块

（3）主流程

（4）特定角色

（5）细分场景

1.高频业务

B端产品是围绕业务做设计的，所以高频业务场景是选取的重中之重。一般来说，除非是非常庞大的业务系统，否则有代表性的、高频的业务场景往往也不会特别多。比如，一个传统的财务系统，很多财务人员的一个高频业务场景就是录入凭证（会计最常用的凭证界面如图5.1所示），而财务总监的一个高频业务场景就是审核与校对财务数据，及时地分析公司的财务状况和潜在风险。而一些高管人员的高频业务场景可能就是查看三大报表，了解公司的整体经营情况等。特别要提一下，随着新的智能财务服务的发展，“业财一体化”的深入，很多传统手工录入凭证的场景正在消失。在很多组织，这样的场景虽然还未完全消失，但已经从一个高频场景变成一个辅助的场景。而高管人员也开始通过实时在线的财务分析数据来进行业务决策，而不是按月、按年才能看到一些“不及时”的财务数据。

而在一个采购场景中，当需要采购一些物资的时候，其中一个高频业务场景就是填写采购订单（采购员最常使用的采购订单界面如图5.2所示），并由采购员把这些采购需求转化成采购订单，并通过寻源等方式找到合适的供应商。所以，这些核心业务系统的核心功能被设计用来解决用户的核心问题，也就对应和映射着一个个高频业务场景，这也是场景选取中最为重要和关键的部分。

在B端产品设计中，要面临的一个大的挑战，就是业务的多样性以及非标准化。就如同财务和采购这样相对标准化的场景，也由于组织的类型及规模、行业特点、管理方式等的不同，有着很大的差异。这个也是现实中无法避免和回避的问题。面向大型组织，有时候很难提供非常标准化的解决方案，原因也在此。所以，现在比较流行的赋能型的业务中台等概念，在一定程度上也是为了应对这些个性化的场景需求和特点。

2.公共模块

公共模块场景主要指一些看似与核心业务并不直接相关，甚至并不具备太多业务特征的场景，如登录、注册等。但是，这些场景对应的功能会被很多模块共同使用，或者说这些场景本身就是那些高频业务场景的一部分。

登录、注册等场景是比较容易理解的公共模块场景，还有一些相对容易忽略的公共模块场景，实际上又非常重要。这些公共模块配合不同的业务，可能还会延展和组合出很多细分的场景。比如，在很多业务场景中，都需要有打印能力的支撑，围绕打印就有很多细分的场景。在后面的设计模式介绍中，有专门的章节来介绍打印。又比如，在很多金融业务系统中，都有围绕客户进行身份识别的一个公共模块场景。通过银行卡、账号信息、生物识别等方式对客户进行身份识别与认证，就是一个公共模块场景。

这些看上去业务化不明显的公共模块场景，又非常重要和高频，在选取时，不应当被忽略。

一般情况下公共模块场景可以做得非常标准化，从而被其他服务共同使用，但也要结合具体的业务场景进行动态调整和配置。在很多大型的开发组织中，会有专门的开发团队来负责公共的、可被复用的能力与服务的打造。实际上这些标准化的公共模块，很多时候就是通过相应场景来分析和确认的。

3.主流程

主流程场景实际上就代表了最为核心的业务场景及相关的组合。一般来说，如果高频业务场景选取得当，主流程场景一般不容易被忽略，两者有很多重合的部分。核心的问题还是要去描述和理解什么是主流程。前文描述了很多业务场景的例子，这些场景本身就覆盖了全部或者部分主流程。主流程是用户完成一个完整核心业务相对完整的流程，这些流程会关联一个或多个场景。

但是，在这些主流程相关的场景中，我们容易遗忘一些关键细分场景的描述。以采购场景为例，“业务人员填写请购单”“采购员生成采购单”，这两个场景构成了某企业核心部分的采购主流程。但是在这个场景中，可能还蕴含着比较重要的业务人员与采购员围绕采购需求进行细化沟通、讨论的过程，而这个过程可能对应了一个非常重要的、无法被忽略的功能。所以我们强调在主流程场景的设计中，要弥补高频业务场景和公共模块场景容易疏忽的内容。

主流程场景强调的是业务闭环的严谨性、流程性和完整性，也是为了降低场景化描述过程中对于需求表达丢失和不完善的风险。毕竟，传统的需求文档虽然过于复杂，但是其数据和信息的表达往往是非常完备的。对于主流程场景的分析也是为了弥补这种不足。

4.特定角色

很多B端产品设计师，应该都调侃过“以老板为中心”而不是“以用户为中心”的设计。这句话虽然是调侃，但也是很多B端产品发展的真实现状。一个企业或组织的最高决策层，往往不能代表使用产品数量最多的用户，但却是最重要的用户。他们往往对一个产品是否成功有着最直接的审判权，对是否使用一款产品有最终的决定权。如果没能满足这些特定角色的业务场景，对于产品在市场上的成功是非常不利的。这也是在B端产品的讨论中经常提到的B端用户的多样性。在C端产品的设计中，如果能“取悦”80%的目标用户，相信这将是一个非常成功的产品。而在B端产品的设计中，应该满足20%特定用户的需求，同时兼顾其他用户。

特定角色的业务场景和使用场景的选择一定要充分重视。很多业务系统的审批模块、高管决策看板等，都是一些特定角色工作中所涉及的业务场景。很多大型企业和组织在选型一款产品时，相关的采购负责人及相应的业务负责人，一定会关注这块产品向决策层提供了什么样的服务与能力。

5.细分场景

在场景的选取和设定中，涉及场景划分的颗粒度大小。场景划分过大，则不利于具象化的理解，容易导致场景过于宽泛而丢失细节。而如果场景划分过小，则容易变成每一个细节功能约等于一个场景，过于碎片化，失去了场景本来的作用，无法支撑一个完整的业务流程。

在实际应用过程中，具体还是要根据业务系统的规模和复杂度来分析。可以先划出一些核心的大场景，在这些场景上再适度地进行细分。这些细分场景，应该有比较合理的颗粒度和场景单元，类似于测试过程中的测试用例。有的时候我们也借用“片段”的概念来代替细分场景的概念，即一系列片段组成一个完整场景。

场景的划分原则不是必须严格遵守和执行的，只是提供了一些场景分析的维度来帮助大家高效地提取和提炼目标场景。无论如何分类，通过已经“场景化”的需求来真正启动产品的设计过程，是非常有效的方法。有了这些场景，才能够具象地理解需求，同时也可以在一定程度上判断场景的合理性。

5.1.2 场景的来源

在梳理和提炼场景时，把一个功能模块直接映射为一个场景是常见的误区。这种方式简单地用功能介绍代替对整个场景细致的、具象化的描述，缺乏对真实用户的使用情况的具象化表达和分析，最后失去场景真正的价值。

描述一个场景，本质上是以某种代入感的形式，使应用场景的人产生强烈的参与感，从而理解真实用户使用产品完成一个任务目标的真实感觉，产生相应的同理心。这也是产品设计中设计师较高境界的追求。

有效场景的来源有很多渠道，只有贴近用户，不断与用户互动的场景才是我们需要的，否则场景就是空谈，就是形式主义，就是闭门造车。如果要打造一个标准化的产品，则需要在各种复杂的B端场景的基础上，做足够的抽象化处理。这也是最为考验产品人的地方。

1.基于现场研究，从下而上

既然是场景，更能理解和准确洞察用户的场景就是现场研究。体验设计师一定要深入现场，实地观察和学习，真正理解用户如何执行一个任务，完成一项业务目标。

1）用来洗水果的洗衣机

某知名洗衣机品牌的洗衣机，质量口碑一直非常好，但在进入一个新兴市场后，经常出现质量问题，而在其他地区则没有类似的问题。厂家在现场调研后发现，当地很多水果摊位用洗衣机来清洗各种热带水果。这次调研不仅发现了问题，还发现了新的商机。这就是一个典型的场景调研，产品与目标用户的真实场景并不相符，但用户又发明了一种基于一个产品的创新场景应用。很多时候，这些场景就是产品创新的催化剂。

2）银行柜员打印的烦恼

某银行工作人员在使用某个业务系统时，在打印（套打）环节，经常放错业务单据配套的专业打印纸，导致打印错误。关于这个场景，项目经理的第一反应是用户应该通过帮助系统、培训等方式了解业务，针对不同的打印任务正确选择对应的打印纸张。但是，银行工作人员根据真实场景，反而向项目组提出了设计的改进方案，在系统界面上明确地提示打印纸的类型，或者在打印纸上明确区分（颜色）。

在B端产品设计中，这种思维是比较常见的。大家经常认为专业的工具应该通过培训、学习来掌握，而经常忽视用户体验方面的优化空间。其实，不复杂的场景，简单的系统改进，会带来工作效率的极大提升，也直接提升了产品的体验。

2.基于顶层设计的抽象场景，从上而下

顶层设计的抽象场景，一方面可以对各级需求文档、产品文档中的细化需求进行场景化的描述和转化（文档中的很多内容来源于对真实用户场景的提炼）。另一方面，大量B端场景的历史积累都能支持场景的有效分析与设计（包括多年的产品和设计经验，相应的业务领域知识、模型及理论等）。

在一些云服务中，利用人工智能技术，很多服务实现了后台化、智能化、自动化的运转，整个过程已经不需要人工的过度干预。而在新技术、新管理思维的驱动下，创新服务无法用传统的场景来准确描述和设计，必须在理解现有业务场景的基础上，大胆地进行创新场景的设计，并交由用户和市场来验证和检验，再做调整，最终逐步形成相对成熟的场景设计方案。