一次流程图设计的思考

暑假即将来临，我们的游戏也开始准备运营活动的设计，目的是提高游戏的活跃，这里我们设计了一个登录的活动，在执行的过程中，我在给我们的程序员画流程图，突然冒出了一些想法，在这里写出来并分享给大家，也欢迎大家提出自己的想法

先来说活动方案

活动时间：7月4日-7月15日

活动详情：

1. 活动期间累计登录3天，获得奖品A
2. 活动期间累计登录5天，获得奖品B
3. 活动期间累计8天，获得奖品C

这是一个很简单的一个运营活动，在页面设计上，我们设计了3个按钮，以便玩家可以去分别点击领取。

下面是流程图第一个版本

第1个流程图思路其实很简单，按照玩家在页面上的操作行为来画流程图，然后把所有的可能性操作都写上去。

下面这个是流程图的第二个版本

前提：

第2种流程图，根据活动方案，把用户类型分为4类：

1. 3种奖励都不能领取类型
2. 只能领取第1档次奖励的类型，即为A类型
3. 能领取第1档次和第2档次奖励的类型，即为B类型
4. 能领取第1档次和第2档次，第3档次的类型，即为C类型

第2种流程图的思路是先把用户类型分类，按照用户类型来画流程图，即如上图，我们把可能的用户类型划分出来，然后根据这些用户类型的操作来画流程图

关于这2个形式的思路，我咨询过我们的开发人员，问他们更乐于接受哪一种？

回答：虽然两者看起来本质上没有区别，但是第1种思维上看比较饱满，考虑的可能性较全。第2种思维则更便于我们理解，即用户的操作流程很清晰。

其实在我的理解来看，第1种流程图的思维是我们经常使用的，第2种则是从用户角度来触发，这就有点像产品设计中我们经常说的用户使用场景，详细的描述就是：A类型用户，在完成任务后（达到登录3天），然后来到页面上准备去领取他们的奖品。这样整个用户使用场景就构成了，他包括 什么样的用户，在什么时间，在什么样环境下去使用这个产品的什么功能，然后解决了什么需求，简单的来说就是包含了who、where、what3个点。

在写需求文档的时候，可能我们更应该要去描述用户的使用场景，而不是单纯的去写一个流程，这样子我们的开发人员更能理解我们的需求，也便于我们沟通。

欢迎大家针对上面的观点和看法与我交流。

本文由 @Tracy1Kidd（微信公众号：Breakmind）原创投稿，并经人人都是产品经理编辑。未经许可，禁止转载。