基于Axure8.0的产品需求文档编写方法

产品需求文档

基于AxureRP的快速原型设计法确实可以提高提升用户演示的体验和原型设计的效率,产品经理、产品设计师或者是交互设计师在确认好需求,做完原型设计之后,都不可避免地要写产品需求文档或者是交互设计文档。不过一般都是大公司才会有交互设计师这个岗位,才会有交互设计文档档产出,而普通的公司都是只有产品经理、需求分析师、产品设计师或者商务分析师这样的岗位,这个岗位基本会包办了从需求收集,需求分析,原型设计,编写产品需求文档这样的一个过程,所以说小公司比较锻炼人,会练就全能的本事。

现在都讲究用工具来辅助工作,工具用得好,确实可以事半功倍,要是工具用得不好,那就只能自求多福了。原型设计软件的主要功能还是用来做原型的,那是不是原型演示完了之后就没有用了呢?这个我想有点工作经验的人都不会这么认为,当然我们还是可以发挥一下原型的剩余价值。大家都知道,如果一份文档里面可以图文结合,所描述的东西更加能够吸引人去阅读,也更加能够帮助别人理解。AxureRP所设计的原型支持HTML格式的浏览,相对于其他原型设计软件直接产出图片,AxureRP的原型既可以通过在浏览过程当中用截图软件来截图,也可以直接导出成图片格式,当然后一种方式更为繁琐,后面会详细说明为什么直接生成图片反而不方便。

一、使用截图+文字编写产品需求文档

这个方式其实就是截图,然后用截图+文字的形式来书写PRD文档,有人就说了,图片制作软件那么多,为什么非得用AxureRP来做原型,还得截图呀,这里有个已经使用AxureRP的前提:

1、AxureRP提倡快速原型设计法,可以大大减少原型设计的时间,这是选择使用AxureRP的一个原因;
2、AxureRP支持HTML格式的浏览,极大的方便了原型的演示效果,可以很清楚地告诉演示对象每个页面的跳转,每个按钮的操作效果,每个连接点击结果等,这是选择使用AxureRP第二个原因;

当然AxureRP的优点不止于此,原因可能很多,但主要的是这两个方面,这两个前提决定了我们当前都是使用AxureRP来做原型设计的,然后再讨论如果在已经使用AxureRP的情况再来优化截图写PRD的方法,否则就没法进行下去了。

1、为什么是HTML格式页面的截图而不是直接导出图片?这个从操作层面上来讲,导出图片的模式操作流程如下:

【导出为图片】-【打开word】-【选择插入菜单】-【选择插入图片】-【搜寻图片所在文件夹】-【选择图片】-【点击按钮】完成插入图片操作;

或者是下面这种方式:

【导出为图片】-【打开图片所在文件夹】-【选择插入图片并打开】-【复制图片】-【打开word】-【粘贴图片】完成插入图片操作;这个比上面的省一个步骤;

从HTML页面截图的模式操作流程如下:

【打开对象所在HTML页面】-【用截图工具截图】-【复制所截图片】-【打开word】-【粘贴图片】完成插入图片操作;

对比一下就知道,用截图的方式所需的操作步骤是最少的,也就是最能节省时间的,这里推荐一个截图工具:Snagit(下载地址),可以对所截的图进行一些简单的编辑,比如画个圈圈提示一下,画点箭头什么的。

2、基于AxureRP原型截图这种方式更能适应需求变化。大家都知道AxureRP是支持单个页面的修改单个页面重新生成原型的,不需要整体原型重新生成一遍,这样某个地方修改了,只要重新生成一下原型,然后再截图修改即可,而导出图片的方式AxureRP只支持导出主页和导出全部页面两种方式;

3、截图工具的辅助功能,上面也提到了,可以对图片做一些必要的处理;

这是截图+文字的模式,有了截图之后,编写描述文字应该就方便很多了,避免出现大段的文字。另外PRD编写一般都是有格式要求的,有些内容不能用工具来解决,一般一份PRD文档要包含以下这些内容:

1、概述部分:简单介绍一下产品的背景,产品的价值或者愿景,产品的简单介绍,一些预估的风险点,干系人,名词解释等等;
2、业务需求描述部分:定义好目标用户群体,业务流程图,业务架构图,脑图等等的介绍;
3、功能需求描述部分:这部分才是用到上面所述方法的点,每个功能点都可以用那样的方式描述;
4、非功能需求描述部分:与产品相关的一些辅助功能,性能要求、易用性要求等等;
5、接口描述部分:与外部有相关接口的需要在这个部分描述;
6、附录部分:培训信息、参考资料等,还可以有运营计划等等;

二、使用AxureRP自动生成产品需求文档

这点我在之前写AxureRP使用教程的时候有提到过,AxureRP是支持通过即定的word模板格式来导出生成文档的。不过使用这个功能对自身的要求是比较高的:

1、要对AxureRP所提供的注释功能非常熟悉,其默认提供的注释字段是国际通用的,并不适合中国国情,要根据产品和项目的需求进行修改和自定义。要了解组件注释和页面注释的使用方式,以及这些注释会出现在文档的什么位置等;
2、要在做原型设计的时候就做好注释的录入,每个组件的交互,前置触发条件,后置反馈事件,以及每个页面的功能说明等,这是一项细致活,挺耗时间的,和快速原型设计的要求不大相符;且万一在确认需求的过程当中需要修改的,这个维护量也比较大;
3、要熟悉word的格式排版设置,用AxureRP默认提供的word模板生成出来的PRD文档,估计不符合大多数公司的文档编写要求,如果没有要求的则可以直接使用,否则就得自己倒腾一个word模板出来,这个对word的功底要求较高,再就是还得熟悉AxureRP里面模板导入的机制和模板使用机制;
4、综上所述,这个功能虽然很强大但实际应用的较少,其实比较鸡肋,个人是已经放弃了,有兴趣的朋友可以深入研究一下,到时分享一下;

我目前基本上就是采用上面两种方式来编写产品需求文档的,在原型已经设计好并演示确认了的情况下,编写产品需求文档一般都比较快速,35页到55页之间的产品需求文档,可以在1天到1天半之内搞定。产品经理要在有限的时间内做更多的事,一是要充分利用工具辅助工作,二是要发掘一些新的方法,双管齐下,应该就可以找到适合自己的工作方式!

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://niubipm.cn/a/chanpinsheji/Axure/2018/0317/145.html