设计协议，而非只设计产品

date

Apr 3, 2024

slug

20240403

status

Published

1.

设计产品的时候，很像是在设计某种建筑 —— 这里是卧室，这里是走廊，那边是电梯间等等。当你满怀欣喜地将产品发布上线之后，发现许多用户并不会按照你规划中的样子来使用产品，然后提出诸多反馈，希望你来修改建筑。

比如一个用惯了 word 的用户使用 flomo，会觉得缺少许多排版功能；而一个经常写日记的用户，会觉得为何不能修改发布时间。

说到底，交通本身不仅仅由道路构成，还由众多不同目的的司机驾驶者汽车，在道路管理条例的约束下，达到自己的目的。从这个角度来看，拥堵更像是附着在道路上的某种协议。

2.

同样，产品亦是如此。如果在设计的时候，仅仅着力于功能的设计，而忽略了对于协议的设计，就会导致用户使用产品时没有明确的预期，摩擦变得巨大，继而产生诸多副作用。

一个很明显的观察是，当我们写的《笔记的方法》发售之后，因为看过书而使用 flomo 用户的留存率和好评度，远远高于当时被应用市场推荐而下载的用户。产品本身没有什么变化，不同之处在于，前者知晓了使用 flomo 的一些基础协议，比如用自己的话做笔记，写卡片而非写文章，就像知道单双号限行，油车不能进景区这些协议一样。而后者则没有这方面的共识，就会带着自己已有的惯性使用（但这并非是什么错误），继而导致各种摩擦。

但显然我们不能指望每位 flomo 用户都看过我们写的书、演讲、文章之后才来使用。所以在去年做了一个很重要的决定，就是去 flomo 101 化 —— 提取出来最关键的几条规则，以产品化的形式告诉用户，而不是用几十篇文章，甚至一本书。

从实际结果上来看，这次改动的效果收益颇丰，因为所有用户无论前置获得过什么信息，在打开产品的时候，都会快速的了解到使用这个产品的核心「协议」是什么，继而按照这套规则使用下去。

从产品功能设计来说，这几个弹窗没什么技术含量，但这些界面的文本却让 flomo 的大部分用户遵循了某种协议 —— 接纳了一些缺陷（不能排版、不方便写文章），也带来了更多便利（快速捕捉、意义涌现）。

所以从广义上讲，协议可以理解为基础设施加行为引导。协议总是限制人的某些能动性，但是却扩大人的其他能动性。

3.

但是协议并是写几个本文就成立了，如果和基础设施不匹配，协议很难发挥积极作用，甚至会带来各种许多负面效果。

最早做美食相机的时候，我们的目的是让用户把在外面吃饭拍的照片，通过添加美美的水印，获得 POI 信息，继而做美食推荐。但是用户却关注在如何让自己拍的美食更好看上，于是出现了大量在家拍摄的人（无效地理位置），甚至不少人用相机拍摄后传到手机上再添加水印（没有地理位置），最终导致社区只剩下美学价值。

再比如说，最早小报童希望沿用 flomo 的卡片思路，希望创作者提供一些真知灼见即可，不需要写成长篇大论。但是这种如微博一样的付费内容，作者是开心了，但是读者却不愿意为此买单。于是上线没多久就发现，许多作者越写越长，甚至不断要求要有标题。最终我们不得不修改基础设施，甚至专门开发了创作者后台，支持富文本编辑。

协议成功的程度，取决于它被使用的程度。

4.

协议还有个好处，即可以比实体设计更能为不确定性提供舞台，为意外的机遇提供便利。

小报童最初只是一个按时长付费订阅专栏工具，但是随着我们对作者了解越多，越发现许多人由于自己的工作生活状态，其部分经验非常有价值，但却很难进行长期连载。

于是我们就想，是否能为他们提供一种新的「协议」，这才有了后来的买断制专栏。除了时长差异，在其他产品设计上，并没有做过多区分。

但结果挺让人意外，因为这种买断制也催生出来了一种类似于课程的案例库，比如刘飞老师就根据自己研究 Midjourney 时的记录，形成了一个买断制的专栏；后厂女工小王根据自己玩小红书的经验，形成了《小红书运营手册》等等。

如果所有的改动都是基于基础设施而非协议，那么一切将会死气沉沉。

5.

上述称之为「协议」的部分，在国内还有一种熟悉的说法，叫做运营。

或许，运营不是一个箩筐，用来装所有产品以外的事情。而是应该用基于产品，定义协议，维护协议，改善协议 —— 毕竟许多时候，都无法通过修改基础设施来弥补协议的缺陷。

这或许才是运营最该做的事情，也是运营超越产品的价值所在。

后记：本来想翻译《Protocols Don’t Build Pyramids》这篇文章，里面内容是在精彩。但后续仔细想了想，一来文章聚焦在城市规划领域，和我们日常工作交集不多；二来看到了一些精彩的观点，然后又如何呢？

所以换了个思路，把对自己的几个核心启发结合过往经验整理了出来，希望对你有所启发。有条件的，当然推荐去阅读全文。