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