配合PRD思考的“增删改查显算传”

简语 操作
Create/Add
Delete/Destroy
Update/Modify/Edit
Read/Retrieve/Browse
Display/View
Calc
Transfer/Pass/Deliver

  • —— 右上角的“添加朋友”,可以雷达加朋友、扫码、手机联系人、公众号等等,顶中位置的“新的朋友”也有此效。
  • —— 删除功能层级较深,需要进入联系人详情页,再点击“更多”操作才能看到红色的删除按钮,这就是“用户+需求+场景”的考虑了,当然也可能有其他考虑:这可能反映了微信不鼓励用户删除好友,正如不鼓励用户发文字状态。
  • —— 操作左滑执行修改,已经形成用户教导,不再赘述。
  • —— 检索功能最为明显,也最为强大。页面顶端的搜索框,就是明晃晃的“查”。同时:搜索框右边多出小喇叭图标,即语音检索,两种检索方式集中设计,高度统一……
  • —— 界面上的文案、图标、排列顺序、交互等等,都可以视作“显”。值得一提的是排列顺序,这是写PRD时需要考虑的。下图中的星标用户、字母A-Z排序分别就是按照关注度、姓名首字母进行排序的。
  • —— 界面上体现得最明显的便是底部的好友数量。微信好友数上限是5000,这也是“算”的体现。当然,“算”与很多计算规则有关,下图的数据也涉及计算规则,再比如微信中常见的如朋友圈点赞/评论数的计算规则、文章浏览量计算规则等等。
  • —— 这是难点。在微信里,一个明显的案例就是聊天:你发信息,别人收到了,这就是“传”。而“传”也是容易出错的地方,例如上图中,删除已设定的通讯录的标签,删除时是否要提示?已经使用的标签能否删除?删除时数据如何传递?这都是需要考虑的内容。当然这里微信做得比较简单,能直接删除,而且没有提示,这当然也是因为“用户+需求+场景”,因为这个功能对于多数用户而言并不重要。而假设换一个场景,换一种用户,标签的分类功能变得非常重要,这时就不能随意删除 —— 必须提示,甚至已使用的标签不能删除。而“传”由于其牵一发而动全身的特性,就可能会使得PRD的一些细小更改变得障碍重重,这是难点,也是必须踏过去的难点。