产品需求梳理流程

0.216字数 3809阅读 5585

本文根据唐杰博客整理

信息构造图

规划产品的第一步就是梳理出产品的信息结构,有了信息结构我们才能继续往下规划产品结构,并且信息结构是服务端技术人员创建数据库的依据,是数据结构的辅助文件。对于新产品或者新功能,没有人能够比产品经理更加清楚所需要的信息内容了,因此第一步我们就需要先将这些信息罗列出来,形成结构化。(如下图)

在这一步,我们还不需要深入的考虑产品的界面与功能。信息结构的考虑有面向前端的,也有面向后端的,具体视产品类型而定。

例如CMS之类的程序,这类程序采用框架式开发,将功能与模板独立,因此前端具有多变性,并且这类产品属于平台型产品。针对这类产品,我们在规划信息结构时,只需要简单的考虑一些前端的功能需求,更多的是面向后端管理员操作进行考虑,从后端入手规划和罗列出所需要的信息内容结构。

无论是什么样的产品类型,无论从哪里入手,我们第一步都是先要罗列信息结构,因为信息结构图不仅是辅助技术人员创建数据库的图表,也是辅助产品人员进行产品功能规划的参考,只有对信息或数据的结构了解,我们才能玩转数据,玩转产品。

信息结构图是产品层面的理解,如果要入库这些信息,还需要进行数据结构的讨论。一条信息的存储有很多附加属性,具体是存成字段还是数据表,还是说存在中间表或者关联表,这些都需要在完成PRD文档后和数据库技术人员共同讨论。讨论时除了展示信息结构图,还要讲解产品原型和功能需求,以便数据库技术人员了解产品意图,方便他们做数据库规划时考虑到以后的扩展。

信息结构图是我们将概念想法形成结构化的第一步,也是我们接下来几步工作的辅助文件

产品结构图和用户流程图

将概念想法形成了信息结构,罗列出了产品的所有信息内容,现在我们就要依据信息结构,开始规划产品的功能需求,绘制出产品结构图用户流程图。首先我们要规划出产品的频道及子频道、子模块或子页面。(如下图)

图注:讲解一下我对于这个思维导图的名词理解
1、 频道:某一个同性质的功能或内容的共同载体,也可称为功能或内容的类别。
2、子频道:某频道下细分的另一类别
3、页面:单个或附属某个频道或分类下的界面
4、模块:页面中多个元素组成的一个区域内容,可以有一个或多个,也可以循环出现(例如:文章列表)
5、模块元素:模块中的元素内容,以文章列表举例:文章标题、文章摘要、文章发布时间,这些都是元素,都是组成模块的内容,同时他们也是可以循环出现的。元素的类型可以是:文字、图片、链接等等

如果你学过网页设计,或者了解Web产品的模板机制,你就能够理解这些名词了。如下图所示,这是博客的首页结构。

当规划出频道后,就需要以用户的视角进行一步一步的模拟操作,逐渐完善产品的结构导图。称为用户流程图,用于展现产品经理脑海中比较抽象的产品逻辑,也是产品经理对自己脑海中的产品想法进行梳理的一个过程。(如下图示例)

这样做的目的就是梳理产品逻辑,让我们清楚的知道产品有几个频道,频道下面有没有子频道或者有多少个页面,这些页面里又有哪些功能模块,这些功能模块里又有哪些元素。这样我们就模拟了用户的整个操作流程,逐一的将产品的所有功能界面操作了一遍,也列出了产品结构图用户流程图

虽然已经明确了产品的结构,但是这样的思维导图对于设计与技术人员依旧是抽象的,他们仍然看不懂,同时对于产品经理自己来说,这样的结构图也是没有经过推演的,具体是否符合产品逻辑,是否符合用户体验,都是没有深思过的,因此我们接下来就要进行原型设计,开始具体的考虑结构方案的可行性。

原型设计

原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出,通过原型设计后,我们就可以进行产品宣讲了。相对于之前抽象的文字描述,原型则更加清晰产品的需求,设计和技术人员或者老板也能够更加直观的了解到产品意图。

原型设计是将结构化的需求进行框架化,因此原型也被称为线框图,具体的表现手法有很多种,相关的辅助软件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。

手绘原型

因为原型也被称为线框图,因此手绘是最简单直接的方法,也是最快速的表现产品轮廓的手法(如下图)

手绘原型在初期验证想法时非常高效,也方便讨论和重构,同时也适合敏捷开发时快速出原型。

灰模原型

灰模原型是由图形设计软件制作而成,最常用的软件是 PhotoShopFireWorks ,相对手绘原型,灰模更加清晰和整洁,也适用于宣讲,但是需要产品人员熟悉使用图形设计软件(如下图)。

灰模原型常用于移动互联网产品的设计,由于移动产品的交互需求复杂,原型设计软件难以高效的表达需求,因此移动互联网产品的设计通常是灰模原型交互文档组合成 PRD 文档。几天我再详情讲讲移动互联网的产品设计)

交互原型

交互原型是使用原型设计软件完成的原型,常用软件是 Axure RP,通常情况交互原型的设计仅早于 PRD文档,是产品经理想法推演的最后一步。通过Axure RP之类的交互原型软件制作出来的产品原型,在功能需求与交互需求的表现和正式产品几乎是一致的,所以有时交互原型也被称为产品Demo版。

以上三种方法并不是渐进的流程,而是三种原型设计的方法,具体取决于你的产品需求和团队要求。

产品经理设计原型是为了帮助自己更细致的思考方案的可行性,也是为了给别人讲解的时候,让听众能够清晰直观的了解产品,同时也是为了确保产品在执行过程中,是按产品经理最初设想的需求和期望完成的。因此产品经理的原型是没有很高的要求的,只要对方能够听懂看懂,使用手绘原型是最高效率的方法。

撰写 PRD 文档

通过之前的准备工作,我们更加清楚了产品的需求,并细致的考虑了方案的可行性,从而减少与避免了撰写文档时容易忽略的细节黑洞。

PRD文档没有标准的规范,也没有统一的模板,每个公司都不一样,并且每个人也不一样,这个取决于个人习惯和团队要求。虽然PRD文档没有标准的规范,但是有两项是必不可少的,那就是文件标识修改记录。文档在撰写过程中,我们可以自行不断的修改完善,但是如果正式发布或交给团队其他成员后,一旦有了修改,为了文档的同步,我们就需要标注出文档的修改内容,备注修改记录。关于文件标识和修改记录,大家的格式都大同小异(如下图)。

PRD 文档的形式常见的有以下三种:Word、图片、交互原型

Word

这是传统意义上的 PRD 文档,主要有四个部分组成(具体视你的产品要求进行划分),分别是:结构图全局说明频道功能效果图。PRD 文档的阅读者更多是偏向于技术人员,因此 PRD 文档目的性很明确,就是要描述产品的功能需求,所有PRD文档是没有关于市场方面的描述,同时也建议大家尽量减少不必要的文字,在能够让阅读者看懂并且了解产品意图的情况下,文字越少越好。这主要是因为绝大多数人是没有足够耐心认真看完 PRD 文档的,因此我们要尽量减化文档内容。

结构图

  • 信息结构图:主要是辅助服务端技术人员创建或调整数据结构的参考文件
  • 产品结构图:主要是辅助设计和技术开发人员了解产品的全局结构,他和用户流程图不一样,产品结构图只是罗列出产品的频道和页面。

全局说明

主要讲解产品的全局性功能的说明,例如网站产品的页面编码、用户角色,移动产品的缓存机制、下载机制,这类全局性功能的说明。这里举一个移动产品的“状态维持与恢复”的例子,示例如下

状态的维持与恢复
当用户退出产品时(误操作、Home键、锁屏、自动关机),产品需要维持用户操作前的状态,当用户返回产品时仍可以恢复到之前状态,并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时,如果用户在产品中有下载任务时,仍然保持下载。

提供一个产品需求文档实例

频道功能

以频道为单位,页面为子项,分别描述产品的频道、页面及页面模块元素的功能需求(格式如下)。

示例格式
1、频道名:频道介绍及需求说明
2、页面1:页面介绍及需求说明
2.1、页面模块1:模块功能需求说明
2.1.1、页面模块1-元素1:功能说明
2.1.2、页面模块1-元素2:功能说明
2.2、页面模块2:模块功能需求说明

在撰写功能需求时,我们需要考虑用户的流程,例如一个“完成”按钮,我们需要描述他完成后,系统要不要给出反馈提示(反馈提示是什么样的形式反馈,内容显示成什么,有没有内容需要调取数据库),或者要不要跳转页面(跳转到哪个页面,这个页面是其他频道页面,还是这个功能的子页面,如果是子页面就需要再描述这个子页面的模块及元素内容)。

效果图

效果图是由设计师完成的产品图,和实际开发完成的产品保真度一致。

图片

图片形式的PRD文档是基于效果图的说明文件,将传统Word形式的功能需求说明标注在效果图上,这种方式经常使用在移动互联网领域,实际上是图文形式的交互需求文件,只是在此基础上更深入的描述出功能需求。

对于图片形式的PRD文档,我们只需要另外再描述一下全局说明,其他频道页面的需求直接以图片形式展示,这种方式相对于Word文档的纯文字更加生动易读并且直观,因此有一些产品经理非常喜欢用这种方式代替Word形式的PRD文档。

交互原型

这里指的交互原型就是上一篇文章讲的原型设计,使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观,并且原型软件还支持元素标注和导出Word文档,因此很多产品经理都喜欢使用Axure PR来代替Word完成PRD文档。

当我们通过Axure PR制作出产品原型后,实际上他已经是很完善的产品Demo了,因此我们只需要加上元素的标注,在标注中说明功能需求,这样导出的HTML文件相比Word文档更直观易懂,是非常高效的产品需求说明方式。

总结:无论你采用哪种方式产出需求文档,最终的目的都是为了方便团队成员理解产品的意图,因此哪种方法能够避免细节黑洞,高效完成产品的设计和研发,那么这种方法就是最有效的方法。

推荐阅读更多精彩内容