高效产出PRD的“三不”原则

文/一井

现在业内对于产品需求文档(PRD)普遍认同的交付形式是Axure的原型+文本,当然你也可以说是Sketch或者PPT等形式,不论是哪一种,都是用可视化替代Word(喜欢看文本的程序员可能是假的)。

本文仅陈述个人对于产品需求文档的看法。

一、PRD的主要构成

1.概要

文档变更记录(版本迭代、版块及功能说明、记录人等,其实就是简化版的功能需求清单)、全局规则说明(升级逻辑、异常逻辑、交互说明、输入限制…)、名词解释(积分、金币、白银会员…)

2.业务说明

产品功能主框架(功能/信息结构图、业务结构图/流程图、一级页面流转图)、权限说明表(角色权限、数据权限、功能权限)、页面交互/功能模块元素构成、规则说明

3.原型图

各页面的线框图、基本的交互形式、文本注释(缺省状态、字段名称、流程说明、等待时长说明…)

4.非功能性需求

地理位置获取、Push推送机制、敏感词过滤、CDN缓存策略、本地文件存放策略…

如果这是产品的第一个版本,则需要在产品的功能结构、业务流程等逻辑层面上花更多的时间去说明,一方面降低与开发人员、项目经理、UED团队等沟通成本,让整个团队快速理解并取得认同,另一方面作为证据和备份,在后期产品开发出现偏差时能及时调整复位。

二、抓住本质的“三不”原则

1.不做高保真

通常喜欢做高保真的产品汪都是在设计方面有一定基础的强迫症,把所有视觉细节和交互特效都堆砌上去,如果是拿出去给外人做展示、给用户做测试,效果自然很好,但通常我们做原型只是为了内部的沟通交流。

在产品规划初期,如果做高保真原型,一旦在评审或后期讨论中遇到需求变更,修改的成本非常之高,严重影响到产品的设计及开发进度。更何况身为产品把原型做成高保真,让团队中的UI情何以堪,是沿用你的风格还是自创一套呢。

所以通常情况下,只需要用线框图将功能架构表示出来,一旦核心功能确定下来,线框图的设计是非常快的,做完一稿立马就能跟大家探讨,制定修改方案,反复几次后就能把产品的设计思路梳理清晰,随后UI和开发人员才能快速跟进,减少后期需求大变更的风险。

换句话说,产品的设计流程应该符合用户体验五要素:战略层→范围层→结构层→框架层→表现层,此时此刻如果产品负责人把精力花在页面的呈现效果上,就会缩减其在战略、范围、结构上的考虑,本末倒置容易把产品带进沟里。

2.不写废话

在产品进行评审的时候,开发人员常常会提各种各样技术角度的问题,比如“数据从哪来?”“这里有几种角色?几种权限?”最后问题及目标都搞清楚了,散会。结果到了具体的开发环节,他们又会来问你相同的问题,“这个角色能看到这些数据吗?”所以在需求文档中把关键性的逻辑用文本/图表展现出来是非常重要的。

但如果所有功能比如返回跳转都要说明清楚的话,文本内容会非常多,开发人员依旧是没有耐心看的,因此要精简产品文档中的注释,少写废话。

比如一些你我皆知甚至是用户都了解的规则,就没必要写在原型图上了。比如“密码显示***”,“若用户没有输入密码,点击登录时则toast提示用户未输入密码”,这样的文本说明纵然很细致,但确实是白写的,而什么内容是有必要的呢?

比如你需要在输入框右侧设置密码可见的切换按钮,或者说明输错三次之后当日无法登录的规则,又比如对账号密码有特殊的格式限制等等,这些才是开发人员不知道的设计思路,需要你在文档中详细告知。

如果你跟团队成员已经有了足够默契,即你知道对方的开发习惯,对方也了解你的设计套路,那么即使你没有说明“点击删除时弹出模态对话框以确认操作”,开发人员也会很自然地把这个反馈加上,如此一来,团队的内部损耗就降到最低,产品的规划、迭代都会进入高效运转的状态。

相信我,就算你把PRD写得极其精炼,团队成员也不一定会完完整整地看完,更要命的是,即使他们都遍历了一次,也会忘记其中的一部分,只要他们忘了就必定认为是你没写…(其实自己写的,自己也会忘)

3.不重复创作

全局都统一的逻辑就在全局中说明规则,没必要在每个页面中嵌套,不要重复发明车轮,这可以帮助我们省很多时间。

比如手势操作、网络异常情况、输入限制等,有些是可以直接复用的,有些可以在原来的基础上根据产品性质再调整,就像设计师的素材库,产品经理也可以积累一套自己专用的控件库。

不重复创作还体现在设计风格、版式上,很多人都执迷于原创,拒绝抄袭现有的类似产品,其实完全没必要,理论上来说,不存在跳脱于现存所有设计的设计套路,所以还不如多看多抄。

还有一个更重要的原因是,如果已经有一款竞品打开了市场,抢占了用户的心智,培养了用户习惯,此刻最该杜绝的就是独树一帜,试图挑战用户的操作习惯,除非找到了用户新的痛点,设计一个全新的功能,比如Snapchat的阅后即焚,不然就应该遵守已逐渐固化的交互形式,尽可能降低用户转移过来的成本。

所以支付宝的聊天界面几乎是像素级复制了微信,所以共享单车的操作流程及页面都近乎一致,从用户体验上来说,这样才能体现出关怀。

微软就是因为培养的用户习惯根深蒂固,所以每次大升级都要付出巨大的成本,遭受用户长时间的质疑和抵制,纵使操作体验确实更好,但在用户看来就是关怀不够,还要花时间重新适应。

三、写在最后

简单来说,拒绝高保真、拒绝废话、拒绝重复,把自己的时间花在产品的核心驱动力上,减少对无用功的投入,降低单调重复的操作频次,才能保证高效产出有价值的牵引力。

做产品如是,个人成长亦如是。

END.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容