原型图和prd-原型设计与PRD入门

相信做产品的对原型图和prd都是再熟悉不过的了,虽然说这两个“技能”不能说是做产品中最重要的两项,但是一定是做的最多的两项之一。这两点虽然非常基础,但是也不是那么容易做好的。来到公司之前我自己做过两个产品的prd和原型图,第一次是在学校团队做的社交软件。那时候写prd的时候没有模板,竟然也没有想过去找一个模板参考一下,当时就凭着感觉自己摸索了一套逻辑先写着,然后给团队里的研发小伙伴看,他们说能看懂我表达的意思就是OK的。那时候的原型图更是简陋,直接用墨刀整了个“草图”,虽说是草图,但是基本上整个风格和UI的图都是我找的,然后就直接用上了。后来去公司实习了,公司规模不大,prd有一个模板参考,但是不是很详细,我硬是把自己觉得更详细的prd(就是我自己摸索出来的那一套,现在看来就是“根本不能用!”)给带我的人看,可能他也觉得我写的比公司的详细,于是让我比对着公司的模板加入了自己的想法。当时我去之前是一个程序员画了原型草图,大家可想而知,那效果!然后我就在程序员面前摆弄了一番墨刀原型,在他眼里,我画的可美了(说明一下,那个部门第一次做APP,所以当时只有程序员,还没有产品)。就这样,自我感觉原型和prd做的还不错的我就来到了现在的公司.......整天被师父说“prd写的不全面,加,加,加!!!!”“原型图画的太丑了,改,改,改!!!”在此,我还是非常感谢师父的高要求,让我学到了不少(刚刚还在喷我文章写的,啧啧啧)。那接下来就来说说自己学到的如何写好prd和画好原型图。

Prd篇

一份完整的prd要做到全面:除了让程序员,UI和UE能完全看懂要做什么,要怎么做(逻辑要非常清晰),还得考虑到和产品,功能相关的所有边缘情况。说的通俗一点,就是让人在能找到所有与需求相关的东西的情况下还找不到任何可以拉出来扯皮的。因为产品狗要对自己的产品负责,你不做好就等着背锅吧。

一,首先从整体来看,要按功能模块来写。我以前自己摸索的是按页面来写,就是先描述这个页面是什么,有什么,有哪些控件,用户场景的使用流程是什么。一直以来我都觉得自己描述的又有逻辑又详细,一来就直接被师父否了。然而我并不是那么容易妥协的人,我得知道为啥我的逻辑有问题,你的好在哪。于是师父拿出了他经常说的“你居然敢质疑我!”说完之后就开始详细解释了:按照页面来写,如果不同页面功能有重合怎么办;其次按功能写是一个逻辑流,如果按页面来就会漏掉一些关键点,因为它没有一条清晰的线;最后很多控件不是我们设计的,是UE设计的,我们只需要把逻辑说清楚,不要抢别人活。好吧,我觉得说的很有道理,但是打翻自己的逻辑重新树立一套逻辑还是不容易的,所以当时琢磨了好久才能按照师父教我的逻辑梳理文档。

二,从细节来看,主要记录三个重要的方面

1,需求说明/修改:说明为什么做/修改这个功能。最开始写这部分的时候我很容易就写成了这是什么功能,为了让用户怎样怎样。后来在师父的点拨下才了解到是站在公司产品的角度上写为什么要做。知道为什么吗?因为程序员总是质疑产品,这个功能为什么做,意义是什么。(潜台词是:能不做就不做吧,我们事多着呢)

例子:当前防蹭网功能只能对已经连接过路由的设备进行“加入黑名单”的操作,并不能对尝试攻击网络的设备进行真正的预防。

2,功能描述:说明用户可以做什么操作以及可以看到哪些内容

例子:

(1)进入到防蹭网的已连接页面可以查看已连接设备的信息:①设备名称,②接入时间,③接入网络类型,④接入次数,⑤总陌生设备数和总接入次数

(2)点击对应设备进入详情页面;

a.可以查看信息:①设备使用历史流量曲线图,②设备上下线时间,③设备使用总流量,④设备总连接时长。

b.可以进行的操作:①标记为家庭设备,②加入黑名单。

(3)进入黑名单列表,可以查看/移除已被加入黑名单的设备。

3,约束性描述:说明整个功能描述里面相关的规则,主要有显示规则,字段规则,防呆规则。这部分相对来说比较难,因为很多点都不容易想到。除了这些,还有很重要的:异常情况怎么处理,极值是怎样的,显示内容及其格式应该是怎样的。

例子:

1.设备列表显示规则:

a.已连接的设备列表为已连接的陌生设备,即不包括本机和家庭设备。

b.可显示/编辑在线设备和离线设备。

c.列表页最多有50台设备,当设备数超过50台以后,按时间顺序自动删除。

d.当前无陌生设备接入时显示:无陌生设备接入网络。

2.设备列表字段规则:

a接入次数:每次下线后再上线连接为1次。

b.接入次数超过99次显示为99+。

3.总陌生设备数和总接入次数:

a.按接入设备和设备接入次数的总和计算。

b.接入设备最多为50台,接入次数超过99次显示为99+

在开始写的时候很容易犯的错是将功能描述和约束条件弄混淆,但是弄清楚功能描述主要是站在用户的角度写的,约束条件站在开发的角度写的,多写几次修改修改就会好很多。

原型图篇

关于原型图其实能说的不多,因为每个人的审美不同,但是有些细节需要提一下。

1,这个也要根据公司的情况而定,比如公司有UI和UE的就不用特别注意美观,重点就应该放在重要的元素,完整度,逻辑清晰。反倒应该以简洁的界面为主(不要加入自己的设计想法,会误导别人的)。因为这时候我们的“用户”是UI,UE和开发,让他们理解有什么元素,怎样看的清楚最重要。如果在公司没有UI和UE的情况下,就需要注意界面的美观和交互了。

2,细节,比如去掉Axure里面那些控件的边框,对齐,颜色统一。

3,标注,prd里面很多重要的约束条件标注在对应的页面会更方便程序员开发。

4,没有时间就不要做酷炫的交互了,因为没用,没人看。甚至可以不用做交互,只需要有逻辑的把页面画全就好了。

其实不同的公司有不同的架构,所以对需求文档和原型图的要求是不同的,不过不管要求如何,都一定想清楚自己写文档的逻辑。还有逻辑也是可以优化的,不能死守自己的那一套逻辑,不好的就要改,让自己一直有进步。都说新人得踏踏实实做好手头上的事,所以看似很简单的文档和原型图就需要我们多用心做好,做好这一步了,基础就打踏实了,然后朝着寻找更好的需求努力!

prd文档是指产品需求文档,而产品需求文档是将商业需求文档和市场需求文档用更加专业的语言进行描述;prd的主要使用对象包括开发、测试、项目经理、交互设计师、运营及其他业务人员。

该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。

广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

原型和PRD是产品经理的主要产出物,和上一章功能和流程是紧密相关的,可以说他们是功能和流程的可视化。

原型和PRD绘制时有一些技巧和规律可循。其中很重要的一部分是工具的使用,聪明的大家去摸索一下就会很熟悉

eg:

后面以这样的一个需求作为案例讲解:

这是上面产品的业务流程:

创建优惠码,后台的页面流程:

一般来说,后台的页面流程时间充沛的时候才去做。

使用优惠码:

最后用户的流程是这样的:

上面的流程得到的结果是这样的

回到产品画布,原型所处的位置,在产品分析过程中,最有可能出现的地方是解决方案的这个地方,因为原型就是解决方案的一种呈现,在工作流中,原型在需求评审和研发测试的时候发挥作用。

简单来说,原型承载了解决方案的细化和落地.

所谓的虚拟概念,就是需求和问题的转化,得到一个具体的方案。然后以产品原型的方式呈现

非常推荐手绘原型,因为它很容易修改。一般情况下,你是用纸和笔画原型的时间要占到你整合原型绘制过程中的80%的时间。

原型的绘制关键是人,至于工具,选一个自己用的顺手的就可以了。

我们在基本方案确定之前,采用手绘,这样的方案效率是最高的,成本也是最低的。

好多人认为需求文档很没有用,因为都没人看写了没有成就感,对项目也没有帮助。

实际上需求文档除了评审会议时,协助内部沟通外,它更重要的是存档的作用,它能让需求有据可查,交接更容易,更职业,跟进者了解之前的做法和过程。

三节课官网需求文档

--

这是我在学习产品能力的第10篇学习笔记。欢迎拍砖。

产品学习笔记总目录