四周年,所有人问微信朋友圈:为什么要做朋友圈这个产品?

今天,是朋友圈诞生四周年。

2012年4月19日,微信发布4.0版本,正式推出“朋友圈”功能。

一切从照片开始。在这个特别的日子里,小派搜刮出了微信团队一堆老照片,这些照片完整记录了朋友圈的诞生历程。

机会难得,小派决定和所有人一起,详细拷问朋友圈初创团队成员们。

(注:以下出镜人员均为初创团队成员。)

Q:为什么要做朋友圈这个产品?

Kink:微信除了流通聊天信息以外,还可以流通什么样的信息?我们是带着这样的初衷开始设计这个产品的。

Q:为什么选择在4.19这一天发布?

Genie:这个真不是for one night 的意思,大家不要想歪了,只是苹果App store刚好在那天通过了我们新版本的审核。

Q:当时产品团队有多少人?

Genie:当时我们创始团队是11个人,大家在情人节那天还在一起加班…吃米粉。

Q:你们做了多少个朋友圈测试版本?

Kenbin:一开始,开发团队选择用英文字母A、B、C来标注版本,可26个字母用完了,都还没有改出一版满意的,于是只能用阿拉伯数字接着标。到产品上线时,内部已测试了34个版本。

Q:「赞」和「评论」为什么要隐藏?

Ts:在最初的设计中,这两个按钮是放出来的,但观察发现对于朋友圈的极简界面来说,放上两个按钮过于抢眼了,为了保证内容在Timeline是主体,后续就把它们收到一个按钮中去了。

Q:「朋友圈为什么要取消滤镜功能?

Kenbin:为了更美好的生活。

Q:朋友圈诞生与桂林米粉也有关?

Kink:那些年我们一起吃过的米粉。

Kenbin:你见过凌晨4点的广州么…当时我们每天加班到这个时候就去吃桂林米粉,最后项目结束我都学会做米粉了。

Genie:致青春。

Wawa:当时Genie把人家老板娘的蛋都搬空了,米粉阿姨嘀咕,看过米粉加蛋的,但并没见过一板一板(一板30个)的点煎蛋的……这可怎么煎啊,钱也傻傻算不清。

Q:为什么要把发纯文字的功能隐藏?

Allen:实际上,在第一个朋友圈版本里,是没有发纯文字的功能开发计划的,发送纯文字只是一个内部测试功能,目的就是不想让用户发纯文字。

因为对于一个普通用户来说,要他写一段字的难度远远大于他发一张图片,我们希望我们的产品是每个人都能用的,所以图片才是我们主推的功能。

Q:那你们去过龙泉寺吗?

Kink:不,我们只去过米粉店。

除了产品团队给出一些回答外,在网络上,也有小伙伴对一些关于朋友圈的奇葩问题给出了解答,比如:

Q:从来不发朋友圈的人是怎样的人?

网友A:“可能他想的是——你的生活我不想错过,我的生活你休想知道。”

网友B:“你要做一个不动声色的大人了。”——村上春树说。

网友C:“大概是他没有微信吧…”

关于朋友圈,你还有哪些问题和需求,不管是一本正经或是脑洞大开的,都可以给我们留言,在下一个新版本中说不定就能看到哦~

这里是彩蛋:想看看微信朋友圈产品团队早期的朋友圈是怎样的吗?

开会…

加班…

最后,还是没离开米粉…

【文/微信派(微信ID:wx-pai)

·氧分子网(http://www.yangfenzi.com)延伸阅读:

您可能还喜欢…

1 Response

  1. 从微信新版交互变化,聊聊微信背后的产品逻辑说道:

    微信最新版本v6.5.12中。有一个交互设计跟之前相比发生了一个变化,从某种程度上,这个变化反映了微信设计产品的逻辑变化。

    引起这种变化的有可能是微信产品经理的考虑,也有可能是数据驱动下的决策,或者是用户反馈后作出的妥协;无论是哪一种,背后折射的是微信产品经理对产品在不同阶段的不同理解。

    先来看看这个具体的交互设计(可以拿着你的手机试试):

    进入微信后选择第二个tab“通讯录”,选择某一个联系人进入个人“详细资料”页面,点击下方绿色按钮“发消息”进入到聊天页面。

    此时,点击左上角的“返回”按钮,点击这个按钮后所返回的页面在新老版本中对应有所不同:

    在最新的微信版本中,点击“返回”按钮后回到的是“详细资料”页面,也就是从哪里进入就回到哪里。

    在微信之前的版本中,点击“返回”按钮返回的是第一个tab“微信”所在的聊天消息列表。

    这种差异在普通用户使用过程中可能感受不是很明显,作为一个产品人,很好奇这其中的产品逻辑变化。

    以下仅为个人观点。

    针对这一交互方式的变化,可能的出发点分析有三:

    一、产品思维与用户场景

    这个交互逻辑的关键点在于:最后点击左上角按钮后,返回的目的页面是哪个。

    微信最新版本里是回到上一级页面“详细资料”,在之前的版本里回到的是第一个tab的聊天消息列表页。

    老版本的设计存在了很长的时间,个人觉得这个设计的初衷是基于产品思维和用户场景的考虑。

    试想一下:用户通过微信通讯录找到某一个联系人并点击进入开始聊天,聊天时间可长可短,这里有一个场景符合老版本的交互设计:

    假如用户已经聊了一二十分钟,这时要离开或返回进入其他的模块,最最有可能去哪里?是再找一个人接着聊,还是看看微信其他的消息通知,或者看看公众号文章缓解一下社交疲惫?

    显然,老版本中的设计考虑的是后者原因。

    微信产品经理们觉得:

    用户在经过一段时间的聊天后需要的是:关注其他最新的微信消息,或看公众号或看朋友圈。所以他们将这个返回操作的目的页面设计为进入第一个tab。

    这是一个合理的设计,也是一个符合用户场景和用户心理的设计。

    但要知道,用户的行为是无法准确预测的,尤其是对于微信这种大体量的产品。

    上述场景确实存在,可能有几千万甚至是上亿的用户都习惯这个交互逻辑。

    可微信是一个十亿用户级别的产品,这种设计符合的用户群在微信的整个体量来说就只是一小部分了。

    在微信最新版本中,这个交互设计被修改为“从哪进就回到哪”,不再是之前的场景化设计。

    这也能理解——人类的思维方式中有惯性思维,就像我们每天上下班都是走固定的路线一样,这种惯性思维会成为一种可预期的安全感,让用户的每一步行动都是可预期的。

    并且考虑微信这么大的用户体量,所以,最原始、最符合惯性思维的设计可能是能兼具群体效应也符合用户思维习惯的。

    基于上述考虑,这个交互设计被修改,某种程度上也反映了微信产品逻辑在不同阶段的不断进化。

    二、数据验证产品假设

    另一种可能的情况是:基于数据的产品假设验证。

    刚刚讲到了:这个交互设计在微信之前版本中,可能是一个基于产品思维和用户场景的设计——这也许只是一种符合用户场景的假设,可能微信产品经理们本身对这个设计也没有十足的把握。

    但作为一个产品驱动的公司,产品经理的话语权肯定是很高的。

    于是,通过在产品中设置数据埋点,将用户在这个交互路径上的所有动作都通过数据记录下来,并且通过海量的用户行为数据收集和分析,最终发现用户通过这个“返回”动作去向的目的页面并不是之前假设的聊天消息列表,是第三个tab“发现”,是再找一个人看“详细资料”或者是直接退出了微信。

    这种假设只是个人猜测,如果可能,那这是一种比较科学的做产品假设验证的做法。

    数据具备代表性,而且能通过数据验证前期的人为假设,是不断优化产品的一种好方法。

    数据验证产品假设现在被运用到越来越多的公司和产品中,典型的AB测试或者灰度测试都是通过数据验证产品设计的方法。

    如果说以前做产品的方式更多的依赖于产品经理的直觉,也许这是下一个阶段科学做产品的最主要方法。

    三、用户反馈驱动产品优化

    第三种可能就是:基于用户反馈驱动的产品优化。

    坊间传闻,在腾讯内部对产品经理的要求是:每天要和多少用户互动,要查看多少用户反馈。此举的目的在于:让产品经理感受用户的感受,在做出产品设计决策时能够真正从用户角度出发考虑。

    做过产品的同学都知道,站在设计视角思考和用户角度思考是完全不同的两种角度。

    设计视角是一种逻辑推理驱动的思维方式,用户视角是一种使用场景和心理行为驱动的思维方式。

    还是基于一个先验的产品设计:当产品经理不确定何种方案更优时,最快速的方式就是尽快将产品推向市场面向用户,基于用户反馈来做产品优化迭代。

    微信老版本中的这个交互逻辑存在也有很长一段时间了,期间陆陆续续可能收到过很多用户的反馈,而腾讯对产品经理的要求势必会让产品经理们对用户反馈的极度重视。

    很多用户觉得这个操作不方便,明明想再返回到“详细资料”页再看看对方的历史朋友圈,而点击时却回到了聊天消息列表,又得再重新进入一次。

    基于类似的用户反馈,最终让微信的产品经理们把这个交互设计调整为最自然的“从哪进就回到哪里”。

    在产品设计中,兼具产品思维和用户思维无疑是产品经理的必备。

    在考虑和决策不同的设计方案时,尽可能的从普遍用户群体的角度去考虑:没有绝对好的设计,也没有绝对不好的设计。取决于产品的普遍用户群固有的使用习惯,而这里面大都是基于人性习惯的考虑,例如惯性思维。

    产品是解决绝大多数用户群体的需求,一个设计本身可能特别优秀,但仅解决了一部分人的问题而忽略了普遍群体,可能就不是一个好设计了。

    以上仅为个人观察和观点,如有不妥之处,望各位看官海涵!

发表评论

邮箱地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>