在产品设计阶段，为了更准确地理解与描述业务需求，我们可以将各种需求文档进行场景化、具象化的设计与描述，并结合原型界面，形成生动的用户场景故事，以此完成场景化的需求建模。
这样的场景化需求建模，形成涵盖了角色、细分的业务场景以及相应原型界面，既保留了业务需求的准确性和完整性，又使得整个需求过程便于相关人员（如用户、工程师等）理解，使需求分析与设计过程之间的衔接更紧密，保证需求能够较为准确和高效地转化为设计。
场景化需求建模
以上简单的场景例子中，我们提炼出一个重要的场景，并把场景用图片和文字进行说明，这些带有具体的角色人员，具体的工作和操作目标的信息，可以让相关人员真正理解业务，真正理解产品要在一个业务场景中所发挥的作用。
场景的划分维度
真实的B端业务场景是多种多样的，从业务场景角度出发，有日常办公场景、外勤差旅场景、巡检场景、仓库拣货场景、特定的专业领域场景等等，而这些都需要结合具体的产品、业务、用户等来综合判断分析。如何从复杂的场景中梳理和定义核心的业务场景呢？可以通过以下常用的维度，来作为判断和划分场景的依据。
1.高频业务
B端产品是围绕业务而设计的，所以高频业务场景是场景化需求建模中的重中之重。一般来说，有代表性、高频的业务场景不会特别的多。比如一个财务系统中，很多财务人员的一个高频业务场景就是录入凭证，而财务总监的一个高频业务场景就是审核与校对财务数据，及时地分析公司的财务状况和潜在风险。
2.公共模块
公共模块场景主要是指一些与核心业务不直接相关，但这些场景相应的功能会被比较多的场景所使用的。比如登录、待办任务、消息通知、流程审批、打印、导出等。
一般这些公共模块场景可以高度标准化，可以在多个场景中被高度重用复用，但也要结合具体的业务场景进行适当的调整和配置。
3.主业务流程
主业务流程场景实际上就代表了最为核心的业务场景，通常主业务流程并不难识别，主业务流程是用户完成一个完整核心业务相对完整的流程，这些流程会关联一个或多个场景。
但是，在这些主业务流程的相关场景中，我们容易遗漏一些关键细分场景的描述。以采购场景为例，“业务人员填写请购单”、“采购员生成采购单”，这两个场景构成了某企业核心部分的采购主流程。但是这个场景中，可能还隐含着比较重要的过程——业务人员与采购员围绕采购需求进行细化沟通、讨论的过程，而这个过程可能对应了一些非常重要的功能。所以，我们要重视细化主业务流程中所涉及的场景。
4.特定角色
例如，B端产品中，不容忽略的关键决策用户（如老板）的业务场景，这类用户也许并不会高频使用产品，但因为其对项目有较大的权力和影响力。因此，如果没能满足这些特定角色的业务场景，对于产品来说是非常不利的。很多业务系统的审批模块、报表驾驶舱、辅助决策功能等，都是一些特定角色工作中所涉及的业务场景。特定角色的业务场景和使用场景的分析一定要充分重视。
场景的颗粒度
在划分场景时，设计场景的颗粒度大小。如果场景划分过大，就容易过于抽象而不利于具象化的理解，也容易丢失细节忽略具体交互体验。如果场景划分过小，则容易过于碎片化，场景琐碎、重复，一方面设计投入过大，另一方面粒度太细容易导致业务链关联不紧密，进而导致设计时缺乏对上下文的考虑，无法支撑一个完整的业务流程。
所以，在实际应用过程中，具体还是要根据业务系统的规模和复杂度来分析。可以先划分出一些核心的大场景，在这些场景上，再适度地进行细分。这些细分场景，应该有比较合理的颗粒度和场景单元，类似于测试过程中的测试用例。
场景的来源
场景化需求建模时，要避免直接根据功能模块来分析场景。这种方式简单地用功能描述代替对整个场景细致的、具象化的描述，缺乏对真实用户的使用情况调研，这是本末倒置的，自然也会失去场景的价值。
场景化需求建模的本质是通过图像、语言等方式，加强需求读者的代入感，从而理解真实用户使用产品完成一个任务目标的正式感受，产生相应的同理心。
场景的来源有很多，但本质的来源还是通过与用户互动获取，场景的有两种来源，一种是基于用户现场研究、自下而上的场景，一种是基于制度、专业领域资料等的顶层设计、自上而下的场景。
基于现场研究的具象场景，自下而上
为了更能理解和准确洞察用户的场景，最好的方式就是进行现场研究，也就是回到用户实际作业操作场景中，进行观察、访谈、文档分析等调研工作。深入现场，实地观察和交流，真正理解用户是如何执行一个任务，完成一项业务目标的。
基于顶层设计的抽象场景，自上而下
我们可以通过与老板、高管用户交流，或是通过标准制度、专业领域资料等来梳理顶层设计理念、方法，进而从更高维度理解业务场景，自上而下的好处是我们不仅能了解到场景是怎样的，更能了解到为什么会有这样的场景存在。
在很多传统行业的作业模式中，可能一些场景通过信息化、数字化后，直接就可以被替代掉了。自上而下的场景研究，往往更能判断出是否存在“伪场景、伪需求”。
场景的呈现
前面介绍了场景的划分维度、颗粒度、来源等，在这些基础上，我们再将场景落地成为具体的可视化呈现。
场景分析文档，我们可以使用PPT的格式进行呈现，便于图文等信息的汇总编排，而且通常可以结合昨天分享《B端产品：用户画像分析》中的用户画像卡片进行描述呈现。如果希望在用户体验上有更进一步的优化分析，还可以结合用户体验地图进行呈现（关于用户体验地图，日后有机会再分享）。
梳理和描述一个场景的时候，建议包含以下要素：
- 场景名称，结合维度、来源等，对场景进行简单明确的命名，便于相关人员沟通。
- 核心用户及相关角色的信息，最好能有用户画像分析描述。
- 用户的动机及行为，包含场景下基本的业务和工作目标、工作任务等。
- 产品使用过程中的相关空间、时间信息，如工作环境（如新楼盘工地等，则可能该场景容易出现弱网络或无网络的情况）、系统环境（如手机APP、办公室电脑等）、时间、地点等。
- 其他有助于准确描述场景的要素，比如采购场景中，采购员是如何与供应商进行初步询价的，通过电话？邮件？微信？等，如果通过邮件，那我们也许可以通过系统完成询价函件的模板编辑和发送，来为用户带来便利等。
综合这些要素，形成场景化需求建模文档，实际应用中，我们可以更灵活些，场景化需求建模的目的，就是要清晰明确的表示清楚场景，以保证需求能够较为准确和高效地被相关人员所理解。
建议的各个要素如下图中红框所示，供大家参考。
要素
希望今天的分享对大家有帮助，明天见。
网友评论