产品需求文档的学习记录(二)

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

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

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

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

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

有了这份结构导图,我们可以对产品进行鸟瞰式考虑和完善,当有问题时,修改起来也比原型和文档方便很多。这样的方法同样适用于移动互联网产品的规划,并且比起Web产品更加容易梳理产品结构。

以上讲的都是前端面向浏览者的用户流程,但是如果规划的是一个平台级的大众化产品就不能从前端进行梳理了,例如CMS、BBS之类的程序,他们采用框架式开发,将功能与模板独立,前端的界面布局仅仅是通过模板机制的标签调用,因此在做产品规划时,前端是涉及不到的,也不应该从前端入手。遇到CMS类平台产品的规划,也同样使用这样的方法,只不过是从后台入手模拟管理员的流程。

PRD文档写前准备就是让我们先通过思维导图梳理思路,明白产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素,逐步的将脑海里的想法明确梳理成结构。虽然已经明确了产品的结构,但是这样的思维导图对于设计与技术人员依旧是抽象的,他们仍然看不懂,同时对于产品经理自己来说,这样的结构图也是没有经过推演的,具体是否符合产品逻辑,是否符合用户体验,都是没有深思过的,因此我们接下来就要进行原型设计,开始具体的考虑结构方案的可行性。

时间: 2024-08-01 22:48:03

产品需求文档的学习记录(二)的相关文章

产品需求文档的学习记录(四)

前三篇文章我们逐步梳理了产品的信息结构.框架结构.界面结构(原型),这一步我们就要根据之前完成的工作,开始正式撰写产品需求文档了(PRD文档). 通过之前的准备工作,我们更加清楚了产品的需求,并细致的考虑了方案的可行性,从而减少与避免了撰写文档时容易忽略的细节黑洞. PRD文档没有标准的规范,也没有统一的模板,每个公司都不一样,并且每个人也不一样,这个取决于个人习惯和团队要求.虽然PRD文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录.文档在撰写过程中,我们可以自行不断的修改

产品需求文档的学习记录(一)

PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google.PRD文档是基于BRD.MRD的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员.在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员.相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是

产品需求文档的学习记录(三)

我们通过思维导图将想法进行了结构化梳理,接下来我们就需要进行方案的可行性推演,验证产品功能是否可行,预估项目要花多少人力物力,因此我们就要通过原型设计进行相关需求的论证.一开始就撰写PRD文档,我们很难对产品进行各方面的评估,也无法得知方案的可行性,并且无法直观细致的考虑产品. 原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出,通过原型设计后,我们就可以进行产品宣讲了.相对于之前抽象的文字描述,原型则更加清晰产品的需求,设计和技术人员或者老板也能够更加直观的

产品需求文档的学习记录(五)

在产品和技术领域里都有UML的技能知识,而对于产品人员的UML则更多的是指用例图,也就是我所称呼的用户流程图.在讲PRD文档写作的第二篇文章里,我提到了用户流程图的制作,实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式,由于以结构化的方式描述用例太抽象,缺少逻辑性表达,并且那篇文章更偏向于功能性用户流程,还不是实际意义上的用例,因此今天我补文一篇,细讲一下UML用例图和用例文档. 用例文档是由多个用例组成的一份文档,主要用于技术开发与测试使用,他是PRD中的重要辅助文档,用于讲

【产品】好的产品需求文档(PRD)怎么写?

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚. 通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识.如何才能写出好的PRD,让产品研发团队成员,开发.测试.运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题.也有人可能认为PRD只要中心思想

产品需求文档(PRD)到底怎么写?

做产品经常会写PRD,但是如果没有一套完整的写作思路和框架,写出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发.前端.测试吐槽.趁这个周末有空,来梳理下一下写PRD的逻辑. 一.什么是PRD? PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档.该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档.当然,这个定义针对的是一个全新的产品.广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位.目标市

PRD产品需求文档

什么是PRD? PRD是Product Requirement Document的英文缩写,即产品需求文档的意思.PRD昰产品流程中的最后一步工作,是将原型中的功能.界面具象化描述,是提交给设计(UI).技术和测试部门的执行标准.一般由产品经理亲自完成,如果有产品专员(助理)的话,由他们主要完成其实更好. PRD应包括哪些内容? PRD的标准很难衡量,因团队而异,只要能够明确传达产品需求的文档都是合格的.但一般需要包含以下四个部分: 1.产品概要:说明产品目标.需求来源.主要项目负责人和产品整体

顶级产品经理是如何写产品需求文档(PRD)的

产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现,作用是"对市场需求文档(MRD)中的内容进行指标化和技术化",PRD质量的好坏直接影响到研发部门是否能够明确产品的功能和性能,是否能够研发出符合预期的产品,所以PRD也是体现产品经理专业程度的一个重要指标. 可以理解为,PRD是产品经理关于产品功能的宣导和传达,它通过清晰扼要的表述将产品意图呈现给阅读者,PRD的阅读者一般包括开发人员,设计

程序员爱看的产品需求文档,转给你的产品经理

假如产品需求文档(PRD)是一个产品,如何做出一个拥有良好用户体验的PRD? 让我们先来考察下PRD的用户群体(User Persona):主要是开发人员,在繁忙的开发任务中最希望看到"简洁易懂"的产品需求文档. 梳理下PRD的功能:传达出产品需求:管理记录产品迭代过程:各部门共享产品信息,以促进沟通: 因此一个好的PRD的原则是:结构清晰:语言简洁易懂:实时共享. 我们具体如何制作? 一个PRD文档即可 现在,越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式,因为之前