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

编者按：在上篇文章中作者讲述了Medium创办的由来，以及他所在的公司将提供设计人员入驻Medium开发团队的事

Medium团队

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

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

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

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

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

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

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

沉浸其中

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

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

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

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

* 品牌和UI系统
* 内容收藏
* 带图片的文章（及编辑器）
* 仅限文字的文章（及编辑器）
* 图片和说明（及编辑器）

早期版本

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

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

第一代发布

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

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

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

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

继续奋进

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

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

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

* 这个页面为谁而做？
* 这个页面帮用户解决了什么问题？
* 我们怎么知道他们需要它？
* 我们想让用户在这个页面做的主要动作是什么？
* 哪些方式可以引导用户做这个动作？
* 我们怎么知道这个页面在按我们希望它做的那样发挥作用？

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

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


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

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


结语. 我们从中领悟到的

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

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

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

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

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

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

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

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

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

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