产品设计程序6个步骤

一、业务分析——要做什么（业务流程图）

几乎每一款产品都会对应一个或多个业务流程，它是对业务事件和不同角色间通过信息流动和交互方式的一种表达，对应的交付物就是业务流程图。

例如电商业务有订单生产流程图、有货物进仓出库流程图、也有资金流程图；外卖业务有接单业务流程图、派单业务流程图、订单流转流程图等。

做产品的第一步就是把业务分析清楚，弄明白要做什么，有哪些角色参与，业务交互节点是什么，信息流、资金流、物流等是如何流转的。

搞清了这些后，就可以绘制不同业务模块的流程图，对整个全局就比较清楚了。另外，我们所说的产品定位、产品路线图也包含在这个环节内。

二、产品分析——解决什么用户问题（User Story）

在完成业务分析并设计好业务流程之后，就可以进入产品分析的环节了，这部分的主要目的就是要明确下来是要解决什么用户问题。

具体就包含了目标用户、人群画像、需求定义、用户体验地图设计等。主要是从用户和产品的角度，通过一些工具把产品要解决的问题具象化表达出来。

例如具体的用户画像构建、需求分类（紧急重要、是否关键路径）、结合业务流程绘制用户情感体验地图等。

然后，在这一步需要定义 MVP（最小可行性产品）以及产品的关键路径（最小关键业务流程），并形成需求清单以及功能清单，排列好优先级。

除此之外，我们常说的竞品分析和用户调研也是在这一步完成，并交付相应的调研分析报告。

这一步的核心就是围绕“解决用户什么问题”来展开工作。

三、结构设计——构建产品骨架（信息架构、功能结构）

到第三步就比较具体了，就是我们常说的设计信息架构和功能结构，交付物就是树状结构的思维导图，这个大家应该都见过也做过。

但需要区别的是，信息架构和功能结构不是一回事，前者是描述产品的信息骨架。例如一个网站的结构包括哪几个部分，每部分具体包括哪些字段信息。这一步最好有技术同学介入。

后者是从使用 *** 作的角度来描述具体的功能结构，例如账户体系包括了注册和登录功能。

为什么需要这两张图呢？

信息架构有助于我们全局了解产品的信息脉络，尤其是对于一些复杂项目，比较利于进行模块化整合和分类。

而功能结构也能很清晰的告诉我们现在产品有哪些具体的大功能和子功能，有些能抽取出来合并同类项的就可以在技术层面做模块化整合。

到目前为止，我们还不会进入具体的原型绘制阶段。

虽然以上三步很重要，但很多人、很多团队其实都忽视了，出现的问题就是产品混乱，新人来了以后没有产品全景图，也不知从何下手。

涉及到历史功能调整时，也不清楚前期的架构和模块划分是如何设计的，牵一发动全身；就像一座大桥要拔掉一颗螺丝，但你不知道拔掉后整座桥会不会垮。

四、原型设计——产品怎么用（交互设计、功能设计）

这一步大家都很熟悉了，使用工具画原型、做交互设计，我也就不展开讲了。

需要特别说明的是，在小公司，功能设计和交互设计大概率就是产品经理一人完成了，而在大公司可能会有专门的交互设计团队。

例如我之前在京东时，具体的交互设计就是专门的 UED 团队来完成，产品经理更侧重需求定义和流程设计。

五、视觉设计——产品长什么样（设计师的工作）

视觉设计属于设计师的工作范畴了，产品经理可介入性不大，我一向主张专业的事交给专业的人做。

这一步产品经理要做的是什么呢，主要是向设计师描述产品使用场景以及用户特征，即产品在什么情况下被什么特征的用户来用。

对此，设计师可能会采取不同的布局设计和配色方案。

例如针对中老年的产品，在按钮大小和字体颜色上，可能需要更醒目一些，如果设计师不理解大背景和产品用户，可能会自己发挥，这样就会造成产品可用性不高。

当然，这里说的可用性不高是指在目标用户人群的可用性不高，但产品本身是可用的。

六、数据设计——验证什么（埋点、数据指标、监测策略）

我们可以说，大部分的产品都是基于先验的假设进行设计的，也就是说实际情况如何我们提前很难知道，那就需要通过数据区验证。

数据设计主要是基于第三步和第四部的成果进行具体验证项定义，并在产品功能上设计相应的数据埋点，以及数据回收和统计机制。

例如在电商产品的商品详情页，用户到底是点“直接购买”多，还是“加入购物车”多，那就在这两个按钮上进行数据埋点，然后统计一段时间内从这两个渠道产生的订单转化率。

如今已经进入精细化运营的时代，对应的，产品也进入了精细化设计的阶段，用科学的方式验证需求，用数据去证明设计，已经成了产品经理必备的技能之一。

要实现流程的“可配置”，即相当于由用户自己“组建”流程，那么，对于程序的开发者，要做的事自然就是一个相反的过程（“拆解”流程）。考虑如何拆解流程能使用户重新组建时省力省心，实际上就是设计一个好用的、可配置的工作流的过程。

清楚了我们要做的事之后，在开始做事之前，我们还需要制定一些做事的原则（“拆解”的原则和方向），毕竟，我们的初衷，不仅仅是能把事做完，把事情做好才是最终目标。那么，什么才是一个好用的可配置的工作流呢？我们认为，好的工作流应包含下面几个特点：组建过程简单、快速，易于维护，用户无需培训、易于掌握等。

制定了上述原则后，我们现在就开始来拆解流程了，首先画一个简单的流程图作为参考。

简单流程图

大致看一下图1中的流程图，先不考虑复杂的内容，我们对一个流程最直观的判断是：流程由环节和路径组成。如果仅将流程拆分成这两个元素，对用户来说是非常好理解的。那么下面，我们就尝试使用这两个元素建立可配置的流程。先粗略地拟一下各元素对应的表单需要包含的域：

1、环节文档：环节名称、处理人员

2、路径文档：路径起点环节名称、路径终点环节名称、流转条件

上面两个文档都是配置文档，要建立一个完整的工作流系统，除配置文档之外，我们还要建立一个包含待审批的业务信息的文档（以下称为主文档），主文档要与配置文档相关联，就需要在主文档中记录一些配置文档相关的信息，这里也先粗略地拟一下这些信息：

3、主文档：当前环节、当前用户

相关基础文档建立起来之后，接下来就开始考虑将各个分散的内容连接起来形成一个完整的工作“流”。假设当前主文档处于申请人环节，那么下一个环节是A领导还是B领导呢？从我们现有的配置文档来看，两个环节文档是通过路径文档连接的，那么我们首先要找到以申请人为起点的所有相关路径，搜索结果为：路径1、路径2、路径3都符合要求。接下来就是判断当前文档符合哪一个路径流转的条件即可筛选出唯一确定的一个路径。然后，从唯一确定的路径文档中可获得下一个环节的名称，通过下一个环节的名称搜索环节文档即可获得下一个环节的处理人员。将上述处理过程放大，就可以实现一个任意庞大的流程。

流程流转过程

看上去上面的方案似乎已经完全实现了一个“可配置”的流程，实际如何呢？下面，我们拿一个复杂一点的流程来分析这种方案的优缺点：

有重复环节和路径的流程图

可以看到，“B领导审核”环节和“会计”环节出现了2次，“B领导审核”到“会计”的路径也出现了两次，假设当前环节为“A领导审核”环节，如果通过上面的处理方式，我们搜索到的符合条件的下一个环节是“B领导环节”环节，然而，“B领导环节”以后有2个可能的路径，如果仍按上述方式处理，我们本来要走的路径5可能会走到路径6而导致流程最终无法流经“总经理”环节。为了避免这种情况，我们可以有很多种选择，下面列出了其中的两种：

第1种：将两个“B领导审核”环节命名为不同名称，如其中一个环节名称改为B领导审核2。

第2种：在环节文档中增加一个位置域，标志其所处位置以区别不同位置出现的同一个环节名称，即使用位置取代环节名称作为环节文档的关键字。

采用第1种方式虽然较“笨”，但是可以不修改我们原来的程序，而且流程的组建过程也是最简单的。但是有些用户可能不会接受这种方式，因为在这样的系统架构下，组建流程的管理员需要绞尽脑汁地考虑“第二名称”怎样命名，而且这个“第二名称”不一定会获得最终用户的认可。为了避免这些麻烦，我们可以采用第二种方式。

下面我们看看环节文档中增加了位置域的效果（图4）。采用“位置”域作为关键字，在主文档、路径文档也相应增加当前位置域即可以唯一确定流程的走向。

增加环节的位置信息

在环节文档中增加位置域的方法解决了环节名称重复的问题，但进一步看，我们仍需要为相同环节名称不同位置的两个环节建立两个环节文档，站在系统管理角度来说，这也是一种很不好的方式，因为调整这种重复环节文档中的任何信息（如：调整环节包含的人员）的时候都需要修改2个或者更多的文档（很可能改了一个忘了一个）。因此，我们有必要将环节名称的其他信息和位置信息再拆分，拆分后各文档包含的域有：

角色文档（职位文档）：角色名称、处理人员

环节文档：角色名称、位置

同时，为了配合这一改动，我们还需要将路径文档、主文档中当前的环节信息拆分成当前角色和位置：

路径文档：路径起点的位置、路径终点的位置

主文档：当前角色名称、当前位置、当前用户

解决了同一流程中重复环节的问题后，我们将流程继续扩展，接下来还将遇到不同流程使用同一环节，不同部门使用同一流程等问题。经过同样的分析过程，我们仍将面临为各种配置文档添加关键字域以区别不同情况或再次拆分成不同配置文档的情况。就像上面提到过的一样，选择添加域或者拆分各有有缺点，添加域可以维持程序的易用性，而拆分成不同文档可以减少系统中的重复配置，提高配置文档的可重用性和可维护性。易用性和可重用性这两个特性在大多数时候是一对矛盾体，如何取舍就全靠我们的系统设计人员把握了。我们这里采用的是以易用性为主，可重用性为辅的策略。图5显示了我们这种策略下的一种数据结构。

可配置的工作流的数据结构

刚才我们都是将流程不断扩大来细化我们的拆分方案，现在，我们将从另一个同样重要方向来继续这一过程，即流程环节的增、删、改。上面我们也曾提到过流程环节的“修改”（修改承办人员），一般情况下修改环节都不是问题，难点的在于增加和删除环节。下面我们尝试在“A领导审核”环节和“B领导审核”之间增加一个“C领导审核”，看看我们的系统是否需要做出修改，见下图：

增加环节

增加环节时，我们需要删除路径4文档（起点位置为2，终点位置为3），增加“C领导审核”环节文档和路径8文档（起点位置为2，终点位置为8）、路径9文档（起点位置为8，终点位置为3）。假如当前环节为“A领导审核”，程序流转时仍将使用主文档中保存的当前位置（位置2）搜索路径文档，此时结果可以从路径4文档变成路径8文档，可见这种设计是可以适应增加环节的。同样，这个设计也可以适应删除环节的情况。

注意，环节增删改时还有一种特殊情况，即删改当前环节。这种情况下不仅仅要修改流程配置文档，主文档中的相关内容也要进行更新，如果没有“外力”，主文档包含的当前处理人（这个还涉及了主文档的读写权限）和当前位置是不会自动发生变化的，因此，需要其他手段配合才能实现一个完美的“可配置”工作流。

到目前为止，一个简单的可配置的工作流就算完成了（跟关系式数据库建模的过程非常相似）。经过这一个过程，才发现其实IBM在Lotus WorkFlow中建立的工作流引擎（数据结构）在技术上已经是一种比较完美的方案了。我们绕来绕去自以为会发现新大陆，到了最后还是回到了前人走过的路上（对比Lotus WorkFlow，主要的不同之处是我们这里没有把人员和角色分拆，原因是不想再配置一次names.nsf中已存在的用户）。不管怎么样，从这个简单的可配置流程设计的过程中，我们还是获益匪浅，也深刻认识到一个再完美的工作流引擎也不可能成为普世真理，因为工作流的易用性和适应能力常常是矛盾的，不同的用户会提出不同的要求。因此，技术人员不必执着于技术不可自拔。

---