场景化重视用户体验感受，以用户为中心进行产品设计，强调产品能够准确地匹配用户真实的业务场景和使用场景，匹配组织中不同分工的业务角色。本文分享场景是如何驱动用户体验设计的，一起来看看。
适合阅读对象：用户体验设计师、交互设计师、产品经理
适用产品范围：B端产品、SaaS、ERP、业财一体化
场景化所表达的理念即是以用户为中心的产品设计思想，强调产品能够准确地匹配用户真实的业务场景和使用场景，匹配组织中不同分工的业务角色。
在产品需求分析阶段，会开展以用户为视角的用户调研，结合产品经理的分析，大量沉淀为设计资产的设计经验等，提炼和分析若干个贴近用户真实使用时的场景。这些场景是体验设计的基础，也是 B端产品体验设计事实上的起点。场景公式，如下：
场景=什么类型的用户（Who）在什么时间（When） 什么地点（Where），因为察觉到什么事物（What）而产生什么需求（What Needs），并能够通过什么行为（How to act）来满足这种需求。
常见的场景来源有 2 大类：
具体来源又包括：现场调研、需求文档、竞品分析、经验沉淀、创新设计等。以此来进行场景的提炼，如角色分析、情景分析，例举出：场景一、场景二、场景三……
现场研究更能理解和准确洞察用户的场景。体验动计师一定要深入现场，实地观察和学习，真正理解用户如何执行一个任务， 完成一项业务目标。
举个工作中实际业务场景例子：
公司的业财系统经常会涉及到打印。在实际工作场景中经常会出现，放错业务单据配套的专业打印纸，导致打印错误。关于这个场景，实施经理的第一反应是应该通过帮助系统、培训等方式了解业务，针对不同的打印任务正确选择对应的打印纸张。
用户体验部门得知后，根据真实打印场景提出了设计的改进方案，在系统界面上明确地提示打印纸的类型，或者在打印纸上明确区分（颜色）。改进设计后防止了放错专业打印纸的情况，从而极大的降低了打印错误。通过简单的系统改进，带来工作效率的极大提升。
顶层设计的抽象场景，一方面可以对各级需求文档、产品文档中的细化需求进行场景化的描述和转化（文档中的很多内容来源于对真实用户场景的提炼）。另一方面，大量 B 端场景的历史积累都能支持场景的有效分析与设计（包括多年的产品和设计经验，相应的业务领域知识、模型及理论等)。
在新技术、 新管理思维的驱动下，创新服务无法用传统的场景来准确描述和设计， 必须在理解现有业务场景的基础上，大胆地进行创新场景的设计，并交由用户和市场来验证和检验，再做调整，最终逐步形成相对成熟的场景设计方案。
在具体的设计过程中，我们通常会把需求文档、流程图、抽象和复杂的业务描述，提炼成一些重要的公共场景或具体业务场景，把这些场景用图和文字进行说明。这些带有具体的角色人员、具体的工作和操作目标的信息，可以让所有参与者真正理解业务，真正理解产品要在一个业务场景中所发挥的作用。
真实的 B端业务场景是多种多样的。从业务场景角度出发，有项目管理的作业场景、日常办公场景、差旅场景、采购场景、及特定的专业领域场景等，而这些都需要结合具体的产品、业务、用户等来综合判断与分析。
在实际的工作中，通常通过以下一些简单原则，来梳理和定义核心的业务场景，作为判断和后续划分的依据：
B端产品是围绕业务做设计的，所以高频业务场景是选取场景中最重要的。
一般来说，除非是非常庞大的业务系统，否则有代表性的、高频的业务场不会特别多。比如，一个传统的财务系统，财务人员的高频业务场景就是录入凭证（会计最常用的凭证界面，如下图)，而财务总监高频业务场景就是审核与校对财务数据，及时地分析公司的财务状況和潜在风险。而一些高管人员的高频业务场景可能就是查看三大报表，了解公司的整体经营情况等。
而在一个采购场景中，当需要采购一些物资的时候，其中一个高频业务场景就是填写采购订单（采购员最常使用的采购订单界面下图）， 并由采购员把这些采购需求转化成采购订单，并通过各种方式找到合适的供应商。
所以，这些核心业务系统的核心功能被设计用来解决用户的核心问题，也就对应和映射着一个个高频业务场景，这也是场景选取中最为重要和关键的部分。
公共模块场景主要指一些看似与核心业务并不直接相关，甚至并不具备太多业务特征的场景，如登录、注册、列表、高级参照等。这些场景对应的功能会被很多模块共同使用。这些公共模块配合不同的业 务，可能还会延展和组合出很多细分的场景。
一般情况下公共模块场景可以做得非常标准化，从而被其他服务共同使用，但也要结合具体的业务场景进行动态调整和配置。研发会有专门的开发团队来负责公共的、可被复用的能力与服务的打造。
主流程场景实际上就代表了最为核心的业务场景及相关的组合，是用户完成一个完整核心业务相对完整的流程，这些流程会关联一个或多个场景。主流程场景强调的是业务闭环的严谨性、流程性和完整性，也是为了降低场景化描述过程中对于需求表达丢失和不完善的风险。
在这些主流程相关的场最中，我们容易遗忘一些关键细分场景的描述。以采购场景为例，“业务人员填写请购单”“采购员生成采购单”，这两个场景构成了某企业核心部分的采购主流程。但是在这个场景中，可能还有着比较重要的业务人员与采购员围绕采购需求进行细化沟通、讨论的过程。所以我们强调在主流程场景的设计中，要弥补高频业务场景和公共模块场景容易疏忽的内容。
一个企业或组织的最高决策层，往往不能代表使用产品数量最多的用户，但却是最重要的用户。他们往往对一个产品是否成功有着最直接的审判权，对是否使用一款产品有最终的决定权。
在C端产品的设计中，如果能 “取悦〞80%的目标用户，相信这将是一个非常成功的产品。而在B端产品的设计中，应该满足 20%特定用户的需求，同时兼顾其他用户。 特定角色的业务场景和使用场景的选择一定要充分重视。
很多业务系统的审批模块、高管决策看板等，都是一些特定角色工作中所涉及的业务场景。很多大型企业和组织在选型一款产品时，相关的采购负责人及相应的业务负责人，一定会关注这块产品向决策层提供了什么样的服务与能力。
在场景的选取和设定中，涉及场景划分的颗粒度大小。场景划分过大，不利于理解，容易丢失细节；场景划分过小，一个细节约等于一个场景，又太碎片化，失去了场景本来的作用。
因此，在做场景分析时，要根据业务系统的规模和复杂度来分析。 可以先划出一些核心的大场景，在这些场景上再适度地进行细分。这些细分场景，应该有比较合理的颗粒度和场景单元。
通过已经“场景化”的需求来辅助设计是非常有效的方法。有了这些场景，才能够具象地理解需求，同时也可以在一定程度上判断场景的合理性。
在梳理和提炼场景时，把一个功能模块直接映射为一个场景是常见的误区。这种方式简单地用功能介绍代替对整个场景细致的、具象化的描述， 缺乏对真实用户的使用情况的具象化表达和分析。
描述一个场景，本质上是以某种代入感的形式，使应用场景的人产生强烈的参与感，从而理解真实用户使用产品完成一个任务目标的真实感觉， 产生同理心。
在实际工作中，只有贴近用户，不断与用户互动的场景才是我们需要的。
本文由 @忻芸 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。