大师网-带你快速走向大师之路 解决你在学习过程中的疑惑,带你快速进入大师之门。节省时间,提升效率

产品人必知必会的“增删查改显算传”(内附案例)

作为产品人,PRD是工作中的一大块重要内容。而关于PRD的生产/搬运(copy)过程,大概可以套用《同桌的你》:

明天你是否会想起,好容易做的原型设计

明天你是否会惦记,评审会上被围攻的你

开发们都已想不起,经常改需求的PRD

我也是偶然翻日记,才想起有漏洞的设计

是的,PRD功能完整、逻辑正确永远是产品人头上的两座大山。这带来了无数撕逼的日夜——从来不曾忘记,而且时常想起……

而保证PRD功能完整、逻辑正确的有效方式之一,就是熟悉“增删查改显算传”。

“增删查改显算传”是什么鬼?先来看看所谓“增删查改”,维基百科如此解释

Incomputer programming,create, read, update, and delete(as anacronymCRUD) are the four basic functions ofpersistent storage.

在计算机编程中,增删查改(CRUD)是永久存储的4种基本功能。

度娘了一下“增删查改”,能明显地看出这与编程的关系。


维基百科还有解释:

CRUD is also relevant at the user interface level of most applications.

增删查改也与多数应用的用户界面设计相关。

为什么“增删查改”能保证PRD功能完整?因为这4种功能太基础了,维基百科如是说:

Without at least these four operations, the software cannot be considered complete.

所以,“增删查改”是研发常常需要考虑的,也是保证界面设计的完整性的。如果在这方面考虑不够全面,可想而知的是,在原型评审与后期开发时,必然会遇到很多问题。再加上PRD更改起来常常是牵一发而动全身,这就蛋疼了……

所以,“增删查改”是必须考虑的,也是必知必会的。“增删查改显算传”,则是前者的升级版。

当然,核心中的核心,仍然是用户+需求+场景,即所谓PSPS。因为这才是PRD的来源,是战略层的内容。很多页面不一定符合“增删查改显算传”,这就是需求决定的。正如巴顿将军曾说过:

Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.

永远不要告诉别人如何做,而要告诉他们做什么,他们会给你带来惊喜。

这里就不过多展开了,将来再聊(要离题了)……

So,以用户+需求+场景为核心,再辅之以“增删查改显算传”,就能打造出一款功能更完整、逻辑更正确的PRD。注意:“增删查改显算传”属于范围层,而“用户+需求+场景”属于战略层,前者从属于后者,切不可打乱顺序。也就是说,在考虑“增删查改显算传”时,必须以“用户+需求+场景”为基础。例如,实际工作中,在设计功能结构图、信息架构图时,不能以“增删查改显算传”为前提,这样就容易本末倒置。比如我之前就犯了这样的错,在设计信息架构时,竟然是这样的,往事不堪回首……

不过,说了这么多,“增删查改显算传”到底是什么鬼,似乎还是有点模糊,那下面我们就直指本质——看看在编程语言上,“增删查改”到底是什么。看下图:



其实从上图中“增删查改”的英文名,以及“增删查改”的中文名(中文的“查”还是容易误解),就能猜出其大致含义。再结合SQL语句的解释,就能更准确地把握“增删查改”。

为了更全面地描述“增删查改显算传”,也为了体现其全面性,这里就将那著名的、能弥补漏洞的“5W2H”糅合进来,给“增删查改显算传”来一个全息展示:


图不给力,拆成2张更美丽:



仔细看看上图,看起来挺多,其实还透露了更多:

1.上图其实体现了用户+需求+场景的思想;

2.上图也说明了“增删查改显算传”为何能保证功能完整;

3.“增删查改显算传”、5W2H都不能保证绝对完整,但相对而言,都已很完整。这也从侧面说明了PRD有多完整。

当然,而我们要做的,就是既要考虑“增删查改显算传”,又要考虑其鞭长莫及的地方——如上图你所见的地方。

到此,我们已经很接地气了。但送佛送到西,不妨更接地气一点——举个栗子好了:

下图是全民应用微信的通讯录页面。


增——很明显的,右上角是“增”,可以加好友、公众号、扫码等等。

删——删除联系人的功能层级较深,需要进入联系人详情页,再点击更多操作才能看到红色的删除按钮,这就是“用户+需求+场景”的考虑了,当然也可能有其他考虑——这可能反映了微信不不鼓励用户删除好友,正如不鼓励用户发文字状态。

查——这个功能就更为明显,也更强大。页面顶端的搜索框,就是明晃晃的“查”。这里吐槽下:搜索框右边多出那一块干嘛,不影响美观吗?都好几个版本了也不改改……

改——左滑修改,这里不特别说明了。

显——这个页面的图标、文案、排列顺序、交互等等,都可以视作“显”。值得一提的是排列顺序,这是写PRD时需要考虑的。下图的通讯录,就是按照姓名首字母顺序排列的。

算——在本页中,体现得最明显的地方就是底部的好友数量,如下图。微信好友数上限是5000,这也是“算”的体现。当然,“算”与很多计算规则有关,下图的数据也涉及计算规则,再比如微信中常见的如朋友圈点赞/评论数的计算规则、文章浏览量计算规则等等。


传——这是难点。在微信里,一个明显的案例就是聊天:你发信息,别人收到了,这就是“传”。而“传”也是容易出错的地方,例如下图中,删除已设定的通讯录的标签,删除时是否要提示?已经使用的标签能否删除?删除时数据如何传递?这都是需要考虑的内容。当然这里微信做得比较简单,能直接删除,而且没有提示,这当然也是因为“用户+需求+场景”,因为这个功能对于多数用户而言并不重要。而假设换一个场景,换一种用户,标签的分类功能变得非常重要,这时就不能随意删除——必须提示,甚至已使用的标签不能删除。而“传”由于其牵一发而动全身的特性,就可能会使得PRD的一些细小更改变得障碍重重,这是难点,也是必须踏过去的难点。

再结合之前总结的思维导图,这里还要考虑用户的数据权限——什么用户能看到什么内容。比如通讯录,我就不能看到你的通讯录(张小龙能不能看到我的,这我就不知道了……)。再比如发朋友圈,你屏蔽了一些人,那些人就不能看到……


其他的就不继续罗列了……

怎么样,这样梳理一遍是不是清晰了一些?总结起来:以用户+需求+场景为核心,再辅之以“增删查改显算传”,就能打造出一款功能更完整、逻辑更正确的PRD。