标准的产品设计工作流程模板.docx

标准的产品设计工作流程

22

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。
标准的产品设计工作流程

每个产品团队都会有自己的工作流程, 无论这个工作流程是否最高效、 是否体现最大价值, 可是我认为只要这个流程能够为实现工作目标提供过程的保障就能够算是好的流程。
对于流程本身而言, 能够因团队不同或工作任务不同而有差异。一个成熟度的产品团队能够在保证工作质量的前提下轻松适应任务的变化, 也就是说能够依据不同的工作要求调整对应工作的流程。也只有这种团队才能正真体现最大的价值, 称得上是一个敏捷的、 能快速响应变化的团队。
那么, 我们先来看看以前做产品设计时的团队工作流程。我总结为是一个相对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、 这份会议纪要将发送给谁, 抄送给谁。

有时候, 产品团队和销售团队不总是一团和气, 一碰面总容易擦出火来。这是因为, 一旦争论到产品的细节, 产品团队总认为销售方面不懂产品, 不懂技术; 而反过来, 销售团队又会责备产品团队不懂用户, 不懂需求, 自以为是。
说实话, 这种情况不太好处理, 但一个有经验的产品经理如果会审时度势, 做出明智的决定, 可能能够化解一些矛盾。
比如,
亲自去再摸一次需求, 而不是一味的火拼, 甚至找到老板来协调;
做出两套方案, 待与用户参与的评审时, 确定最终的需求;
如果明知自己是正确, 则冷处理, 将类似的问题全部挂起, 并尽快整理一份书面澄清函, 由PO提交用户逐一回复。
l  7出资方评审
主要参与角色是Sponsor, Product Owner, PM等; 主要的过程产物是《评审报告》。
内部研发型产品的sponsor一般是分管产品研发的副总或CTO, 有时候CEO, 销售副总也会作为干系人列席; 交付型产品的sponsor一般是用户方的业务负责人。
在这种级别的评审会议, PM要非常的细心准备好每个细节, 熟话说: 台下十年功, 台上三分钟。如果不能经过会议让sponsor认为出资是值得的, 那么团队的日子将非常难过, 对整个team的信心将是沉重的打击。
因此, 在准备过程中, 我认为有以下一些要点是特别要注意的:
1、 要有P3组合。PPT+Prototype+Plan。
Ø  Ppt着重介绍产品的主要设计细节, 核心技术方向, 产品亮点, 有必要还需要包括用户调研的数据分析成果, 外部的可靠来源数据依据等。
Ø  Prototype主要展现产品的外观模样, 主要展现的是功能性, 交互性, 以及视觉性。
Ø  Plan主要展现, 截至当前阶段产品研发的过程到了哪个环节, 一共花费了投资人多少钱, 成本是否在可控范围内, 后续还要投入多少资源等等。
2、 要有问题应答表。
Ø  PM要准备好sponsor可能会问道的一些问题, 并做好准确、 真实的答复准备, 以随时响应sponsor的提问。
Ø  如果PM不能cover所有的方面, 就一定要做好分工, 不同的人准备回答不同的问题。
3、 要准备现场的一些记录工作。
Ø  安排特定人做现场的录音或记录工作。

会议中, 一般会形成一些重要结论, 比如: 当前的工作是否正常, 是否能够继续到下一个阶段; 是否需要做出修改和调整; 是否要停止下来, 等待其它条件满足后再继续。
不论怎样, PM要做好各种应正确准备, 随时与各方面做好沟通和传递。

l  8交互呈现调研
主要参与角色是视觉设计师和交互设计师; 标准成果物是《交互呈现调研报告》。
在交互呈现调研过程, 主要是明确用户群体的特性, 包括了解其使用习惯, 特殊偏好, 在用产品操作过程的友好或缺陷之处等等。
在调研过程中, 我们常常将会用到一些可重用的资源来作为调研的辅助, 比如:
1、 框架体系;
2、 设计模式;
3、 组件;

这些能够被用来作为调研的资源, 为我们快速的理解用户的实际需要有很大的帮助。因为在调研过程中, 有很多时候用户会告诉你, 她们看过的某某网站, 某某产品的某些表现形式很好, 能够借鉴。可是, 哪些表现元素是真正能够被借鉴的, 哪些是不适合被借鉴的, 都没有明确下来, 包括如何借鉴, 如何和用户的实际需求结合起来, 都只是一些非常空洞和概念的想法而已。
因此, 我们会用到一些被我们沉淀和积累的资源来作为调研过程中的案例标准来展现和承载探讨。
Ø  框架体系
框架体系指产品依据展现业务的不同而设计的有着内在联系的各种页面展现框架集合。举个例子, 一个购物网站有注册框架, 支付框架, 购物流程框架, 商品展现框架。同时, 为了支撑购物的良好体验, 一般还会有商品的论坛框架, 评价框架, 搜索框架, 比较框架等等。
那么, 如果是个着重于信息的管理产品呢, 则有信息发布框架, 信息聚合展示框架, 信息搜索框架, 栏目展现框架, 详细信息页框架等等。
如果我们能过将这些框架示例按照一定的逻辑组织和整理起来, 在调研过程中, 依据用户的不同需求, 有针正确展现相类似的框架示例, 那么就能够方便直观的基于示例进行探讨, 明确用户的意图, 形成调研结论。
Ø  设计模式
设计模式是一种常见问题的常看法决方案。
比如, 用户忘记了密码怎么办, 那么我们能够提供一个密码找回模式, 这个模式是经过输入注册的邮箱地址后, 我们将用户的密码发到该邮箱。相应的, 还有登录模式, 各种搜索模式, 分页模式, 日期输入模式, 图片切换模式, 评论模式, 留言模式……
有很多企业都建立了自己的模式资源库, 也就是将各种设计模式的文档经过整理后, 分类保存, 在网上或企业内部进行公开。
比如, 雅虎的设计模式库: 。
Ø  组件
组件是页面最通用的组成元素, 比如, 文本, 链接, 按钮, 复选框, 图片等。一般模式能够在不同产品中通用, 然而组件却往往只适用于特定的产品, 因为, 组件是确定了展现形式的成品, 能够直接被使用。
组件资源库和模式资源库一样, 能够采用很多方式来管理和收集, 比如wiki的方式。也有很多公共的资源提供网站, 比如, , 上面就有很多最新的组件资源

l  9视觉风格调研
主要参与角色是视觉设计师和交互设计师; 标准成果物是《视觉风格调研报告》。
视觉风格调研工作在交互呈现调研的基础上, 调研产品的实际用户群体的熟知的文化理念, 以及现有在用产品的生命原色, 产品隐喻, 所在地方的政治约束, 社会元素等众多因素, 为后期设计适合本产品的特有视觉风格提供依据。
调研过程中要关注的一些要点包括:
Ø  企业CI
Ø  企业内部的视觉设计规范
Ø  现有系统的视觉设计
Ø  企业文化
Ø  用户群体特性
Ø  操作使用环境
Ø  操作使用习惯
有时候, 用户会要求你去改变现有产品的视觉设计, 那么还需要调研清楚, 她们为什么要改变, 原来的视觉有什么不足之处。

l  10视觉设计
主要参与角色是视觉设计师; 标准成果物是《页面效果图》, 《视觉设计规范初稿》。
在视觉调研完成后, VI进入设计阶段。在设计之初, PM、 UE首先要与VI确定工作内容和计划。
比如,
Ø  哪些页面要做效果, 这些页面的确定稿分别在何时会提供给VI。
Ø  哪些组件会被使用到, 有多少种组件需要做效果, 这些组件何时会确定提供给VI。
除了页面的效果图, 还要形成视觉设计规范的初稿, 在这份规范中, 要形成视觉设计的各种标准。比如,
Ø  页面栅格系统
Ø  视线流
Ø  框架布局的大小
Ø  各个元素的大小, 色彩, 对齐
Ø  各种留白
Ø  交互defalt样式, 鼠标划过样式, 点击样式
Ø  文字规范, 字体, 大小
Ø  图片样式, 大小, 格式, 显示处理等
在这个阶段VI的成果只能称为视觉设计规范的初稿, 这是因为只有在得到sponsor评审确认后, 设计的标准才能最终确定下来, 成为后续工作的基线和准则。

l  13裁图及前端实现
主要参与角色是前端工程师, F.E; 标准成果物是《静态页面》, 《视觉设计规范》。
前端工程师的最主要工作分为两个部分:
1、 切图。
2、 编写页面JS和CSS等实现脚本。
下面是一个前端工程师交给PM的成果目录结构:

后续工作将交给PHPer, Javaer完成前后台的渲染。
到此, 整个产品设计工作将完成阶段性任务, 后续则是产品开发工程师实现代码, 产品测试工程师完成测试和集成, 最终发布; 产品进入运营阶段。

本文参考了:
《WebAnatomy:Interaction Design Frameworks that Work》
       By Robert Hoekman,jr.  Jared Spool