标准的产品设计工作流程模板文档格式.docx

1、 前端工程师开始依照产品经理的线框做HTML开发, 同时要肩负一些交互设计工作, 比如, 导航, 搜索, 查询, 弹出页面或层设计, menu等; 同时, 美工开始依照线框, 做页面的视觉设计, 比如, 色彩, 按钮, logo, icon等; 当HTML和美工设计都ok了, 就能够交给Javaer、 PHPer等做前后台整合了; 然后是产品的一系列测试, 包括可用性测试, 功能性测试, 性能压力测试, 产品集成测试, 发布测试等。然而, 随着产品精细化设计的要求, 特别是web2.0的一些标准逐步引入到产品设计范畴。以注重用户体验, 注重以人与系统的交互为设计重点, 崇尚简约和适度的设计理念

2、被提出来, 并逐渐引领了产品设计的主流思想。在新的产品设计过程中, 为了体现web2.0的UE设计元素, 实现产品设计的工作精细化, 我们逐步优化了新的产品标准工作流程, 并定义了产品工作流程的标准输出成果。新的产品设计团队标准工作流程被划分为两个领域:1、 产品功能设计领域;2、 产品视觉交互设计领域;这种划分的意义在于把产品不再仅仅看作一个由代码构成的系统, 而更是一组由用户行为构成的服务集合。从系统角度来看设计更看重的是功能, 而从服务角度来看设计更看重的是体验, 因此, 我们在产品设计的过程中, 一条线去关注产品的功能设计, 一条线去关注产品的体验设计。只有两个领域都做到了精致, 做到

3、了极致, 一个产品才称得上是好产品, 才有机会帮助投资人获得盈利的可能。产品功能设计领域包括以下一些环节: 制定工作计划 用户需求调研 产品功能分析 信息架构设计 原型制作 内部评审 出资方评审产品视觉交互设计领域包括的环节是: 交互呈现调研 视觉风格调研 视觉设计 视觉内部评审 资方评审 裁图及前端实现从UE的五层要素设计思路来看, 用户需求调研过程是对应的Strategy和Scope层; 产品功能分析过程对应了Structure层; 交互呈现调研、 原型制作对应了Skeleton层; 视觉风格调研和设计对应了Surface层。信息架构设计则对应了Structure层的信息架构和Skelet

4、on层的信息设计。下面对每一个流程进行简要的介绍和描述:l1制定工作计划主要参与角色是PM-产品经理; 主要的标准成果物是工作计划。第一步非常重要, 能够理解为是产品路线图上最为关键的一个阶段计划。熟话说万事开头难, 好的开头是确保成功的第一步。一个成功的产品在其生命历程上, 会包括:创意阶段-设计阶段-实现阶段-运行阶段-更新升级-消亡这里制定的工作计划是设计阶段的工作计划, 这个阶段计划的目标是把产品的创意变成可实现的产品设计语言, 确保产品的创意和目标得以在实现过程中完美体现出来。同样, 在计划的过程中, PM也要考虑工作任务的特性, 结合工作流程做出适应和改变。我在制定工作计划时使用的

5、工具一般是MS的Project或者Excel, 计划内容要明确至少四大要素:1、 任务: 要完成的任务最好能做合理的细分, 能够参考WBS的定义。2、 时间: 任务开始和结束时间;3、 资源: 投入到任务的资源, 要责任到人;4、 产出: 标准的产出物是什么, 这是检验其工作成果的最好载体。2用户需求调研 主要的标准成果物是调研问卷和调研分析报告。对于有特定目标用户的研发型产品, 往往都需要PM在产品设计之初对用户做详尽的调研, 调研的内容包括: 总体性调研产品价值目标, 用户的业务目标, 用户的组织架构, 与产品相关的流程, 规章制度, 出资人对于产品认定的成功标准等。 功能和非功能性调研产

6、品用户角色, 产品功能需求, 用户对于产品功能的需求优先级, 产品内容需求, 产品约束, 运营需要, 性能要求, 其它特性等。在进行调研的时候, 调研问卷是必不可少的一份文档。在准备调研问卷时, PM能够经过问卷明确调研的方向和把控范围; 被调研者能够了解调研重点, 并准确的给予响应, 明确提供有价值的信息范围（ 深度和广度等） 。需求调研完成后, PM要及时完成调研分析报告, 并与用户进行确认。调研分析报告是将调研过程中形成结论的内容按照一定的逻辑格式规整成文后, 方便用户进行逐条确认。调研分析报告一般着重体现五点内容:1、 产品的战略目标和价值体现2、 产品的核心业务形态3、 产品的功能分

7、布和描述4、 产品的非功能需求（ 不包含交互和视觉部分内容, 这部分将单独调研） 5、 产品的内容需求（ 作为信息架构设计的基础） 如果调研报告能将上述的五方面内容说清楚了、 说准确了, 我们会认为调研工作是成功的。3产品功能分析 主要的标准成果物是产品需求文档, 有个洋名字为PRD。产品需求文档是对产品的需求分析后, 以设计语言进行描述, 将作为开发阶段的主要输入物之一。如果是通用型产品, 在PRD的分析过程中还能够借鉴MRD。在这类项目中, PRD在产品项目中是一个承上启下的作用, 对上是基于MRD内容的深化和落地, 对下是要把MRD中的内容设计语言化和技术化, 向研发人员说明产品的功能特

8、性和性能指标。在这里, 我们抛开市场元素, 只从产品本身的功能特性来看, 我们约束PRD要体现以下的一些内容: 产品生命周期模型 实现进度安排规划 产品技术路线 对产品feature详细描述 feature优先级 产品release计划 用例（ use cases） 设计 产品部署设计 产品性能设计至于产品的需求分析方法, 能够参考我前面的文章探讨APP的分析过程。4信息架构设计主要参与角色是PM-产品经理或IA-信息架构师; 主要的标准成果物是信息架构设计。产品的信息架构设计文档主要包括: 信息架构策略 信息架构蓝图 内容映射 内容模型 原型（ 着重体现四大致系: 导航, 搜索, 标签和组织

9、） 具体能够参考我前面的文章信息架构的设计思路。这里需要说明的是: 特别对于互联网产品而言, 信息架构不是一个简单的工作, 不能把它作为产品需求设计的一个附属任务来完成, 而是要将其作为一个独立的工作任务, 安排有经验的专家来负责把控。因为, 我见过很多因没有重视产品的信息架构设计, 而到后来不得不推翻重做的产品, 这种劳命伤财的过程希望不要再发生了。5原型制作主要参与角色是PM-产品经理和UE交互设计师; 主要的标准成果物是低保真原型和高保真原型。很多产品经理都是十项全能, 画线框, 画原型, 做分析, 做设计.可是真正检验一个产品经理的业务能力和设计素养的就是她做的prototype。为什

10、么这么说?因为, 软件行业的产品经理, 往往身上都背负着产品创新和设计的重任, 这种能力最好的体现方式就是经过原型来展现, 一个有想法并能将想法快速展现出来的PM, 具备成为一个合格PM的基础。在不同的团队, PM的工作略有不同。有的产品经理只画线框, 然后把线框交给UE, 由UE完成prototype的制作, 因为在UE的工作中还包括了交互的设计。有的产品经理则需要一把抓, 从功能设计到交互设计全部搞定, 当然这样的产品经理虽然累, 但综合能力将会更为突出一些。再来说说线框和prototype的区别: 线框是静态的; prototype能够是有交互能力的; 线框是思路; prototype是

11、思路的具体实现; 线框包括静态页面和说明; prototype是页面和行为展现; 线框更多体现框架、 组织、 结构、 功能划分及布局等; prototype更多体现: 逻辑, 细节, 元素, 整体, 色彩, 交互, 内容等。Prototype又分为低保真和高保真两种: 低保真原型反应页面的框架逻辑, 导航逻辑, 交互逻辑, 标签逻辑, 内容组织逻辑等。 而高保真原型在低保真原型的基础上, 还加入了信息内容, 视觉元素, 交互细节等。两种原型的用法也略有不同:一般在产品团队中, 内部更看重的是低保证原型。因为, 在设计之初, 最怕的是偏离设计方向而浪费资源, 因此经过低保真原型能够快速的发现问题

12、, 经过不断的迭代设计完善产品框架和主体构造。一般在与外部进行产品工作成果说明和演示时, 用高保真原型更好。因为, sponsor或用户更喜欢关注产品的实际模样, 因为她们骨子里是代表未来实际使用者的利益, 如果她们觉得色彩不好, 交互细节有问题, 那么她们会坚持要求团队做出响应, 直至她们满意为止, 既然如此, 我们最好将这个过程安排的越早越好, 至少不要因为她们的意见而导致后期的开发工作重复。6内部评审主要参与角色是Product Owner; 主要的过程产物是评审报告。在一个以自有产品销售为主的企业里面, 产品的研发和销售往往是两个体系。我们将产品的研发负责人称为PM, 而将销售的负责人

13、称为Product Owner。PO熟悉客户, 知道客户为何需要这个产品, 也知道市场的很多方方面面, 因此, 她们参与产品的内部评审是非常有必要的。在内部评审过程中, 我们要做好评审报告的记录。对于评审过程, 我认为有以下几点要特别记录:1、 一致认同的问题。在会上就要给予明确的响应措施, 谁负责响应, 多长时间响应, 谁来检查等;2、 不能落实的问题。在会上要形成跟进方案, 谁来跟进, 找谁获取资源, 争取什么时候获得结论等;3、 形成的结论。会议上形成了什么结论, 后续有何安排等, 都需要详细记录。4、 这份会议纪要将发送给谁, 抄送给谁。有时候, 产品团队和销售团队不总是一团和气, 一碰面总容易擦出火来。这是因为, 一旦争论到产品的细节, 产品团队总认为销售方面不懂产品, 不懂技术; 而反过来, 销售团队又会责备产品团队不懂用户, 不懂需求, 自以为是。说实话, 这种情况不太好处理, 但一个有经验的产品经理如果会审时度势, 做出明智的决定, 可能能够化解一些矛盾。比如, 亲自去再摸一次需求, 而不是一味的火拼, 甚至找到老板来协调;做出两套方案, 待与用户参与的评审时, 确定最终的需求;如果明知