1、什么是业务场景？
什么是场景？
场景经常出现在电影里，由人物、时间、地点/环境、意图组成的一个画面或片段。
什么是业务场景？
商业体系下的人物、时间、空间、目标组成的一个“片段”。场景的描述：什么人，在什么时间，在什么环境/情景下，做什么事，来达成什么目的。
业务场景有大也有小，如下图：第一行是主要业务场景，下面的子模块是细分业务场景。
业务场景的每个要素，都是设计时要考虑的。
基于人物的考虑：APP的老年模式、基于视障人群的语音模式。
基于时间的考虑：外卖APP，中午推荐午餐，晚上推荐晚餐。
基于环境的考虑：夜间模式。
2、为什么要梳理业务场景？
1）设计依据。
业务场景是设计的起点，动手画原型写文档之前，应该先梳理业务场景。没有基于场景的设计，就像空中楼阁，站不住脚，不能YY。尤其是B端产品，强依赖业务场景。C端产品还好，有可能你就是用户，清楚场景。
2）完整性。
梳理业务场景，需要调研、沟通、思考，不要闭门造车，如果你不是业务专家，业务一定会说出一些你想象不到的场景，跟业务一起梳理场景，可以让产品方案更完整。但是注意，跟业务梳理业务场景和需求就好了，千万别乱听他的方案，容易带沟里去。要会识别什么是场景、需求和方案。
3）差异化。
要在市场中形成核心竞争力，必须找到优于别人的解决方案，解决方案需要在场景中去找。
4）沟通。
开发一定会灵魂拷问，为什么要做这个功能？你的说出场景，且清楚这个场景的是低频还是高频，重要还是不重要，为什么重要。
3、如何梳理业务场景？
步骤：一听。听业务说。二问。问主流程、分支流程、异常情况。三确定。梳理流程，跟业务反讲一遍，确定流程。
基于业务流程梳理业务场景
怎么梳理业务流程？
主流程：角色+活动+分支，输出：泳道图。示例：
活动：每个活动都有一个流程，输出：活动图。
怎么梳理业务场景？
一个活动就是一个场景，对场景进行描述，从场景中找到需求。
具体包括：场景名称、描述、需求。识别出可以通过系统实现的需求，这部分就是设计的基础。示例：
输出：主业务流程图+场景清单，走查清单：
业务是否闭环？
场景是否覆盖完整？
有哪些可以精简的？
4、业务场景即用例
业务场景进一步结构化和系统化，就是用例，可以说业务场景≈用例。业务场景是用例的前置。业务场景不用考虑系统实现细节，用例需要考虑一部分。
用例的关键要素：
名称：用例的名称
描述：用户通过系统，达成什么目标/解决什么问题
参与者（角色）：哪个角色
前置条件：执行用例的前置条件，比如登录、会员等级达到制定条件。
后置条件：执行用例完成后，系统的变更，比如状态流转，数据变更等。
主事件流（主业务流程）：正常情况下和系统的交互流程
备选事件流（分支异常流程）：异常情况下系统的处理逻辑
规则：系统根据什么业务规则执行判断
示例：
写在最后
什么是业务场景？业务场景是对某个业务“片段”的描述
为什么要梳理业务场景？1、让设计有据可依。2、保证方案完整。3、差异化核心。4、方便沟通。
怎么梳理业务场景？一问二听三确认。先梳理业务流程，再形成场景清单。
业务场景≈用例。只是梳理用例的时候需要考虑系统方案。
