产品设计主要工作流程图

标准的产品设计工作流程每个产品团队都会有自己的工作流程，无论这个工作流程是否最高效、是否体现最大价值，但是我认为只要这个流程能够为实现工作目标提供过程的保障就可以算是好的流程。

对于流程本身而言，可以因团队不同或工作任务不同而有差异。

一个成熟度的产品团队可以在保证工作质量的前提下轻松适应任务的变化，也就是说能够依据不同的工作要求调整对应工作的流程。

也只有这种团队才能正真体现最大的价值，称得上是一个敏捷的、能快速响应变化的团队。

那么，我们先来看看以前做产品设计时的团队工作流程。

我总结为是一个相对normal的流程。

大多时候，一个PM，一个美工，一两个写Html的工程师就足够了。

如下图所示：工作流程包括：Ø 当产品经理做好了产品的需求分析和功能实现批次计划后，开始计划产品迭代过程。

Ø PM做好产品的线框设计，交给前端工程师（Front-End）；Ø 前端工程师开始依照产品经理的线框做HTML开发，同时要肩负一些交互设计工作，比如，导航，搜索，查询，弹出页面或层设计，menu等；Ø 同时，美工开始依照线框，做页面的视觉设计，比如，色彩，按钮，logo，icon等；Ø 当HTML和美工设计都ok了，就可以交给Javaer、PHPer等做前后台整合了；Ø 然后是产品的一系列测试，包括可用性测试，功能性测试，性能压力测试，产品集成测试，发布测试等。

然而，随着产品精细化设计的要求，特别是web2.0的一些标准逐步引入到产品设计畴。

以注重用户体验，注重以人与系统的交互为设计重点，崇尚简约和适度的设计理念被提出来，并逐渐引领了产品设计的主流思想。

在新的产品设计过程中，为了体现web2.0的UE设计元素，实现产品设计的工作精细化，我们逐步优化了新的产品标准工作流程，并定义了产品工作流程的标准输出成果。

如下图所示：新的产品设计团队标准工作流程被划分为两个领域：1、产品功能设计领域；2、产品视觉交互设计领域；这种划分的意义在于把产品不再仅仅看作一个由代码构成的系统，而更是一组由用户行为构成的服务集合。

从系统角度来看设计更看重的是功能，而从服务角度来看设计更看重的是体验，所以，我们在产品设计的过程中，一条线去关注产品的功能设计，一条线去关注产品的体验设计。

只有两个领域都做到了精致，做到了极致，一个产品才称得上是好产品，才有机会帮助投资人获得盈利的可能。

产品功能设计领域包括以下一些环节：Ø 制定工作计划Ø 用户需求调研Ø 产品功能分析Ø 信息架构设计Ø 原型制作Ø 部评审Ø 出资方评审产品视觉交互设计领域包括的环节是：Ø 交互呈现调研Ø 视觉风格调研Ø 视觉设计Ø 视觉部评审Ø 资方评审Ø 裁图及前端实现从UE的五层要素设计思路来看，用户需求调研过程是对应的Strategy和Scope层；产品功能分析过程对应了Structure层；交互呈现调研、原型制作对应了Skeleton层；视觉风格调研和设计对应了Surface层。

信息架构设计则对应了Structure层的信息架构和Skeleton层的信息设计。

下面对每一个流程进行简要的介绍和描述：l 1制定工作计划主要参与角色是PM-产品经理；主要的标准成果物是《工作计划》。

第一步非常重要，可以理解为是产品路线图上最为关键的一个阶段计划。

熟话说万事开头难，好的开头是确保成功的第一步。

一个成功的产品在其生命历程上，会包括：创意阶段---设计阶段---实现阶段---运行阶段---更新升级---消亡这里制定的工作计划是设计阶段的工作计划，这个阶段计划的目标是把产品的创意变成可实现的产品设计语言，确保产品的创意和目标得以在实现过程中完美体现出来。

同样，在计划的过程中，PM也要考虑工作任务的特性，结合工作流程做出适应和改变。

我在制定工作计划时使用的工具一般是MS的Project或者Excel，计划容要明确至少四大要素：1、任务：要完成的任务最好能做合理的细分，可以参考WBS的定义。

2、时间：任务开始和结束时间；3、资源：投入到任务的资源，要责任到人；4、产出：标准的产出物是什么，这是检验其工作成果的最好载体。

l 2用户需求调研主要参与角色是PM-产品经理；主要的标准成果物是《调研问卷》和《调研分析报告》。

对于有特定目标用户的研发型产品，往往都需要PM在产品设计之初对用户做详尽的调研，调研的容包括：Ø 总体性调研产品价值目标，用户的业务目标，用户的组织架构，与产品相关的流程，规章制度，出资人对于产品认定的成功标准等。

Ø 功能和非功能性调研产品用户角色，产品功能需求，用户对于产品功能的需求优先级，产品容需求，产品约束，运营需要，性能要求，其他特性等。

在进行调研的时候，调研问卷是必不可少的一份文档。

在准备调研问卷时，PM可以通过问卷明确调研的方向和把控围；被调研者可以了解调研重点，并准确的给予响应，明确提供有价值的信息围（深度和广度等）。

需求调研完成后，PM要及时完成调研分析报告，并与用户进行确认。

调研分析报告是将调研过程中形成结论的容按照一定的逻辑格式规整成文后，方便用户进行逐条确认。

调研分析报告一般着重体现五点容：1、产品的战略目标和价值体现2、产品的核心业务形态3、产品的功能分布和描述4、产品的非功能需求（不包含交互和视觉部分容，这部分将单独调研）5、产品的容需求（作为信息架构设计的基础）如果调研报告能将上述的五方面容说清楚了、说准确了，我们会认为调研工作是成功的。

l 3产品功能分析主要参与角色是PM-产品经理；主要的标准成果物是《产品需求文档》，有个洋名字为PRD。

产品需求文档是对产品的需求分析后，以设计语言进行描述，将作为开发阶段的主要输入物之一。

如果是通用型产品，在PRD的分析过程中还可以借鉴MRD。

在这类项目中，PRD在产品项目中是一个承上启下的作用，对上是基于MRD容的深化和落地，对下是要把MRD中的容设计语言化和技术化，向研发人员说明产品的功能特性和性能指标。

在这里，我们抛开市场元素，只从产品本身的功能特性来看，我们约束PRD要体现以下的一些容：Ø 产品生命周期模型Ø 实现进度安排规划Ø 产品技术路线Ø 对产品feature详细描述Ø feature优先级Ø 产品release计划Ø 用例（use cases）设计Ø 产品部署设计Ø 产品性能设计至于产品的需求分析方法，可以参考我前面的文章《探讨APP的分析过程》。

l 4信息架构设计主要参与角色是PM-产品经理或IA-信息架构师；主要的标准成果物是《信息架构设计》。

产品的信息架构设计文档主要包括：Ø 信息架构策略Ø 信息架构蓝图Ø 容映射Ø 容模型Ø 原型（着重体现四大体系：导航，搜索，标签和组织）具体可以参考我前面的文章《信息架构的设计思路》。

这里需要说明的是：特别对于互联网产品而言，信息架构不是一个简单的工作，不能把它作为产品需求设计的一个附属任务来完成，而是要将其作为一个独立的工作任务，安排有经验的专家来负责把控。

因为，我见过很多因没有重视产品的信息架构设计，而到后来不得不推翻重做的产品，这种劳命伤财的过程希望不要再发生了。

l 5原型制作主要参与角色是PM-产品经理和UE交互设计师；主要的标准成果物是《低保真原型》和《高保真原型》。

很多产品经理都是十项全能，画线框，画原型，做分析，做设计…….但是真正检验一个产品经理的业务能力和设计素养的就是他做的prototype。

为什么这么说？因为，软件行业的产品经理，往往身上都背负着产品创新和设计的重任，这种能力最好的体现方式就是通过原型来展现，一个有想法并能将想法快速展现出来的PM，具备成为一个合格PM的基础。

在不同的团队，PM的工作略有不同。

有的产品经理只画线框，然后把线框交给UE，由UE完成prototype的制作，因为在UE的工作中还包括了交互的设计。

有的产品经理则需要一把抓，从功能设计到交互设计全部搞定，当然这样的产品经理虽然累，但综合能力将会更为突出一些。

再来说说线框和prototype的区别：Ø 线框是静态的；prototype可以是有交互能力的；Ø 线框是思路；prototype是思路的具体实现；Ø 线框包括静态页面和说明；prototype是页面和行为展现；Ø 线框更多体现框架、组织、结构、功能划分及布局等；prototype更多体现：逻辑，细节，元素，整体，色彩，交互，容等。

Prototype又分为低保真和高保真两种：Ø 低保真原型反应页面的框架逻辑，导航逻辑，交互逻辑，标签逻辑，容组织逻辑等。

Ø 而高保真原型在低保真原型的基础上，还加入了信息容，视觉元素，交互细节等。

两种原型的用法也略有不同：一般在产品团队中，部更看重的是低保证原型。

因为，在设计之初，最怕的是偏离设计方向而浪费资源，所以通过低保真原型可以快速的发现问题，通过不断的迭代设计完善产品框架和主体构造。

一般在与外部进行产品工作成果说明和演示时，用高保真原型更好。

因为，sponsor或用户更喜欢关注产品的实际模样，因为他们骨子里是代表未来实际使用者的利益，如果他们觉得色彩不好，交互细节有问题，那么他们会坚持要求团队做出响应，直至他们满意为止，既然如此，我们最好将这个过程安排的越早越好，至少不要因为他们的意见而导致后期的开发工作重复。

l 6部评审主要参与角色是Product Owner；主要的过程产物是《评审报告》。

在一个以自有产品销售为主的企业里面，产品的研发和销售往往是两个体系。

我们将产品的研发负责人称为PM，而将销售的负责人称为Product Owner。

PO熟悉客户，知道客户为何需要这个产品，也知道市场的很多方方面面，所以，他们参与产品的部评审是非常有必要的。

在部评审过程中，我们要做好评审报告的记录。

对于评审过程，我认为有以下几点要特别记录：1、一致认同的问题。

在会上就要给予明确的响应措施，谁负责响应，多长时间响应，谁来检查等；2、不能落实的问题。

在会上要形成跟进方案，谁来跟进，找谁获取资源，争取什么时候获得结论等；3、形成的结论。

会议上形成了什么结论，后续有何安排等，都需要详细记录。

4、这份会议纪要将发送给谁，抄送给谁。

有时候，产品团队和销售团队不总是一团和气，一碰面总容易擦出火来。

这是因为，一旦争论到产品的细节，产品团队总认为销售方面不懂产品，不懂技术；而反过来，销售团队又会责备产品团队不懂用户，不懂需求，自以为是。