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

date
Apr 3, 2024
slug
20240403
status
Published
tags
思考
summary
让我们把视角拉回到日常生活的城市中,你会发现,就算修建再多的道路(改产品),也无法彻底解决拥堵(满足不同的用户需求)。而有些时候,只需要修改一些协议(如限行、潮汐、单向行驶),也能让堵成一锅粥的地方暂时舒缓。
type
Post

1.

设计产品的时候,很像是在设计某种建筑 —— 这里是卧室,这里是走廊,那边是电梯间等等。当你满怀欣喜地将产品发布上线之后,发现许多用户并不会按照你规划中的样子来使用产品,然后提出诸多反馈,希望你来修改建筑。
比如一个用惯了 word 的用户使用 flomo,会觉得缺少许多排版功能;而一个经常写日记的用户,会觉得为何不能修改发布时间。
让我们把视角拉回到日常生活的城市中,你会发现,就算修建再多的道路(改产品),也无法彻底解决拥堵(满足不同的用户需求)。而有些时候,只需要修改一些协议(如限行、潮汐、单向行驶),也能让堵成一锅粥的地方暂时舒缓。
说到底,交通本身不仅仅由道路构成,还由众多不同目的的司机驾驶者汽车,在道路管理条例的约束下,达到自己的目的。从这个角度来看,拥堵更像是附着在道路上的某种协议。

2.

同样,产品亦是如此。如果在设计的时候,仅仅着力于功能的设计,而忽略了对于协议的设计,就会导致用户使用产品时没有明确的预期,摩擦变得巨大,继而产生诸多副作用。
一个很明显的观察是,当我们写的《笔记的方法》发售之后,因为看过书而使用 flomo 用户的留存率和好评度,远远高于当时被应用市场推荐而下载的用户。产品本身没有什么变化,不同之处在于,前者知晓了使用 flomo 的一些基础协议,比如用自己的话做笔记,写卡片而非写文章,就像知道单双号限行,油车不能进景区这些协议一样。而后者则没有这方面的共识,就会带着自己已有的惯性使用(但这并非是什么错误),继而导致各种摩擦。
但显然我们不能指望每位 flomo 用户都看过我们写的书、演讲、文章之后才来使用。所以在去年做了一个很重要的决定,就是去 flomo 101 化 —— 提取出来最关键的几条规则,以产品化的形式告诉用户,而不是用几十篇文章,甚至一本书。
从实际结果上来看,这次改动的效果收益颇丰,因为所有用户无论前置获得过什么信息,在打开产品的时候,都会快速的了解到使用这个产品的核心「协议」是什么,继而按照这套规则使用下去。
notion image
从产品功能设计来说,这几个弹窗没什么技术含量,但这些界面的文本却让 flomo 的大部分用户遵循了某种协议 —— 接纳了一些缺陷(不能排版、不方便写文章),也带来了更多便利(快速捕捉、意义涌现)。
所以从广义上讲,协议可以理解为基础设施加行为引导。协议总是限制人的某些能动性,但是却扩大人的其他能动性。

3.

但是协议并是写几个本文就成立了,如果和基础设施不匹配, 协议很难发挥积极作用,甚至会带来各种许多负面效果。
最早做美食相机的时候,我们的目的是让用户把在外面吃饭拍的照片,通过添加美美的水印,获得 POI 信息,继而做美食推荐。但是用户却关注在如何让自己拍的美食更好看上,于是出现了大量在家拍摄的人(无效地理位置),甚至不少人用相机拍摄后传到手机上再添加水印(没有地理位置),最终导致社区只剩下美学价值。
notion image
再比如说,最早小报童希望沿用 flomo 的卡片思路,希望创作者提供一些真知灼见即可,不需要写成长篇大论。但是这种如微博一样的付费内容,作者是开心了,但是读者却不愿意为此买单。于是上线没多久就发现,许多作者越写越长,甚至不断要求要有标题。最终我们不得不修改基础设施, 甚至专门开发了创作者后台,支持富文本编辑。
协议成功的程度,取决于它被使用的程度。

4.

协议还有个好处,即可以比实体设计更能为不确定性提供舞台,为意外的机遇提供便利。
小报童最初只是一个按时长付费订阅专栏工具,但是随着我们对作者了解越多,越发现许多人由于自己的工作生活状态,其部分经验非常有价值,但却很难进行长期连载。
于是我们就想,是否能为他们提供一种新的「协议」,这才有了后来的买断制专栏。除了时长差异,在其他产品设计上,并没有做过多区分。
但结果挺让人意外,因为这种买断制也催生出来了一种类似于课程的案例库,比如刘飞老师就根据自己研究 Midjourney 时的记录,形成了一个买断制的专栏;后厂女工小王根据自己玩小红书的经验,形成了《小红书运营手册》等等。
如果所有的改动都是基于基础设施而非协议,那么一切将会死气沉沉。

5.

上述称之为「协议」的部分,在国内还有一种熟悉的说法,叫做运营。
或许,运营不是一个箩筐,用来装所有产品以外的事情。而是应该用基于产品,定义协议,维护协议,改善协议 —— 毕竟许多时候,都无法通过修改基础设施来弥补协议的缺陷。
这或许才是运营最该做的事情,也是运营超越产品的价值所在。
后记:本来想翻译《Protocols Don’t Build Pyramids》这篇文章,里面内容是在精彩。但后续仔细想了想,一来文章聚焦在城市规划领域,和我们日常工作交集不多;二来看到了一些精彩的观点,然后又如何呢?
所以换了个思路,把对自己的几个核心启发结合过往经验整理了出来,希望对你有所启发。有条件的,当然推荐去阅读全文。
推荐阅读:
 
 


© nabin 2024