一个 H5 活动带来的反思：流程设计是关键

基本上所有的功能设计的流程都可以大概用这张PPT来进行简要的概括...

真的可谓是“纸上得来终觉浅，绝知此事要躬行”…产品直接相关的、间接相关的书籍看了很多，产品相关的课程视频也看了不少，BRD、MRD、PRD也都接触过、写过，方法论上基本正确，大道理也能够讲的头头是道。然而，真的是去落地实践的时候，却还是会出现一些问题，最近在策划公司的一个H5的抽奖活动，有感而发，想梳理整理出来一些东西…

一. 活动背景

本周被分配了一个任务，进行一个H5的抽奖活动的方案策划，H5页面在App内被打开，可以分享至微信好友或者朋友圈。这个H5的抽奖活动是在公司的内部进行抽奖的。

活动采用九宫格的形式，单人每天的参与次数有最大限制，可以分享至微信好友和朋友圈获得好友助力，当有好友通过微信分享的链接进行抽奖后，原链接分享者获得一次额外的抽奖机会。

二. 活动策划

当时拿到这个项目的时候，需求的颗粒度很粗，大概就约等于做一个九宫格的抽奖方案，可以分享至微信进行好友助力。并且需求还是二手的需求，所以在接下来的活动策划中给自己挖了很多的坑，一是需求的来源并不详细，二是不明确需要交付的产出物是具体什么样子，三是自己之前并没有接触过H5的抽奖活动，于是我只能按照自己的理解的流程来进行拆解。

1活动目的分析

目标-问题-方案，这应该是遇事正确的打开方式，首先要明确想达成的目标是什么，紧紧围绕着目标，不要跑偏了，其次是我现在遇到的问题是什么，限制因素是什么，根据现有的资源和限制条件，想办法找到可以达成目标的解决方案。 在拿到这个小项目的时候，我就在考虑这个活动的目标是什么，为什么要做这个活动，为什么要分享至微信，而且仅仅只支持分享至微信，在想清楚这些问题之后，我就开始着手去梳理整个活动的流程。

2流程梳理

整个抽奖的流程可以分为两部分，一部分是从App内打开的流程，一部分是从分享至微信中的链接打开的，而从微信中的链接打开时，又分为打开自己分享的链接以及打开别人分享的链接。

打开别人分享的链接时需要进行工号验证，此时又分为工号验证与工号未验证的情况，工号验证之后又可能存在App账户已注册和未注册两种情况…下图为简单的活动流程示意图：

虽说只是一个简单的H5抽奖活动，但是需要考虑的东西其实挺多的，正常的流程是抽奖，然后是中奖或者不中奖，之后可以选择分享至微信或者不分享，对于用户而言一次任务已经结束。

但是这仅仅只是一些正常的流程，还有很多异常流程需要考虑，比如抽奖已达最大抽奖次数、当日没有抽奖机会、用户未安装App，如何引导去下载，怎么区分iOS与安卓…

3产出功能清单

考虑了好久之后，总算是把整个分支流程和异常流程考虑清楚了，评审通过之后就开始进行活动的功能清单的整理，由于活动是需要能够进行模板复用的，需要在后台加入一个活动管理的功能，进行抽奖活动的上下线管理以及其他的一些操作，所以功能清单上也就分为客户端和后台两部分来写。

4产出线框图

把流程和功能清单都梳理清楚之后，就开始进行低保真的线框图的绘制了，由于之前没有进行过H5的活动策划，于是就去找了有五六个抽奖活动的H5页面，体验了一段时间这些H5活动之后才进行线框图的绘制。

5产出设计稿

我们的设计还是很给力的，虽然中间遇到了需求的变更，新增了一些需求，设计还是很快的产出了设计稿。

6开发测试

还没有进入开发阶段，问题还没有暴露出来…

三. 活动反思

在活动策划的整个流程中，是按照之前自己学到的方法论去实现的，整体上没有出现什么大的问题，但是一些小问题还是有的，针对出现的一些问题，反思如下：

1整体流程

基本上所有的功能设计的流程都可以大概用这张PPT来进行简要的概括：

在功能设计的前期需要进行需求的收集和需求的分析，将合理的需求转换为产品的需求，经过需求评审之后确定需求的优先级、实现难度、开发排期等...

经过这些流程之后才是设计阶段，产品原型经过评审之后会产出视觉稿，之后是开发测试、上线运营，然后根据上线之后得到的反馈来进行优化改进。 在设计阶段首先需要梳理清楚整个流程，可以通过流程图和用例图来进行梳理，确定整个系统中会有哪些个角色，系统的边界是什么，不同角色之间有什么样的权限区分，不同的角色之间的关系和流转是怎样的。

梳理清楚整个流程之后是产品整体结构的梳理，一个是逻辑上的结构，更接近于产品结构，一个是物理上的结构，即页面结构，不同的页面之间如何实现跳转，梳理清楚这些角色、流程与结构之后才是具体的原型的设计。

2沟通、沟通、沟通

在项目的进行中，沟通真的是非常非常大的问题啊，可能是沟通不充分，沟了但没通，可能是在沟通中出现了偏差，导致理解上出现了问题，也可能是后期的跟进上存在问题。

在沟通中，能当面沟通的就不要打电话，能打电话的就不要用IM，能用IM的就不要用邮件去沟通，重要的事情需要邮件确认的除外。 在项目的前期就需要能够和各项目干系人进行充分的沟通，以求能够达成共识，能够确定好里程碑事件，当有什么不清楚的问题或者需求发生变动的时候，需要及时通知各项目干系人，纠偏越早越好。

在项目中，则需要能够定时的进行沟通汇报，明确项目的进度、存在的问题、接下来的打算等，需要能够不断地对项目进行跟进。

3需求变更

这是一个很头疼的问题，可能会拉仇恨，可能会让团队成员的劳动成果进行返工，也可能会造成严重后果的问题，但是又不得不去面对的问题。

既然很难避免，那就在最开始考虑问题的时候，尝试着尽可能的去考虑清楚，如果迫不得已要进行需求变更的话，最好尽快通知各项目干系人，并且最好能够给出他们一个合理的解释，不然很容易就会失去团队成员的信任。

4owner 意识

最开始我对这个并没有什么观念，后来慢慢的觉得作为一个产品人，产品经理也好、产品助理也罢，都需要对这个产品负责，也许你只参与了这个产品中的某一个模块。但是对于这个模块来说，你就是这个模块的产品经理，你需要对模块负责，你需要想办法去协调资源，去沟通、去跟进、去保证产出，并且不断的去优化迭代。 以上就是这篇文章的主要内容，欢迎斧正、指点、拍砖…

关于我：王家郴，喜欢网球和骑行的产品汪。公众号（产品经理从0到1），每周都会在公众号上写点东西，欢迎关注,求指教、求分享、求交流。目前奔走在产品的道路上，漫漫产品路，与君共勉。

关键字：流程设计, 产品经理, 流程

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！