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

我们通过思维导图将想法进行了结构化梳理,接下来我们就需要进行方案的可行性推演,验证产品功能是否可行,预估项目要花多少人力物力,因此我们就要通过原型设计进行相关需求的论证。一开始就撰写PRD文档,我们很难对产品进行各方面的评估,也无法得知方案的可行性,并且无法直观细致的考虑产品。

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

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

当到了原型设计这一步时,已经不仅仅是构思了,我们需要更加深入的了解每个页面上的元素和这些元素的属性。例如按钮元素,我们就需要考虑这个按钮的功能,并且这个功能操作后带给后端和前端的反馈。举例这个按钮是注册会员按钮,用户操作后,第一步逻辑是验证用户输入的信息是否合法,不合法则给出前端反馈;合法则和后端通信验证是否已经存在同样信息,已经存在则给出前端反馈,不存在则进入下一步,注册成功;注册成功后的反馈是跳转页面,还是弹出层提示用户完善资料,这些都是需要更详情的考虑的。当然这些更细致的思考是留在需求文档撰写时的,而此时我们需要做的就是把这些元素通过原型表现出来。

原型设计的表现手法主要有三种:手绘原型、灰模原型、交互原型

1、手绘原型

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

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

2、灰模原型

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

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

3、交互原型

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

通常情况下交互原型是产品经理与交互设计师共同讨论确定,然后由交互设计师制作,但是绝大多数的公司是没有交互设计师这个职位的,因此这类工作最终是由产品经理来负责的。(很多公司给视觉设计师的职称是交互设计师,但本质还是视觉设计)

关于Axure PR制作交互原型我在这里就不多介绍了,网络上有很多这类的教程,我个人建议是学习Axure PR时,随便了解一下网站模板的结构,这样可以帮助你更加结构化使用Axure PR。(推荐一个我之前画的原型,网站已经关了,原型当时设计的也比较简陋,有很多缺失的页面,仅供参考看看。)

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

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

时间: 2024-10-05 04:45:04

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

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

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

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

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

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

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

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

我们将概念想法形成了信息结构,罗列出了产品的所有信息内容,现在我们就要依据信息结构,开始规划产品的功能需求,绘制出产品结构图和用户流程图.首先我们要规划出产品的频道及子频道.子模块或子页面.(如下图) 图注:讲解一下我对于这个思维导图的名词理解1.频道:某一个同性质的功能或内容的共同载体,也可称为功能或内容的类别.2.子频道:某频道下细分的另一类别3.页面:单个或附属某个频道或分类下的界面4.模块:页面中多个元素组成的一个区域内容,可以有一个或多个,也可以循环出现(例如:文章列表)5.模块元素:

【产品】好的产品需求文档(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文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前四篇文章进行整体的摘要介绍,帮助大家快速了解写作流程. 产品需求文档(PRD)的写作 四篇章:1.写前准备(信息结构图)2.梳理需求(产品结构图和用户流程图)3.原型设计(手绘原型,灰模原型,交互原型)4.撰写文档(PRD文档)5.用例文档(UML用例图.流程图) 1.写前准备(信息结构图):http://tangjie.me/blog/52.h

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

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