欢迎光临
最新房产资讯

让部落格回归本质——Medium诞生记(下)

让部落格回归本质——Medium诞生记(下)
〉〉 让 Blog 回归本质——Medium 诞生记Medium 团队

一切都已经安排就绪后,我们才开始观察跟我们一起合作的团队成员。这些人当然都是名号响亮的人物。有一次,我们团队中一名开发人员 Chris 说道:「嘿!Dustin Diaz⋯⋯我知道这家伙⋯⋯他写过一本关于 JavaScript 的书⋯⋯像他硬是写了一本书就可以了。妈的,这本书应该属于我的。」Jon Lax 则回覆:「欢迎加入英雄联盟。」

团队里没有个人

在 Medium 团队工作的每一个人都非常聪明。他们中的很多人都曾开发过这个地球上最棒的网站、服务和软体。我们上班的第一天,再一次,我们感到有些惶恐,但很快我们就意识到,这个团队里没有个人。

在进行工程开发的某个阶段,我们开始设计一个投票/评分系统。该系统的部分功能是一个类似于 Google 的「+1」和 Facebook 的「like」的按钮。我们正在辩论这个按钮该如何运作,以及上面应该呈现什幺讯息。这时候产品主管 Jason Stirman 说道:我们应该打电话给 David 叫他过来,他是 Google「+1」按钮团队的一员。于是 David 过来加入我们的讨论。他为我们讲了更多关于人们是如何推荐内容的知识,这让我们得以继续展开工作。

我们为能成为这支精英团队中的一员而倍感荣幸。我们还开玩笑地说,除了用肉做成的时光机,和这些家伙共事让我们几乎可以创造出任何东西。

沉浸其中

团队里两条主线在共同进行:今天要做的东西,和将来要做的概念化内容。

我们内部运行着一个非常简陋的 Medium 版本。事实上我们叫它「杯子节奏」。这个早期的版本反映出 Evan 对这款产品的很多核心理念。多亏了前端开发人员和后端工程师每晚的搭建开发工作,我们得以将

另一条主线是概念设计。字面上来讲

他们已经创建出了数以百计的实体模型。那时的 Medium 不光包括文字类的内容,它还包含了很多其他类型的内容:照片、短篇文章、长篇文章等等等等。它还尝试让发布者选择不同的主题模板以符合他们自己的内容。这其中的很多概念都推动了现今内容的呈现方式。他们使用大图、大型而前卫的布局。这些概念或多或少地分别渗透到后来的文章和内容收藏的设计里。

我们的团队聚集讨论,最后我们决定关注以下几个方面:

早期版本

起初我们的工作快速而鬆散。设计师和工程师会坐得很近,为我们上面总结的内容工作。我们会聚在小组里,然后一起检查初步的草图、各个模板设计以及原型。我们会讨论这些内容的优缺点,做出决策,然后继续工作。这样的情景每天会发生 6 次。随着内部产品的不断进展以及它的界面和功能变得越来越清晰,我们减少了开会的次数,转而开始细化产品的每一部分,以便我们可以真正地使用它。努力工作在一开始会很重要,但使用情况才是决定一款产品能否存活的因素。

实际上,当有非常多的东西得完成的时候,我们已经不太能记得要实际去用这款产品了。为了尝试克服这一点,每週我们都要求设计团队给 Github 至少提交一篇最少包含两个 bug 的文章或日誌。这是一个很省力的请求,它确保了我们可以使用自己正在设计的产品。

第一代发表

Evan 站在整个团队面前。他简单地演示了一些幻灯片——中间穿插着漂亮又令人发笑的过渡内容。他讲到哪些东西要包含在内,哪些要去除。它将会很简单——甚至没有主要页面。时间表也安排得气势逼人:2012 年 7 月 31 日 Medium.com 将正式上线。只有一百个左右的使用者可以发表内容,但所有拥有 Twitter 帐号的使用者都可以阅读 Medium 上的内容。他的讲话简短而有力。这是一次非常激励人心的讲话,整个团队听完他的讲话后都非常兴奋。

那番谈话以后,到发表日期到来之前的这些日子里,整个团队日以继夜的奋斗。开发进行的如此之快,以至于几乎不可能花时间后退一步看看 Medium 正在变成什幺。我们错过了 31 日,所以只能延到 8 月 14 日发表。那时虽然产品仍有不少缺陷,但它仍然让整个团队感到很开心。

Medium 发表当天,如你所期待的那样,非常混乱。当它上线之后,我们所有人都聚集到主会议室,查看大萤幕上的 Twitter 和实时分析,此时工程师们则密切关注着他们的笔电,实时监控他们能够监控的一切,以确保网站的速度和稳定性。它始终没有出现故障,而且速度一直很顺畅——这样的工程师团队很少得到他们应得的荣耀,但荣誉确实都该归给他们。

今天终于落幕,从明天起,我们将开始属于我们的第二段旅程。

继续前进

Medium 的上线,让我们感觉极好。事实上我们的合约期限还剩三个月,这也表示我们可以更进一步优化自己才刚发表的产品。除了

明显的缺点,这个网站还缺乏美化和其他一些我们因时间赶不及完成的功能。

我们重组团队,把原来的团队拆分成新功能团队。每一个功能团队都至少有一名设计师,前后端各至少一个开发人员。一些团队可能需要负责多项功能,这取决于团队人员的複杂度。我们用一张便于修改和理解的摘要板来指导团队完成他们各自的功能。

这个摘要板主要包括以下几方面内容:

在彼此分开的团队工作还会遇到一个极为常见的问题:在整个产品的开发过程中,如何保持设计的完整性。

我们仍在飞速般向前推进。我们也尝试去做很多新东西。除了

改进现有部分,我们还添加了一些新功能,如个人资料页、笔记、多栏目投稿、统计等等。那时,我们仍在致力于开发不同的文章类型:照片、附文字说明的照片、纯文字、文字和图片、短文和其他一些準备要设计的东西。

让部落格回归本质——Medium诞生记(下)

这样的 Medium 会突然让使用者获得多样的选择权——这个产品现在则走到了两难岔路。

现在我们面临着两个选择:继续走多媒体内容的路线,或者,专注于文字,影像仅为辅佐。现在看来专注写作似乎是再清楚不过的选择了,然而在当时,当你因为所有曾付出的努力而迷失方向的时候,这个选择会很难做。多亏了 Evan 最终做出了决策。我们痛恨看到我们设计和创建的内容无法上线,但他们又需要被砍掉以让这个新产品可以在简约中继续成长。我们最后的选择是,把它们融合成下面三种形式,由左而右分别为:纯文字、图片作为说明、图片作为封面。

让部落格回归本质——Medium诞生记(下)
结语:我们的领悟

在我们开发这个产品的过程中,这样的事情会不断上演。有时候我们只是放弃某个创意,其他一些时候,我们则需要抛弃我们已经做出来的东西。

为了产品能更好表现,你需要高瞻远瞩,以及无畏的勇气砍掉这些东西。甚至在我们加入之前,这个产品已经尝试过很多不同的模型。当时这可能会让人感到沮丧,但最终,如果你不忍痛下手,这个产品会变得複杂并缺失方向。

当我们要离开这个强大的团队回家待上几週的时候,我们其实非常煎熬。虽然我们可以使用数位产品联繫彼此,但这无法代替我们在旧金山时的面对面交流。我们在多伦多的那些星期的工作效率不会比在旧金山时高,这合乎我们的预期。我们寻找着可以填补这种空缺的科技产品,我们用 Google Hangouts、Campfire chats、Anybot 机器人以及其他一些如电子邮件和手机的联繫方式联繫彼此。

在旧金山我们也许会做错,但我无法想像远距离工作可以像在一起工作时那样高效。——特别是当我们为第一代产品努力奋斗时。

如果你花很多时间来查看草图或者只是纸上谈兵的话,你实在是做了太多的假设。一个很棒的产品或服务应该运作顺畅,而不是中看不中用。许多使用者体验问题是难以避免的。他们需要在使用的过程中被发现。对这款产品来说,强制使用它来发表文章以及问题 bug,让我们不断在使用中发现问题。

Medium 进化的如此之快,以至于我们很少花时间退后一步看看它一路走来的样子,或者,花时间专注于像素级别的完美设计。这通常并不是坏事,它让你做出权衡,然后选择了用更实用的方式去改善产品。

VIA: teehanlax.com

相关推荐