设计 / 产品

把大象放进冰箱的理由

. 5 min read . Written by seki

设计功能易,建立功能边界难,这一年来深刻体会到这一点。

想到一个段子,有人不小心把桌面快捷方式全删掉,以为自己电脑被清空了。那么,为什么我们不能在快捷方式中删除某个文件,而必须进入实体所在的文件夹中才可操作?从物理逻辑上来说,任何数据都可在任意位置被CRUD,但从概念模型来说,文件必须放在它在唯一的文件夹内,这是图形界面的物理隐喻,否则「磁盘」与「文件夹」等概念的设计意义荡然无存。

通过快捷方式对源文件进行CRUD?这种需求真实存在

然而任何刁钻的需求,都有可能在0.1%的使用场景中被提出,就像把大象放进冰箱,作为产品设计者下意识觉得这个需求有问题,却又不知如何反驳——这一问题在B端尤为突出,对用户提出的需求全盘接受后,产品的功能边界变得暧昧不清。

无法测量

更大的问题在于功能边界清晰与否无法被数据衡量,如果通过可用性测试进行衡量,往往会发现用户完成单一任务的效率甚至有所提高,在一切效率优先的原则面前,效率优先进一步变成万事皆允,产品设计师最终无法hold住概念模型。

解决之道

没有银弹,目前想到三个方向:

  • 对于抽象的实体,把功能做多,保持实体单一化

有些工具产品中的实体天生有着很自然的隐喻,例如微信的群——群聊意味着多人聊天,而且必须要把用户拉进群才能进行聊天,这一切都很自然。但并非所有产品都天生拥有这样自然的隐喻,尤其是B端,抽象的实体必然是很多的,比如云服务器的控制台,简直呵呵。

我正用来写这篇文章的软件Notion就是“实体单一化”很好的例子,这个笔记只有着两个明确的实体——「Block」和「Database」。Block十分抽象,但是功能很强大,它可以变成一段话、一张图片、一个page,page和page之间又可以互相嵌套,形成层级结构。Database就比较简单,可以像Excel(大概是最为人熟知的Database)一样处理数据,也可以像我一样,只是当做文章目录使用,这两种实体间形成互补,即便Block本身很抽象,但这个概念足够单一,用户久而久之也就理解了。

为什么Notion不用“页”这个清晰的隐喻作为基础实体,因为这样就做不出体验的差异化了呀。

  • Storytelling

Figma的团队会经常在博客里解释产品的一些特性,比如为什么一开始不做shadow spread,比如figma的行间距为什么和sketch不一样。但,为什么要在博客里解释这些东西,实际用户里恐怕只有1%会去读这些文章吧——我曾经抱有这样的想法,但后来意识到,去阅读博客的往往是最刁钻的“专家型用户”,而那些1%的需求也往往由他们提出,团队博客的这些文章起到了解释和安抚的作用。

这是不是B端“情感化设计”的一个好例子?顺便一提,用户反馈软件「腾讯兔小巢」默认就有“团队博客”的模块,可以看出产品经理对需求挖掘得很到位,如果能稍微解释下这个模块的价值就更好了。

  • 微服务化

这大概是软件工程给我又一个启发,所谓大道至简…学科的尽头都是相通的哲学。

举个小程序的例子——钉钉和LARK的小程序,就是“微服务化”的B端功能,我想现在“疫情报备”、“疫情地图”一定会是使用率较高的小程序,但2020年之前,一个办公软件几乎完全不会有这种需求,如果人类运气够好,2021年之后恐怕也不再会有这种需求,所以它们不可能是一个常驻功能。

微服务的价值并不只是“高内聚低耦合”,更重要的是它具有单独的生命周期,可以随需求的诞生而诞生,随需求的消亡而消亡,而基础功能永存。