讓部落格回歸本質——Medium 誕生記(下)

評論
評論

〉〉 讓 Blog 回歸本質——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 的上線,讓我們感覺極好。事實上我們的合約期限還剩三個月,這也表示我們可以更進一步優化自己才剛發表的產品。除了

明顯的缺點(如沒有主頁),這個網站還缺乏美化和其他一些我們因時間趕不及完成的功能。

我們重組團隊,把原來的團隊拆分成新功能團隊。每一個功能團隊都至少有一名設計師,前後端各至少一個開發人員。一些團隊可能需要負責多項功能,這取決於團隊人員的複雜度。我們用一張便於修改和理解的摘要板來指導團隊完成他們各自的功能。

這個摘要板主要包括以下幾方面內容:

  • 這個頁面為誰而做?
  • 這個頁面幫使用者解決了什麼問題?
  • 我們怎麼知道他們需要它?
  • 我們想讓使用者在這個頁面做的事情是什麼?
  • 哪些方式可以引導使用者做這件事情?
  • 我們怎麼知道這個頁面,確實按照我們的期待發揮作用?

在彼此分開的團隊工作還會遇到一個極為常見的問題:在整個產品的開發過程中,如何保持設計的完整性。

我們仍在飛速般向前推進。我們也嘗試去做很多新東西。除了

改進現有部分,我們還添加了一些新功能,如個人資料頁、筆記、多欄目投稿、統計等等。那時,我們仍在致力於開發不同的文章類型:照片、附文字說明的照片、純文字、文字和圖片、短文和其他一些準備要設計的東西。

medi03

 

這樣的 Medium 會突然讓使用者獲得多樣的選擇權(這也就意味著閱讀的複雜性)——這個產品現在則走到了兩難岔路。

現在我們面臨著兩個選擇:繼續走多媒體內容(包括圖像、引述、影片與文字)的路線,或者,專注於文字,影像僅為輔佐。現在看來專注寫作似乎是再清楚不過的選擇了,然而在當時,當你因為所有曾付出的努力而迷失方向的時候,這個選擇會很難做。多虧了 Evan 最終做出了決策。我們痛恨看到我們設計和創建的內容無法上線,但他們又需要被砍掉以讓這個新產品可以在簡約中繼續成長。我們最後的選擇是,把它們融合成下面三種形式,由左而右分別為:純文字、圖片作為說明、圖片作為封面。

mediummmmm

結語:我們的領悟

有時候,即便出色的創意,也必須被砍掉

Geoff Teehan,合作夥伴

在我們開發這個產品的過程中,這樣的事情會不斷上演。有時候我們只是放棄某個創意,其他一些時候,我們則需要拋棄我們已經做出來的東西。

為了產品能更好表現,你需要高瞻遠矚,以及無畏的勇氣砍掉這些東西。甚至在我們加入之前,這個產品已經嘗試過很多不同的模型。當時這可能會讓人感到沮喪,但最終,如果你不忍痛下手,這個產品會變得複雜並缺失方向。

遠距離工作是很艱難的考驗。

--Chris Erwin,開發人員

當我們要離開這個強大的團隊回家待上幾週的時候,我們其實非常煎熬。雖然我們可以使用數位產品聯繫彼此,但這無法代替我們在舊金山時的面對面交流。我們在多倫多的那些星期的工作效率不會比在舊金山時高,這合乎我們的預期。我們尋找著可以填補這種空缺的科技產品,我們用 Google Hangouts、Campfire chats、Anybot 機器人以及其他一些如電子郵件和手機的聯繫方式聯繫彼此。

在舊金山我們也許會做錯,但我無法想像遠距離工作可以像在一起工作時那樣高效。——特別是當我們為第一代產品努力奮鬥時。

親自使用產品。

--Geoff Teehan,合作夥伴

如果你花很多時間來查看草圖或者只是紙上談兵的話,你實在是做了太多的假設。一個很棒的產品或服務應該運作順暢,而不是中看不中用。許多使用者體驗問題是難以避免的。他們需要在使用的過程中被發現。對這款產品來說,強制使用它來發表文章以及問題 bug,讓我們不斷在使用中發現問題。

快速開發表示你可能永遠不會有滿意的一天。

--Matt Hodgins,設計師

Medium 進化的如此之快,以至於我們很少花時間退後一步看看它一路走來的樣子,或者,花時間專注於像素級別的完美設計。這通常並不是壞事,它讓你做出權衡,然後選擇了用更實用的方式去改善產品。

VIA: teehanlax.com

評論