图示干货:用Axure做一份团队成员都爱用的“RD产品”

这是一种思维方式的转变:产品经理把文档看作是一个产品,那么基于这个产品的用户需求,可以进行不断的优化,从而让各种RD成为团队成员用户都喜欢用的产品。

对于PM而言,应当把文档看作是一种“半成品”:

和最终产品一样,文档也是有“用户”的;

MRD和BRD的用户,是公司的董事会或项目总负责人;

而PRD的用户,则是UI、交互和程序等;

——关键是不同的文档,和其他产品一样,最终目的都是要让“用户”用起来,而且最好用得舒服,体验不错。

而目前的各种文档,其实更多的是一种“形式主义”:

MRD和BRD言辞空洞,经不起推敲,有的项目甚至直接跳过;

因为很多项目本身,经不起严格的“M+B”的可行性论证!

事实上,要做好M+B可行性论证,甚至要用到MBA的案例分析的技能。见下图:

当然,有些老总或许只是灵光一闪,拍拍脑子,就要开始做一个产品。

然后让产品团队直接开始“模仿”市场上的成功产品,美其名曰“微创新”!

其实真正的潜台词是,“别人已经做了,我们也跟着做吧”。

所以很多时候,连人家为什么要做那些功能按钮都搞不清楚,就已经开始做了。

在我看来,真正的微创新,是要在理解产品的基础上,进行“迭代更新”式的跟进。

所以,一份好的M+B文档,应当是以一系列的市场和商业问题为导向的,并且需要作出严谨的“可行性”结论的。

接着说PRD:目前的PRD,可谓又长又臭,团队成员宁愿看看原型图,不懂的张口来问,都不愿意翻看“加长版”的PRD。

套用一位资深产品经理的话说,PRD目前的主要用途是“秋后算账”用的。

那么,PRD的用户在使用这个文档产品的时候,遇到了什么问题呢?

不外乎是“查找麻烦、相对不方便和废话太多”三点。

所以,作为这个文档产品的创造者,就有必要考虑进行相应的改进:1.让查找更方便;2.减少废话,说重点。例如以问题对答的方式,来写这个文档。

综合以上,使用Axure做一份产品工作文档,可以很好的解决以上的问题。

——起码在形式上,能更加准地确聚焦问题,最最关键的是,方便团队成员查找和使用,摆脱“交流基本靠吼”的囧境。

将所有RD进行汇总,见下图:

我做的这个模版,是采用Axure,把产品涉及到的文档汇总在一起,团队成员可以根据自身的工作需求,点击不同的板块,并快速查找到相应的问题所在。

当然,可以根据团队工作的需要,增加相应的板块,如在这份“模版”里,我把重点难点另外摘出,方便用户(团队成员)查找:

同时,将会议进行一个汇总和备忘,方便与会人员随时查看和审查各自需要落实的会议议项。

当然,领导也可以很方便的看到会议的大致状况,了解到项目的一些问题。

最后要说的是,我做的这一份模版,提供的是一个思路——产品的核心,还是用户需求本身。就产品的各种文档而言,最基本的需求就是“好用、简洁、快捷”。

个人认为,要做出“有想法”的产品,首先要保持思维方式的灵活性和开放性,包括对身边的一些人、事和物的全面改进。

别奢望那些严守传统、思想保守的人,能干出突破传统、创新的产品。

所以,这是一种思维方式的转变:产品经理把文档看作是一个产品,那么基于这个产品的用户需求,可以进行不断的优化,从而让各种RD成为团队成员用户都喜欢用的产品。

文:何为贵 微信18859475153,欢迎朋友们留言交流。

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表