产品经理，原型设计之前你要做些什么？

也许我们经常会碰到这么一副画面：很多产品经理在梳理好了产品架构的脑图之后，都会火急火燎打开原型设计工具Axure，开始进行原型设计工作去了。三下五除二就基本将产品线框图给画完了，然后就屁颠屁颠地跑去和研发工程师过需求，讨论的时候会发现：不是这里有个小问题，就是那里有个逻辑没想明白，整理整理返工，结果下一次又发现有一个流程没有考虑清楚，这样来回反复几次才能将一个产品需求和原型界面给讨论清楚。

其实，这样的场景出现的频率还比较高。想想自己第一次去和公司开发沟通的时候，也是碰到了这样的情况，被开发喷这里逻辑不对，那里漏了一种分支情况的思考，当时那个囧啊，真想找个地缝钻进去。后来才知道，在设计原型之前，其实还少了一个关键的步骤，那就是确定产品的业务流程，梳理产品的流程图。

从字面来理解，流程图＝流程＋图。流程，是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程；而图呢，就是将这些流程进行显性化和书面化的一种表达。

流程图有时也称作输入-输出图，某种程度上来说，流程图是一种沟通性质的图形化语言。一般会使用一些标准符号代表某些类型的动作，如判断用菱形框表示，具体的操作行为、活动用方框表示，开始和结束用圆角矩形框表示。

但比这些符号规定更重要的，是必须清楚地描述产品业务流程的顺序及使用逻辑。从产品经理的角度来理解，流程图其实就是一个用户使用产品的过程，基本的三要素是“从哪进—做什么—从哪走”。比如用户打开一个电商APP，会有这样一个使用产品的过程：

用户从电商商城的首页进入，通过搜索来找到自己想要购买的商品，了解后将其加入购物车，购买了自己想要的商品，支付结束后便离开APP，待收到商品后又回到APP进行确认收货。

可以看出，只要产品用户在使用我们产品的过程中有其自身的目标和任务，产品流程就会存在。产品经理要做的，就是通过一系列步骤完成任务和流程的梳理，最终目的是帮助用户，完成核心任务。

而且制作产品流程图不仅可以帮助产品经理梳理、完善用户操作使用流程，还能有效降低团队成员间的沟通成本。在实际的工作中，产品经理需要向很多人（尤其是开发人员）描述产品需求和原型界面，借助可视化的流程图，沟通的效率会提高很多，毕竟一份步骤清晰的流程图要比一大段文字直观易懂得多。

常见的流程图分类有两种，一种是业务流程图（Transaction Flow）, 一种是页面流程图（Page Flow）。

对于产品经理来说，用的比较多的自然是业务流程图，页面流程图一般是设计师那边使用比较频繁。在工作中，我们经常能够看到两种业务流程图，一种是单纯的用户操作行为流程图，这种流程图往往只涉及一种用户角色，不需要进行跨部门或者跨功能完成某项任务，如下图所示：

另一种则很好区分，俗称为“泳道图”，在样子上也挺像游泳池里的泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。泳道图是处理多角色、多系统、多模块的复杂需求的最好方法，它的本质就是希望可以通过角色、系统、模块的划分将复杂的功能梳理切割清晰，因此多模块之间的关联尽可能单一，实际中也很少存在多联系线条的情况，因此如果泳道之间多条关联，最好自己反思下是不是之前的功能模块架构切割的不太合理，导致绘制出来的图不够简洁。

讲完了基础的东西，接下来我们来梳理下，该如何确定产品的流程。

首先我们要设计的是产品的核心功能流程，也就是用户的核心使用路径。拿微博进行举例，微博用户的核心操作路径是这样的：

• 路径一：登录微博——查看微博动态－－转发、点赞、评论微博
• 路径二：登录微博－－发表自己的微博－－查看私信，回复微博评论

这是微博用户最常有的两种操作行为，所以你会发现：所谓产品的核心功能流程，就是一个产品对用户产生的价值，用户要感知到这个价值需要完成的最简操作步骤。微博这个产品对用户来说，最大的价值无非就是两个方面，一个是可以碎片化地浏览资讯，一个是可以碎片化地发表自己的动态信息。用户要感知到这两个价值，就必然要做出上述的一系列操作流程和步骤。

所以，在确定产品的主干流程的时候，需要先弄清楚产品的价值到底体现在哪里，用户要完成对这个产品价值的感知，需要付出哪些行为。通过这样一个简单的分析，我们就能得出产品的主流程了。

当然，这里输出的产品主流程，只是一个产品的整体使用流程，具体到某一个功能如何进行操作使用，就需要花费更多的精力去进行细化分解。

那对于某个功能的产品操作流程梳理，我们又具体怎么来做呢？

1. 业务调研

如果你是在梳理一个简单的功能操作流程，或者已经比较通用成熟的产品流程，那么只需要好好研究几款产品，就可以知道常规的流程是什么样的，典型如产品的注册登录流程；但如果是梳理一个全新的业务功能流程，尤其是设计企业内部支撑系统的时候，就需要对相关业务进行系统的调研了。

其实调研的过程，倒是和我们小时候写记叙文有点相似，无非就是要解决who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？基本上只要我们深入到业务环境里去，和业务相关人员好好沟通交流，搞明白这几个问题也不是什么难事。然后把调研结果做一个完整记录，我们的调研就可以算是圆满完成了。

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!