产品经理-先需求文档还是先原型
2013-09-11 15:25
956 查看
这个问题比较复杂,需要分开来谈,首先说明下需求把它分为用户原始需求,产品需求,软件需求;对于原型我们思考将其分为低保真原型如手画草稿和高保真原型( 包括体现了核心交互设计)。
如果是在企业内部或企业信息化软件,一般是首先能够收集到用户原始需求,我们根据用户原始需求进一步整理为产品需求。这个需求文档是在前的,产品需求里面核心内容即产品架构,产品组件和核心功能说明等。有了这个后我们一般会先开始画原型,这个时候是偏高保真原型,有了原型后再开始写软件需求规格说明书,在写需求过程中发现原型有缺陷会进一步对原型进行调整。可以说软件需求和原型基本是相互促进和完善的过程,中间有很多细小的交叉迭代,但是一般情况下还是原型在先。
简单总结下就是用户需求和产品需求在先,(原型+软件需求)多次迭代完成。
如果是互联网行业,可以看到很多时候很难拿到完善的用户需求并进一步整理为产品需求。如果从产品经理层面来说,很多时候是你有想法想做一款产品,或者说更高的领导给了你一个产品构思让你去考虑是否可以研发为有价值的产品。
在这种情况下我们看到产品需求或者说更粗点的叫产品方案一定是在先的,产品方案或PRD毕竟可以更快的输出转化为文档。有了产品方案或PRD才容易进一步决策这个产品是否做。要知道在这里做这个决策跟原型一点关系都没有,更加重要的是产品能否吸引用户带来用户价值。如果这一点都过不了,根本就没有必要在原型上多花时间。这个时候的产品方案更多用于决策,里面包括了PRD的内容,但是可能并不是很细化。
所以对需要快速响应的互联网行业,产品方案在先用于决策。其次再考虑详细的产品需求和原型哪个在先的问题。这个时候其实没有完全必要的先后顺序,我们可以这样理解,即经验丰富或结构化思维能力强的,需求和UI分工细的,一般会先完善完整的PRD,再交付到其它岗位去做原型。而对于新产品我们都还在探索阶段的,则一一定是先原型,通过不断的原型细化来准备把需求想清楚。要知道做原型很多时候就是在细化需求。做原型细化需求更是以用户驱动的方式。
很多时候我们看到由于产品需求和原型思考结合的太紧密而很难将工作分给两个人做,这个时候往往是产品经理全部一起做,那么这个时候原型可以理解为偏低保真的原型,可以手工画的,也可以是axure画的,只要能够和需求完全结合起来,把想到的需求完全通过原型验证满足即可。
低保真原型后,产品经理可以根据低保真原型详细的定义产品需求和软件需求。而低保真原型可以交付专门的交互设计团队转化为高保真的原型。两者可以并行做,做后可以进一步在高保真原型基础上严重已经细化后的所有需求是否都可以得到满足。
最后,没有必要太多考虑谁先谁后问题,但是要意识到原型是帮助我们思考需求,细化需求的重要手段,画原型的过程往往就是需求细化的过程。
如果是在企业内部或企业信息化软件,一般是首先能够收集到用户原始需求,我们根据用户原始需求进一步整理为产品需求。这个需求文档是在前的,产品需求里面核心内容即产品架构,产品组件和核心功能说明等。有了这个后我们一般会先开始画原型,这个时候是偏高保真原型,有了原型后再开始写软件需求规格说明书,在写需求过程中发现原型有缺陷会进一步对原型进行调整。可以说软件需求和原型基本是相互促进和完善的过程,中间有很多细小的交叉迭代,但是一般情况下还是原型在先。
简单总结下就是用户需求和产品需求在先,(原型+软件需求)多次迭代完成。
如果是互联网行业,可以看到很多时候很难拿到完善的用户需求并进一步整理为产品需求。如果从产品经理层面来说,很多时候是你有想法想做一款产品,或者说更高的领导给了你一个产品构思让你去考虑是否可以研发为有价值的产品。
在这种情况下我们看到产品需求或者说更粗点的叫产品方案一定是在先的,产品方案或PRD毕竟可以更快的输出转化为文档。有了产品方案或PRD才容易进一步决策这个产品是否做。要知道在这里做这个决策跟原型一点关系都没有,更加重要的是产品能否吸引用户带来用户价值。如果这一点都过不了,根本就没有必要在原型上多花时间。这个时候的产品方案更多用于决策,里面包括了PRD的内容,但是可能并不是很细化。
所以对需要快速响应的互联网行业,产品方案在先用于决策。其次再考虑详细的产品需求和原型哪个在先的问题。这个时候其实没有完全必要的先后顺序,我们可以这样理解,即经验丰富或结构化思维能力强的,需求和UI分工细的,一般会先完善完整的PRD,再交付到其它岗位去做原型。而对于新产品我们都还在探索阶段的,则一一定是先原型,通过不断的原型细化来准备把需求想清楚。要知道做原型很多时候就是在细化需求。做原型细化需求更是以用户驱动的方式。
很多时候我们看到由于产品需求和原型思考结合的太紧密而很难将工作分给两个人做,这个时候往往是产品经理全部一起做,那么这个时候原型可以理解为偏低保真的原型,可以手工画的,也可以是axure画的,只要能够和需求完全结合起来,把想到的需求完全通过原型验证满足即可。
低保真原型后,产品经理可以根据低保真原型详细的定义产品需求和软件需求。而低保真原型可以交付专门的交互设计团队转化为高保真的原型。两者可以并行做,做后可以进一步在高保真原型基础上严重已经细化后的所有需求是否都可以得到满足。
最后,没有必要太多考虑谁先谁后问题,但是要意识到原型是帮助我们思考需求,细化需求的重要手段,画原型的过程往往就是需求细化的过程。
相关文章推荐
- 产品经理应该先写需求文档还是先画原型?是应该正向思维,还是逆向思维?为什么?
- (10.3.1)产品经理应该先写需求文档还是先画原型?
- 产品经理应该先写需求文档还是先画原型?
- 产品经理应该先写需求文档还是先画原型?
- 产品经理应该先写需求文档还是先画原型图
- 产品需求文档PRD的写作(三) – 原型设计(手绘原型,灰模原型,交互原型)
- 产品经理之产品需求文档PRD-全栈工程师熊盼
- 产品经理的PRD产品需求文档
- 产品需求文档写作方法(二)原型设计+撰写设计
- 产品需求文档(PRD)写作(三) 原型设计(手绘原型,灰模原型,交互原型)
- 产品经理如何写PRD文档-产品需求说明书
- 需求是如何变成产品原型的:产品经理和交互设计师的对话
- 产品经理的MRD市场需求文档(怎么做)
- 产品经理与交互设计师的对话——需求是如何变成产品原型的
- 后端产品经理笔记:需求文档语法
- 产品经理与交互设计师的对话——需求是如何变成产品原型的
- 产品经理是如何把需求变成产品原型的
- 产品经理,你该如何做一份完美的需求文档?
- 产品经理的BRD商业需求文档(为什么要做)