An image to describe post 换个角度看微信小程序

2013年摄于瑞士。


去年参加几次技术沙龙时,我注意到一个有意思的现象:与之前大家统一接受的换名片不同,有些人并不愿意被添加微信好友——“不好意思,不熟的人不加微信”。

这个现象之所以有意思,是因为名片暴露的个人信息似乎更多:所在公司、职位、电话、邮件等等;相反,微信只暴露一个账号。如果是从隐私角度考虑,能接受换名片就应当能接受加微信。但不愿意加微信,恰恰也是从隐私的角度出发的,因为不愿意被打扰。

所以不加微信的原因,是“隐私”之外另一重考虑:不愿意跟你发生某种形式的联系。

所谓“联系”,指的是发生交互的能力。名片暴露了公司、职位、电话、邮件等等联系,看似繁多,其实都是单向的联系方式,外人不主动联系你,是没法获取更多信息的,如果有危害,也无非是些很容易拒绝的骚扰。微信的联系则复杂很多:加了好友就可以看你的朋友圈,持续看到你的动态、了解你的爱好和心理,可以把你拉到某个陌生的群,还可以“零成本”把你的微信名片发给其他人…… 从这个角度来看,不加微信就很容易理解了。

如果顺着这个角度继续思考就会发现,工具提供的交互能力,与基于工具建立的联系的强弱是大致匹配的:电话是独占式而且“必须即时答复”的,所以联系强度很高,不轻易发起;微信是全方位介入生活而且形式多样的,所以强度也不小,而且包罗万象;短信、QQ不要求马上答复,表达形式也较贫乏,所以往往用于不那么正经的场合(银行通知类短信除外);邮件的情况复杂一点,虽然交互能力有限,但因为往往揉合了职级体系和工作安排,并不能简单算作弱联系。

这些结论不难理解,但仍然有很多时候大家会“搞错”联系的强度,本该交换名片的时候变成了互加微信,本该留邮件地址的时候留了电话号码。究其原因,未必是参与者对联系形式没有感知,还有可能是因为确实没有合适的联系形式。

要知道,真实世界的联系是非常复杂的,即使看起来很固定的“双人好友联系”,也可能需要在不同强度和形式中切换——有时候我只想和你的邮件联系,有时候又需要和你电话联系。可惜的是,大多数通讯工具只提供了“好友”这类联系模式,它是固定的,缺乏灵活变化的柔韧。所以,如果我加了你的微信好友,那么任何时候——哪怕我们的关系不那么密切了——你都可以随时给我发消息、给我拉群、看我的朋友圈。这,正是让很多人感觉不适的原因。

再举个例子。很多人都有过饭馆排队等号的经历,领号之后往往只能干等着,如果错过就只能重来。好一些的饭馆会提供让食客留下电话号码,这样领号之后就可以四处逛逛,快到了会接到饭馆电话通知。但这也只解决了单方面的问题,不少食客在闲逛时希望知道进度——“前头还有几个人,是不是快了”,电话显然不能胜任。于是,专门用于查询和通知等号情况的微信服务出现了,它提供了双向的、即时的通讯,既可以等通知,又可以主动查询。

看起来,这种服务完美地解决了问题,其实不是,这种交互还是不能灵活变化。用餐完毕之后,食客就不再希望和服务号保持紧密联系,至少不要再受它们的骚扰,但刚刚已经关注的服务号还会遗留下来,也没有办法自动切断联系。不知道其他人怎么对付这种问题,我经常不得不关注的各种“服务号”,只能手动取消关注或者关掉“接收消息”的选项,下次到某些时候又必须手动开启“接收消息”,如此往复,烦不胜烦。有没有可能,我虽然关注了你,但是只在我需要的时候你会出现,我不需要的时候你就不出现?目前来看,似乎还没有。

前些年有个概念非常流行,叫LBS,也就是“基于地理位置的服务”,比如当年流行的“签到”,就是最直观的例子。LBS单纯从形式上看可能是强联系,但只有你到了特定的地理位置才能使用某种服务,一旦离开特定位置,服务也随之消失。人能不能和服务交互、如何交互,在一定程度上是随着地理位置的变化而变化的。可惜很多LBS都是“为了LBS而LBS”,一方面特别希望建立强联系黏住用户,另一方面又没有很好的适配场景。结果在用户不需要的时候总是跳出来烦扰,要么在用户真正需要的时候又帮不上忙。LBS应用的功能再强,不能“体谅”用户就是白搭。

总的来看,基于现下流行的单纯“加好友”或“关注”方式所建立的静态联系,它所提供的交互能力,即便功能足够强,也太不灵活,太难变化,所以还有大量应用场景不能覆盖——上面提到的依时间或者地理位置变化而变化的联系,其实都是具体的应用场景。理想状态下,个体与个体、个体与服务之间的联系,应当能根据应用场景变化而不断变化。如果有统一的账号和基础能力,提供的联系有不同层级的区分,有针对具体应用形态的定制,并且能平滑地切换,自然很容易催生千丝万缕的联系。

微信已经在这方面做了些尝试,而且效果不坏,订阅号就是例子。虽然微信的存储、推送在技术上都没有问题,大家也默认接受微信的实时消息,但绝大多数微信订阅号每天只能推送一次,这种“克制”在微信高黏性、高频度的应用特性下生生开辟了“弱联系(弱触达)”的特区。它虽然引发了不少抱怨,却保证了订阅号和读者之间相对健康的联系,订阅号不能毫无节制的乱推,读者也不会感到烦腻。

现实生活中还有更多类似的场景,需要专属而且灵活的联系形式和规则。组团出游就是这样:在旅行团没有结束之前,所有团员的联系是非常紧密的,大家需要聊天,需要分享照片,需要收到统一通知,需要定位团员,需要能方便地清点人数和答到…… 一旦旅行团结束,就应当各回各家各找各妈,避免持续的打扰,真正愿意保持联系的人,完全可以自己拉微信群接着聊。单纯为旅行团做个应用程序又太重,所有人需要注册、登录、加好友,最后还得记得注销和退出;但是没有这样的应用,效率确实又无比低下。理想状态下,通用工具在轻松解决身份问题的基础上,能很好提供“在特定场景下定制联系形式和能力”的服务。可惜,这样工具我还没有看到过。

上面这些问题我之前一直在思考,也和不少朋友交流过。基本观点认同的人不少,但这种问题究竟要如何解决,未来在哪里,一直没有明确的答案。上周看到微信小程序的公开课,看到张小龙的演讲,尤其是他谈到场景、生态的部分,我相信微信团队也思考了这类问题:在现实生活中的每个具体场景下,应当有办法定制出最精简最适合用户需要的“小微信”(这个名字不一定准确),在其中,服务与用户的交互能力不会被滥用,也就不会给用户带来麻烦。如果能做到这一点,整个生态圈里联系的粒度就会细致很多,能够催生的联系也会大大超出人们的想象。

但我失望的是,现在看到很多关于小程序的文章,大都在讲如何开发、如何调用、如何部署,并没有多少产品设计和交互能力定义上的讨论。所以,我把自己的想法写在这里。