让博客回归本质 － Medium诞生记

        编者按：越是浮躁的年代，就越是需要可以沉淀思想的地方。Medium 志在于此，它是一个专注于分享观点和故事的博客平台，由最先创造博客产品 Blogger 和 推ter 的 Evan Williams 打造。本文作者供职于 Teehan+Lax——一家提供互联网产品解决方案的公司。文中出现的 Geoff TeeHan 和 Jon Lax 是该公司的两个创始人。

        一个专注于分享观点和故事的地方

这个世界已经拥有数不胜数的媒体了。然而无论传统媒体经济经历着何种变故，都无法阻挡海量信息从智能手机、企业以及新一代的媒体型创业公司那里疯涌进互联网，让整个世界都看得见。

在不断推出的媒体型产品让人们的生活变得越来越高效时，我们开始思考某种具有极大改进空间的媒体产品，它对个人来说并不是必需的，对新闻媒体来说也不重要。我们就叫它观点吧。

何种类型的观点？各种各样的：对今天（或过去）发生的某件事情的独特看法，分享的努力学来的专业知识以便让读者做得更好，一个让人们大笑，微笑或者 让人们觉得有意义的故事。你可能有一些可以冲击、影响他人的想法想要与人分享——而这些想法超越了你的朋友，超越了 140 个字可以表述的范围——我们想要提供这样的工具和场所（Evan Williams）。

        开始

        推ter 联合创始人 Evan Williams 和 Biz Stone 创立了新公司 Obvious，我们与该公司间的联系，始于 Evan Williams 在 推ter 上关注我们。推ter 创始人用这种方式跟人交流看似来似乎很正常。直到几天后，我们收到他发来的直接邮件（Direct Mail）。

        当时是 2011 年的 9 月份，几次邮件的交流之后，Evan 在一封邮件内问到我们能否尽快选个时间同他在旧金山见面。接下来那一周，Geoff Teehan 来到了旧金山——Obvious 公司所在的那座城市。

        第一次会谈

        我们当时并不知道自己要期待些什么。因为没有议程安排，我们只是在日历上标着：一个小时的会谈。Evan 暗示会谈的内容与他准备着手的下一步工作有关。一想到要同这个创建了 Blogger，当然还有 推ter 的人见面，我们就有些紧张。

        会议的一部分内容是，由我们讲述我们做过什么、如何做出来的，我们公司的结构，我们一起合作过的伙伴以及我们当时在做什么；我们那时刚发布了 TweetMag 应用，还现场演示了 iPad 平台的 Readability 应用的原型。

        会议的最后 20 分钟则由 Obvious 来讲述它当前正在思考的东西。这些东西大都是关于未来的出版业的。我们当时还不太清楚这些东西，但很快我们就会弄清他们。

        会议结束时，Evan 说道：“非常高兴和你们会谈。虽然我现在还没有任何东西，但一想到我们将来会找到某样东西然后一起合力完成，我就感到很兴奋。”一个结束时没有下一步安排 的会议通常不是个好征兆，但不得不说，花时间和对某些事物抱有相同热情的人一起交谈实在是件非常愉快的事情。

        第二次会谈

        大概一个月后，我们终于收到了来自 Obvious 的消息。这次是关于在一起工作的事。

        Geoff 和 Jon 飞到旧金山同 Jason Goldman 还有 Evan 见面，这次他们两人了解到更多关于 Obvious 正在做的东西，以及我们公司可以提供的帮助。

        在会议上，Jason Goldman 和 Evan 谈到他们正在探索出版平台的一些创意。他们已经为创建这样一款产品而工作几个月了。这款产品的精细、复杂程度令人难以置信，虽然它已经试运行过一些模式，但所有这些模式没一个能让人找到对的感觉。

        他们想试验一些新的东西。它不需要功能全面，只要出现原型就可以了。Evan 相信产品决策要由实际使用情况决定。即便我们没能创建出一个功能全面的产品，但这个原型仍给他们带来更好的方向感，如果他们的新产品创意值得继续探索下去的话。

        Jason 因事去多伦多待了两天，我们则对原型进行了粗加工。接下来的两个月我们设计、创建出各种各样的产品模型。我们每周都会同 Obvious 联络。我们的工作方式挺像对普通客户那样：由于每周一次的客户反馈而不得不加大马力工作。

        产品模型使得我们可以从两个方面中的一个鉴定一些功能：哪些功能不好用，或者哪些功能需要丰富。

        漫长的等待

        就在 2011 年圣诞前夕，我们把产品原型包装了起来。Obvious 的工作人员对我们的工作表示了感谢，然后，就没有然后了。

        直到新年过后我们仍在等待。我们不断查看 Obvious 的网站、它的 推ter 以及其他一些科技媒体的博客，希望听到官方宣布与我们所做的产品相关的任何消息。但什么都没出现。

        这对我们来说总是难熬的。你在做工作时不能透露工作内容，然后还无法确定它是否会出现在网上，抑或最终被决策者砍掉。我们能做的只有等待。

        再次联络

        在 2012 年 4 月份，Evan 再次电邮 Geoff，并说道他希望讨论以一种更亲近、更能彼此协作的方式在一起工作的问题。在去年为原型而工作了四个月后我们知道，在 Obvious 工作是很繁忙的。他们已经创建出一些东西了，这就是他们说到的——Medium。他们已经有了实际的代码，一个正在运行的产品以及准备塑造出某样东西的决 心。

        接下来我们飞回旧金山。此时的 Obvious 已经搬进了一间更加漂亮的工作室。那里的工作人员已经增加了一倍，而他们所有人正专注于创建 Medium。

        从 Medium 身上几乎看不到我们所做原型的任何踪迹，但这也可以理解——它已经演化成另一个非常不同的产品了。Evan 解释道，他感觉到在 Web 上进行有意义的写作是一个需求方向。没有一个地方可以供那些想写一些比微博更有质量的内容的人驻足。博客，这个长远看来更能满足人们需求的产品，需要精华内容来让它崛起和繁荣。

        获得成功的那些人需要对单一方面的问题进行持续地关注和学习，而新人则需要读者。他继续说道，人们有时在谈到某一主题时只能想到一样东西，但他们不可能每天每周都有机会在谈论某一主题时想到新的东西。这正是 Medium 愿意解决的问题。

        他希望我们提供一个团队和 Medium 现有的团队进行融合，以帮助他们设计产品。彼时，他们团队有三名设计师：Dustin Senos，Leigh Taylor 和 Dann Petty。Dusting 身兼两职，他既是开发人员又是设计师，而 Dann 和 Leigh 则专注于设计。Evan 已经打造出一支非常了不起的工程师队伍，但他还需要设计师的帮助，这也是我们加入的原因。

        这次的工作方式跟典型的客户任务有些不同。它不会让我们回到多伦多，然后在独立状态下工作，就像我们做原型时那样。我们需要成为 Obvious 团队中的一部分。这对我们来说不仅有些麻烦而且还很有挑战性。经过长时间讨论，我们达成了以下约定：

        6 个月交付：设计产品不光是为了发布——它在发布后仍需要不断细化改进。

        特种突击团队：Geoff 将带领 4 人的团队和 Obvious 原来的团队一起设计、改进 Medium 的用户体验。

        远程工作：我们几乎要花我们一半的时间在旧金山的 Obvious 办公室工作。

        深度整合：在这个团队工作的每一个成员都将被视为 Obvious 的雇员。新的 Obvious 邮箱地址，到项目的 Github、Campfire 小组的访问权，甚至可以使用 AnyBot 在现场开会，如果当时我们在多伦多的话。

        全身心投入：这个团队将只为 Medium 工作，不可再分心于其他任何工作。

        Medium 团队

        一切都已经安排就绪后，我们才开始观察跟我们一起合作的团队成员都有哪些。这些人当然都是响当当的人物。有一次，我们团队中一名开发人员 Chris 说道：

        " 嘿！Dustin Diaz... 我知道这家伙... 他写过一本关于 JavaScript 的书... 像他硬是写了一本书就可以了。妈的，这本书应该属于我的。"

        Jon Lax 则回复道：“欢迎加入英雄联盟。”

        很快我们就意识到，团队里没有个人

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

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

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

        沉浸其中

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

        我们内部运行着一个非常简陋的 Medium 版本。事实上我们叫它 " 杯子节奏 "（他们曾在听电子节奏音乐的同时玩速摆杯子游戏，该名字由此得来。不过简单起见，我们将仍叫它 Medium）。这个早期的版本反映出 Evan 对这款产品的很多核心理念。多亏了前端开发人员和后端工程师每晚的搭建开发工作，我们得以将 Photoshop 和内部服务器部署平台高效无缝地结合。有了这个工具，我们可以更快地探索创意和作出决策。

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

        我们的团队聚到了一起讨论，最后我们决定关注以下几个方面：

        * 品牌和 UI 系统

        * 内容收藏

        * 带图片的文章（及编辑器）

        * 仅限文字的文章（及编辑器）

        * 图片和说明（及编辑器）

        早期版本

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

        实际上当有非常多的东西要去做的时候，我们已经不太能记得要实际去用这款产品了。为了尝试克服这一点，每周我们都要求设计团队给 Github 至少提交一篇最少包含两个 bug 的文章或日志（编者：这些文章和日志都使用 Medium 的编辑器写成）。这是一个很省力的请求，它保证了我们可以使用自己正在设计的产品。

        第一代发布

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

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

        Medium 发布当天，如你所期待的那样，非常混乱。当它上线之后，我们所有人都聚集到主会议室，查看着大屏幕上的 推ter 和实时分析，而此时工程师们则密切关注着他们的笔记本电脑，实时监控着他们可以监控的一切，以确保网站的访问速度和稳定性。它始终没有出现故障，而且访问 速度一直很快——这样的工程师团队很少得到他们应得的奖励，但荣誉都归他们。

        终于，太阳落下去，杯盏举起来。从明天起，我们将开始属于我们的第二段旅程。

        继续奋进

        Medium 的上线让我们感觉棒极了。事实上我们的合同期还剩三个月，这也意味着我们可以更进一步地优化自己刚刚发布的产品。除了显著的短板（如没有主页），这个网站还缺乏美化和其他一些我们推迟的功能。

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

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

        * 这个页面为谁而做？ 

        * 这个页面帮用户解决了什么问题？

        * 我们怎么知道他们需要它？

        * 我们想让用户在这个页面做的主要动作是什么？

        * 哪些方式可以引导用户做这个动作？

        * 我们怎么知道这个页面在按我们希望它做的那样发挥作用？

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

        我们仍在飞速般向前推进。我们也尝试去做很多新东西。除了改进现有的部分，我们还添加了一些新功能，如个人资料页，笔记，多栏目投递，统计和其 他一些东西。那时，我们仍在致力于开发不同的文章类型：照片，附文字说明的照片，纯文字，文字和图片，短文章和其他一些准备要设计的东西。

        这样的 Medium 会突然让用户获得多样的选择权（这也就意味着阅读的复杂性）——这个产品现在则走到了一个生死攸关的关键点。

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

        结语. 我们从中领悟到的

有时候，即便好的创意也必须被砍掉
——Geoff Teehan，合作伙伴

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

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

离家很远去开发一款产品是很艰难的
——Chris Erwin，开发人员

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

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

要使用产品
——Geoff Teehan，合作伙伴

        如果你花很多时间来查看草图或者只是纸上谈兵的话，你实在是做了太多的假设了。一个很棒的产品或服务会工作良好，而不光是看起来好看。许多用户 体验问题是难以避免的。他们需要在使用的过程中被发现。对这款产品来说，强制使用它来发布文章以及问题 bug 保证了我们一直在使用它。

快速开发意味着你可能永远没法满意
——Matt Hodgins，设计师

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

        VIA: teehanlax.com