做出高保真原型还需要再写 PRD 文档吗？
刚入行，好多东西都不懂，按我的理解PRD文档就是为了说清楚产品设计思路，既然这样，那么高保真原型能否替代PRD文档
按投票排序
高保真原型只为在沟通中更为直观的让UI，开发了解你的功能需求。内嵌的逻辑，细节，设计思维都还是得用PRD来讲清楚的。我个人认为：高保真原型只是一个沟通的桥梁，具象化需求。实质的逻辑还是得用PRD交代清楚。
让我来总结下我司产品设计流程发展历史 1.我没有来公司之前老板自己做设计和原型他的步骤是在笔记本上画wireframe和userflow,然后自己写html+css，设计基本就是用css在做 因为是在做自己的产品所以基本不需要和任何人沟通，只要在他脑子里过就可以了...2.后来老板太忙没时间自己做，于是他画wireframe和userflow，我来做mockup，他仍做html+css省了一部分时间，因为在和clients沟通的时候如果只用wireframe和userflow，客户是很难理解的，还是mockup更直观。我们用github来做everything，PRD就放在github issue里，clients可以看到所有工作记录，很多同事是remote work 也可以跟进进度。3.后来老板开始更忙，连html+css也没时间做，于是出wireframe+workflow，我做mockup，前段来implement。这段时期是最混乱的，老板一个人全包的时期，他直接一边prototype一边design，所以所有逻辑上的错误都可以及时被修正，而如果缺少了prototype环节，会出现非常多的漏洞，这段时间我司作品惨目忍睹。3.后来老板开始更忙，连html+css也没时间做，于是出wireframe+workflow，我做mockup，前段来implement。这段时期是最混乱的，老板一个人全包的时期，他直接一边prototype一边design，所以所有逻辑上的错误都可以及时被修正，而如果缺少了prototype环节，会出现非常多的漏洞，这段时间我司作品惨目忍睹。4.后来老板看不下去，建议我学前端，变成像他一样的全能选手，我拒绝了，我认为样样通实际上样样都做不好，还是应该分工明确，问题的关键在于设计师和前端的沟通工作没有做好，这是我的弱项，我不善于团队合作，性格内向，我能做出很好的mockup但是一旦到了implement环节，前端只能做出40%的效果，当时我司前端比较注重完成功能性，好不好看他们不在乎。5.后来我开始把mockup做的非常细，尝试把每一个步骤解释清楚，老板那边也不断给前端上课，告诉他们把功能实现是远远不够的，我们需要最终成品和mockup尽可能靠近。这段时期我们仍没有prototype，我只是在mockup里把flow做进去，还是会有很多漏洞，有些小漏洞前端就直接自己按自己想法改了，大的会沟通一下，但是离“无间合作”还差的很远很远，我当时就睁一只眼闭一只眼只要老板不提我就懒的折腾，因为害怕增加前端的工作量。6.我渐渐的发现prototype和PRD的重要性，prototype帮助自己输通逻辑，prd帮助团队沟通，而当时我没有找到一个好的做prototype的方式，所以注重把精力放在prd上到了这个时期，我们基本可以把工作到70分了，虽然交互上还有很多很多问题，因为没有prototype，很多交互/用户体验相关的工作我们其实做的很少很少,这也跟我们产品性质有很大关系，系统太复杂，对交互的重视就会降低，但我不认为做企业应用就要完全忽视体验，现状只是因为目前大多数企业应用的甲方只求吃饱，不求吃好。具体不清楚，我们不做国内客户，所以没那么多困扰。到了这个时期，我们基本可以把工作到70分了，虽然交互上还有很多很多问题，因为没有prototype，很多交互/用户体验相关的工作我们其实做的很少很少,这也跟我们产品性质有很大关系，系统太复杂，对交互的重视就会降低，但我不认为做企业应用就要完全忽视体验，现状只是因为目前大多数企业应用的甲方只求吃饱，不求吃好。具体不清楚，我们不做国内客户，所以没那么多困扰。7.目前的阶段，老板认为在做mockup之前可以先做prototype，所以我不参与phase1的制作，由前后端完成，先实现功能phase 1完成后开始做mockupphase 1完成后开始做mockup（左是prototype，右是mockup）（左是prototype，右是mockup）phase1中的一些逻辑不通的地方我们会在mockup环节试图一起改进，顺念做concept添加简单的新功能我也开始用marvel来做一些简单的prototype，用来检查自己是否有逻辑上的疏忽我也开始用marvel来做一些简单的prototype，用来检查自己是否有逻辑上的疏忽总之我觉得高保真原型和PRD都非！常！重！要！PRD比较简单，在sketch里画示意图，在github里逐条解释即可，就跟编辑这条答案这么简单，不断的edit解释清楚，理清纲要。prototype做起来比较烦，我实在不爱用axure，marvel和invision在核心功能上其实远不如axure好用，但贵在轻，可以导入sketch，同步dropbox等等，分享起来也比较方便，复杂的交互可以用AE，但我实在懒=_= ，其他的一切比较火的做prototype的主要还是偏重移动端，我也尝试过用keynote，但keynote也不是特别好用，还有我觉得很快就会有人去开发好用简单的软件出来的哈哈哈哈对了，之后有空我会把内容好好整理下放到专栏里去，速度很慢但敬请期待 英文版
当然需要了。需求文档除了具有让你详细定义需求外，还具有备档的用处。
需要你的产品理念 规划 策略 流程 目标等等都不是原型能体现的 而且 原型不利于测试
先明确一个问题：你写文档是做什么用的？隐含问题1：团队规模有多大？隐含问题2：开发流程是什么样？隐含问题3：产品多大？周期有多长？文档的作用一般来说有三个1 明确设计2 制作依据（技术&美术&测试）3 迭代参考在既定的需求下，你需要用确定的方案来满足需求这个方案要充分考虑到产品的大小，团队规模和开发周期同时，要由技术来实现，那就必须遵循技术的开发流程在不同的情况下，需求文档的样子是大相径庭的一般来说，互联网产品崇尚敏捷开发，快速建立原型快速体验快速提交反馈修改意见快速迭代在一个高效的开发节奏下，文档是赶不上开发的，因为你应该多花时间去思考和设计但这并不是说文档就可以不写，可以先做关键记录，然后回头补充文档即使文档比开发慢，也要补充文档，因为今后的修改也要有参考这就是为什么一定要写文档的原因再说所谓的高保真原型，这种原型更多的是用来辅助前端和美术做界面开发和功能流程开发用对于后端逻辑和网络状况处理的描述不如写文档来的方便比如说你要给每天第1个、第11个、第111个...第111111个登陆的用户发奖励，奖励内容是xxoo...这种需求你几乎没办法用高保真原型表述出来，或者实现代价很高，或者理解成本很高反而文档简单直观这样的功能实际上有很多，比如统计用户行为（并非所有的统计第三方SDK都提供），根据不同用户属性进行不同的行为（微信官方朋友圈广告）等等很多很多，基本都是非文档描述不清楚所以说，做产品写文档应该没有什么争议只要根据实际情况调整执行策略，把文档写的满足需求，不耽误开发，不影响合作，不给后续维护迭代制造麻烦，够用，好用，就可以产品赚了钱，扩充团队，美化文档~恩恩~
即使做了高保真的原型，也一定要写PRD。但是不一定就要用Word来专门写个文档，用写PRD的思路在原型上写，我觉得是最好的解决方案。1、为什么做了高保真的原型，也一定要写PRD？高保真的原型，只能表达UI和部分交互，而逻辑和一些分支条件的交互不能完全表达。举个例子：注册功能。这个页面算是高保真原型了吧：给不懂技术的领导看，这个页面估计还行，给不懂技术的领导看，这个页面估计还行，要是给开发前端UI测试看，这里还缺少大量的需求描述。一个完整的注册功能需求描述应该包含如下几个部分：1）逻辑规则。例如：手机号码长度11位、只能以13x开头、不能重复注册验证码重新获取时间为60s，验证码有效期为20分钟获取验证码后，未收到短信，可以获取语音验证码语音验证码获取流程2）交互规则。交互规则需描述“在什么条件下，给用户什么样的反馈”条件为各种事件，例如单击、失去焦点、鼠标移入、加载、刷新等反馈为各种展现，例如显示弹窗、关闭窗口、打开网页、文本框旁边文字提示等另外，一些信息展示的功能还需要描述数据规则，如文本长度，数据来源，排序规则等。2、为什么在原型上写需求？在之前的一个答案里（），我提到过，需求的描述方式有2种，一种是用例描述方式，一种是功能描述方式。而在原型上写需求，就是功能描述方式。在原型上描述需求有2个好处：1、产品在设计页面的同时，能迅速的把考虑到的需求细节以备注的方式在原型旁边表述；2、对于阅读者来讲，原型图+文字的描述更容易被理解。见过很多开发测试，在看PRD文档的同时，也会对照着原型看，因为PRD文档里面的截图+文字描述的方式看起来相对要费劲一些。总的来说，在项目时间允许的情况下，我是比较赞同做高保真原型的，它能更直观传达产品的想法，也更容易被别人理解。《启示录》一书作者就建议描述产品需求只需要高保真原型+注释就可以，完全不需要文档，以下是书中的一些观点：产品说明（需求）文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。高保证原型最大的优势是可以用于测试。与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一起创建原型。
线框图==框架PRD==逻辑
像阿三那种杂技练得再厉害有啥用？打起仗来分分钟药丸～～
看团队需要，开发nb沟通顺畅就可以不要PRD。不过最好还是补一下，原型图只是具象的通常以页面或效果为维度展示产品的一种表现形式。数据结构、产品框架、时序图、流程图等这些如果需要的话就要加在文档里备份的。
不一定。高保真原型有两个作用，一是帮助 PM 理清设计思路。对于新手设计师，设计时容易丢三落四，高保真原型需要考虑整体导航结构、内容、按钮、跳转链接…把这些都过一遍起码不会遗漏功能点，一些明显的矛盾之处也容易发现。不过对经验丰富的 PM，所有的细节都诚然在胸，这一点就不太重要。高保真原型的另一个作用是沟通，如果相关方对整个系统都不了解，那么一个高保真原型能帮助大家快速理解。不过如果相关方都对背景足够了解，那么原型也不是必须的。相对而言，文档的左右是描述原型里无法提现的内容，包括设计目标，数据预估，运营策略，一些原型图上无法提现的细节逻辑。因为画图的速度终归没有写文档快，所以对于能在文档上提现的内容，我本人更喜欢写到文档上。我个人的偏好是中低保真原型加文档，高保真原型由设计师产出。供题主参考。
已有帐号？
无法登录？
社交帐号登录详解产品需求文档（PRD） - 91运营网
详解产品需求文档（PRD）
PRD是英文“Product Requirement Document”的缩写，翻译为中文就是“产品需求文档”，主要用于完整描述产品需求，向研发部门明确产品的功能和性能。
PRD的面向对象是研发部门，用于向他们说明需要开发的产品功能和这些功能的性能要求。PRD质量的好坏，在很大程度上不仅直接影响着研发部门是否可以明确产品的功能和性能，而且在很大程度上决定了产品的最终质量。
NO.1 PRD的主要内容
一份完整的PRD文档主要包含两部分内容：一是对项目的介绍，包括项目概述、项目价值、项目背景等；二是整份文档的主体部分，对产品需求的详细描述，包括功能需求和非功能需求。
对于不同的公司、不同的项目类型，PRD包含的内容会有所差异，但一般来说，比较常见的PRD都会包含版本修订记录、项目概述、项目价值、项目背景、场景描述、功能总表、业务流程图、用户界面、功能描述、非功能描述、附录等模块。
下面是一份比较常见的PRD的目录。
1.项目概述
2.项目价值
3.项目背景
4.功能概述
4.1场景描述
4.2功能总表
4.3业务流程图
4.4 功能描述
4.5 数据监控需求
5.用户界面
6非功能需求
NO.2 产品功能的描述
用户界面和功能描述是PRD最重要的两个部分，用户界面主要是以产品原型作为载体，用直观图形的形式展现产品的功能，功能描述则是在用户界面的基础上，以文字的形式诠释产品功能的细节，使开发人员更清晰地明白产品功能性能的要求。
对产品功能进行描述，一般需要两个步骤：
第一，梳理产品功能描述部分的整体结构，有规律地将产品功能分成多个较小的功能单元，并确定描述的先后顺序。
比如，在产品功能具体的分解时，可以按功能在系统中的位置、按业务流程、按功能主次、按功能所处界面位置等进行分解。
第二，以用例的形式描述分解后的产品功能。
用例指的是在不展现系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。它的好处是可以将产品功能需求与产品设计彻底分离，不用考虑具体的系统设计与技术细节。
下面是一个关于旅游用例图的展现形式：
除了用例图，还需要一个与之对应的用例表，规范的用例包括用例名称、用例编号、角色、描述、基本流程、备选流程、异常流程、后置条件、备注等。
NO.3 PRD的基本要求
一份优秀的PRD文档应该满足五个方面的要求：完整、准确、清晰、简洁、稳定。具体如下所示：
在项目开发中，如果产品需求发生变化（这种可能性是很大的，但是一般来说，都会将需求变化放到下一版本中），那么在修改PRD的时候，也应该就修改PRD内容进行必要的确认。
NO.4 PRD的模板
很多公司应该都会有PRD模板，供产品经理参考。但我感觉，根据具体项目与产品功能需求的不同，产品经理是需要根据灵活情况进行修改的。比如，我们的产品经理在撰写PRD时，主要是围绕用户界面与功能描述展开的，很简洁，没有用到用例，但是以图文并茂的形式把产品功能介绍的很清楚了。
文章来源：微信公众号尹剑利（yinjianli88）
勾搭小编微信号yunyingba,加入91运营官方社群，会运营的人都在这里了产品原型文档(PRD)规范_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
产品原型文档(PRD)规范
上传于||文档简介
&&介​绍​产​品​经​理​使​用​的​p​r​d​文​档​规​范​。
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢