手把手教學：如何設計一款「完美」的「失敗」產品？

這群宅男費盡心思做了一款移動閱讀版「快播」，最後還是敗給了Kindle。真是心與身的淬鍊，血與淚的教訓。

作者 | Thomas Guigue

在我構建「Read」應用的過程中，我犯過很多錯誤，其中學到的一件事是——切忌推倒重來。如今，網頁中的每一處都完美的體現了這些案例的精髓。我的第一個例子是「Read」——一款能免費閱讀Epub 格式電子書的iOS 應用程序。

我的碩士論文題目是關於數字設備上的手勢交互，之後從事了電子閱讀方面的研究。我前兩次負責的產品分別為Addr 和Libr。前者是一款iPad應用程序，用集合註解替代傳統閱讀方式；後者是一個業餘項目，工作原理類似於P2P網路，它可以讓讀者在應用程序內分享電子書籍。

我的第一個作品Addr（中）至今仍未通過App Store 的審核

總之，我就是和電子閱讀較上勁兒了。

在2015年5月，我、Simon還有Augustin決定研製一款電子閱讀的應用程序。它將專門適用於蘋果手機、由數據驅動、早期並不加入社交功能的一款純效率工具。我的兄弟Simon（坐我邊上）和我一起完成了之前的兩個應用程序，負責客戶支持、公關、宣傳材料。Augustin當時剛剛完成了Opus（一款推薦書籍和電影的程序）的開發，正在找新的項目。他用自己的專業技術背景完善了我們團隊。

終於，我們三個好基友成立了一個小組，全心全意解決一個核心問題：如何在手機屏幕上愉快地閱讀。

從屏幕入手

我們的目標是引領未來趨勢——也就是迎合讀者在移動端的閱讀需求。小組之前設計的兩款只適用於平板電腦（iPad）的App。但自從我們收到某些一星差評——「去你的臘雞App，我只用手機閱讀！」——類似這種，我們就立刻洗心革面、重新做人——將視線轉向手機。

因此我們買了iPhone 6和iPhone 6 plus在上面測試軟體，大家猜怎麼著？它們完全適應！大屏大體上給用戶提供了良好的閱讀體驗。人們可以自然而然地在任何時間，任何地點，拿出手機。

關注閱讀格式

這是我們探尋電子閱讀習慣的切入點。

在圖書館、書店，甚至是巴黎的蘋果門店外進行的一些調研後，我們發現電子書籍的主流格式還是PDF。但我們自知無法提升PDF格式電子書籍的用戶體驗，因為它已被廣泛用於印刷行業。現在沒有技術可以百分之百的將PDF格式文件轉化成可以根據不同尺寸重排（reflowable）的文件。但自打我們打算開發這個產品以來，我們就對PDF堅決「Say No」！

這段文字摘自我們發布Read的Medium文章：

「我們堅信Epub將取代PDF成為標準的文本格式，因為用戶可以通過Epub自定義文字樣式和頁邊距等。我們想通過Read改變人們在移動端閱讀文本的方式.在Pocket，Medium，Flipboard這些成功案例誕生後，我們相信，電子書和網頁文章最終會成為一體。」

強迫縮放後的PDF，不能自適應，無法標記Highlight（左）。Epub（右），面向web的格式

所以哪些人會閱讀Epub格式的電子書？哪些人會過度使用手機？

谷歌表單里的用戶旅程圖

從這個問題出發，我們虛擬了一個人物，叫Jared。我們花費一些時間去研究他的品味。他喜歡什麼，不喜歡什麼？他日常生活是什麼？我們發現Read將在以下五個方面發揮作用：

1、 讀懂電子書籍；

2、通過電子圖書館表現他的個性；

3、建立讀書計劃；

4、閱讀後產出內容；

5、推薦書籍。

我們將所有關於Jared的想法放在Trello 的白板上。自那以後我們經常用這個方法增加新的內容、思考Read的未來藍圖。

Jared 以及他的問題

我們將Read視為對iBooks的一次變革。我相信通過設計師可以改變iPhone上的標準自帶程序。Sunrise、Wunderlist、Mailbox 就成功地讓早期用戶轉向一個更俏皮的設計產品。

全速前進

我們知道自己的工作方式會對產品產生巨大影響。因此從一開始，我們就決定在收集足夠的用戶反饋之前，明確3項規則：

1、發布產品越快越好；

2、構建微小但穩定的特色功能；

3、保持最精簡的UI框架。

我先將Read設計為僅適用於iPhone的產品，然後再其做面向iPad的適配調整。我終於不用為iPad單獨做線框圖了。我們直接從Xcode編寫iPad版本，代碼可以規定相對顯示大小和位置，以及圖片文字的絕對大小。

我們在巴黎參加GoogleLauchpad（初創公司活動）遇到結隊編程（Peer/Pair coding）的傳道者。我和Augustin都會Objective-C，所以我們很快適應這種方式。我認為我們嘗試編程並愛上它有3個原因：

1、這種方式避免了編碼過程中的所有小問題，程序的運行速度會變快；

2、我們可以寫易懂的代碼；

3、團隊中不會編碼的成員也不會覺得這個工程太難，因為我們兩個都可以調試代碼的任何部分，並且在任何地點任何時間都可以使它運行。

長按會觸發動畫並促使用戶滑動屏幕

如何應對任務不明的情況？

當我們必須編碼一些冗長的類（class），重寫一些函數（function）時，Augustin會快速完成這邊編程任務；而我則有時間構思一些設計原型圖，然後將圖片用jpg格式發給小組。如果不需要學新的Objective-C技術，我們就可以儘快實現這些設計。

當別人問起我在小組裡負責什麼，我很難回答。我負責組內的視覺框架，但是我們大多時候也和Augustin一起編程。在建立原型時，非常有效的辦法是用Xcode里一些變數，迅速調整顏色、大小和交互動畫效果。

我們的第一目標仍然是儘快發布一個產品，然後更新它，越快越好。通過在App內安插的嗅探器（最終都接入Segment），我們能獲取儘可能多的數據幫助我們構建產品。（譯者補充：嗅探器是一種基於被動偵聽原理的網路分析方式。使用這種技術方式，可以監視網路的狀態、數據流動情況以及網路上傳輸的信息。）

高效能工具

Read首先應該是一種高效能工具（productivity tool）。我們認為Read可以作為Hub在輸入（源文件）和輸出（Hihglight，引用）之間起到樞紐作用，讀者可以存儲數據供以後使用。

我們最初的問題是：

1.相對於競爭對手而言，最需要改善的是什麼？

2.哪些是第一天就要執行的重要方案？

3.如何提升API的價值?（API：Application Programming Interface，應用程序編程介面——譯者注）

4.如何整合它們？

5.我們希望用戶在屏幕上是什麼？

6.什麼可能促使用戶採取這一行動？

7.我們把嗅探器放在哪裡？命名慣例是什麼？

我們決定致力於以下方面：

1. 通過Dropbox導入書籍

2. 使用Evernote同步划出的重點

3. 自定義閱讀體驗

4. 在設備之間同步書籍

5. 每周向用戶推送被他們標記highlight的郵件

6. 構建一個極簡UI

作為一個立志成為閱讀工具之翹楚的應用程序，於我們而言，專註解決一個問題非常重要。例如，我們已經有數百個添加註釋、社交共享或支持PDF的請求，但我們並沒有急著把這些任務列在我們的list 中。

用戶很快就試用了Read，並且表示希望Read的功能在別的App上也能看到。也就是說，我們從第一天就戳中了用戶的痛點。

在我們真正開始「Read項目」（我在蘋果上的第一個線框圖）之前，它並不能很好地適配iPhone（左）。調整後（右）。

對於我們來說，一個高效能工具意味著：

1、集中於單個任務

2、適度的定製

3、API 優先

我們首先集中注意力實現將兩個API（輸入和輸出）插入到我們自己的「EPUB引擎」中。這不是關於新按鈕的設計，也不是關於從一個屏幕到另一個屏幕的平滑過渡。

Read遵循極簡原則。白色是主導顏色。兩個屏幕就足夠：

1、主頁圖書館；

2、閱讀視圖。

主頁圖書館是一個ePub文件列表，靈感來自於Pocket（文章）和iTunes（歌曲）兩個大家耳熟能詳的應用。一開始，我們沒有在書的單元格（cell）中添加許多信息。我們的閱讀視圖簡直美極了，我們打造了一個完整的文本屏幕。

單元格（cell）的進化史：從左至右

設計一個移動Hub （上）

連接Dropbox

Read不提供任何內容，完全由用戶自行下載電子書。因此我們不斷嘗試促進這第一步：讓用戶用書籍來填滿這個App。

電子書大多儲存在Dropbox 和Drive 中。不要忘記，儘管電子書只是大小範圍為200K到50M的文件，卻可能含有幾十張圖片。所以我們面臨兩個問題：

1、文件大小；

2、API調用的數量。

首先，為了獲得一本書的元數據，要解壓縮Epub文件。但即便使用全新的iPhone 6S，一次性解壓縮幾百本書也會花費很長時間。其二，很多用戶在他們自己的「雲」里都有大量的數據。當Read 只通過抓取位於Dropbox 結構中的1T 數據來檢索Epub文件時，應用程序會因為API 被大量調用而崩潰。

這就是Read 不能自動下載每個可用Epub文件的主要原因。就好比Read 只能用來管理股票，而無法控制現金流動。因此我們必須用一個簡單的「添加」按鈕讓手動添加電子書變得容易。（我們沒想到還需要一個「刷新」按鈕……）

兩種書本目錄的設計原型圖

用戶必須是積極主動的，它不像社交或新聞應用程序——這些應用程序使用戶被動地接受滾動的新聞推送。在Read 中，當一個用戶增加了三本或更多的書時，我們就認定他「被鎖定」了。這些用戶會每星期都會使用Read，並且每次用上20分鐘。

當使用「MyDropbox」時，我們想讓用戶直接訪問他們所有的書，並讓這些書在一個簡單的視圖裡顯示。

然而我們失敗了，有兩點原因：

1.他們沒有立即認識到這些是他們的書；

2.如果他們在Dropbox中有大量的數據，並且如果他們的電子書遠離Read 的根目錄，App就會崩潰掉，顯示不出任何東西。

我們用更簡單的方式改進了這個功能：Read 可以顯示用戶的Dropbox 結構。用戶顯然更熟悉自己建的結構及導航，他們就可以更輕易找到自己的要找的文件。一次點擊即可下載書；第二次點擊即可打開書。

（左）所有Dropbox里的書；（右）設計後更簡單的視圖

現在我們已經證明我們的用戶在他們自己的Dropbox 中存了很多書。他們當中數以百計的人直接要求我們提供像Drive 和Box 那樣的服務。

下一步做什麼？

克里斯多夫·陶澤特給了我一個提議，可以減少上傳新書這種麻煩的重複動作。Read可以推送通知讓用戶直接導入Dropbox中的最新書籍。這都是關於用戶行為的精準預測。。

他的見解令我明白了簡約設計的力量，從而避免了一個惱人冗餘的任務過程。

精簡的選擇菜單

設計一個移動Hub （下）

連接Evernote

一般用戶都會在文本上標出重點以便專註閱讀。Simon 採訪了數十名骨灰級讀者。他們保留引號為了以後產出內容。（採訪建立在Medium，Quora和Evernote的論壇。）使用移動端的專業讀者會把每一個重點內容一個接著一個的複製/粘貼，對他們來說，這是個非常痛苦和重複的過程。Simon 在他的伯克利寫道：

「很多人都有同樣的體會：讀了書，卻記不住講了什麼。那麼如何記錄一本書的精華呢？我們為此建立了最簡單的工具：Read 可以把每一個標記保留成Evernote 里的專用筆記，而且每個都能在設備間同步。

標記功能的實現是最好的例子：說明軟體本身講如何對用戶界面帶來好的影響。兩者相呼應：

1.一個按鍵用以突出顯示選定的文本（text Menu）。

2.一個按鍵用以顯示所有的重點（highlight Menu）。

Highlight 是Read的核心價值之一。我們在很早之前就深入進行了用戶測試——我們問了一些簡單的問題：這些符號在你看來是什麼意思？並不是所有參與測試的用戶都能確定圖標、高亮顯示、注釋或引號之間的聯繫。我們測試了幾十種圖標，直到選出那個每個用戶都能輕而易舉地識別出的圖標。

用於用戶測試的圖標

然後我開始定製iOS 默認的文本菜單(text Menu)——長按一個文本選項之後出現的彈出式菜單如複製、編輯和分享——這是一個棘手的代碼操作。我們決定反過來思考這個問題。如果我們不能在Objective-C 中自定義菜單，那我們就得想出一個基於默認的iOS 文本菜單UI的圖標。在幾個小時內，我們就設計並實現了新的圖標。

這個圖標現在是動態的，通過它我們可以看到標記重點在隨時間流逝而增加。它以新鮮的、遊戲化的方式使讀者看到自己的閱讀進度，可以這樣說，程序員的福音往往也是用戶的福音。

iOS 系統默認按鈕（左），改進中（中），最終方案（右）

字體的選擇

細節決定體驗

突出全段的長按手勢

選擇合適的字體是個非常糾結的過程，特別是做用戶測試的時候。但這很重要！當在移動端閱讀時，字體的正確選擇能幫我們解決兩大問題：

1. 閱讀長段文本；

2. 移動設備上閱讀（比如iPhone 6）。

字體設計師們關注閱讀舒適度，很明顯，對他們來說襯線字體是提高閱讀體驗最好的選擇。一句話平均有10個單詞，如果這句話；但移動端屏幕比紙頁小。

有兩條規則使我選擇正確的襯線字體：

1. 能夠在一個句子中不修改字間距，在有限的屏幕寬度容內納最多詞數；

2. 這個字體的字母「e」中的空白區域比較大。由於Read提供了五種字體大小選擇，我需要注意的是最小文本的易讀性。

最困難的，是在不犧牲閱讀體驗的前提下每頁儘可能放置更多的單詞。我試圖選擇一個儘可能窄的字體來限制斷字，同時避免過多收縮。我選擇了Tiempos 字體，它的大多數字元較小，間距較為收緊，整體的對比度也比較適應手機屏幕。

字體名：(1) LyonDisplay, (2) Karol, (3)Tiempos Text, (4) New Fournier BP, (5) Dolly, (6)Georgia, (7) Novel Pro, (8) Suisse BP Serif, (9) Brill, (10) Merriweather, (11)Romain BP, (12) Galaxie Copernicus.

「創新」VS「體驗」

作為地道的藝術生，我著實費了好些時間才將創業公司的需求與我的個人品味及價值觀區分開來，同樣也費了好些工夫才搞清楚，也許對很多人來說都顯而易見的一點：使用某個產品時，良好的體驗實際上和那些花里胡哨的手勢，並沒有什麼關係。

我設計的第一個應用叫M. Proust，我為其眼花繚亂的交互而自鳴得意，但這樣的應用並不適用於創業思維。由於改動了一些基本的可用性原則，用戶基本無法適應M. Proust那樣的使用方式。我才明白，預測用戶行為是現實應用程序市場中唯一需要遵循的法則，這無疑有悖於我在藝術院校里所接受的教育 2012年，我以「數字設備上的手勢交互」為題寫下了碩士論文，那時還想著如何用最創新的方法讓用戶用數字屏幕愉快地閱讀。然而我錯了，「創新」只是手段而並不是「目的」， 「體驗」才是。

一些用戶喜歡能設定很多功能的菜單，但是考慮到在電子書的App里，太多個性化可能會不利於人們實際閱讀的方式。

「新功能」VS「核心功能」

一旦建立了應用的核心功能，新的問題就隨之而來。是圍繞新功能進行迭代，還是鞏固核心功能？

由谷歌表格羅列的按優先順序排列的用戶反饋功能

在用戶的要求與我們自己的追求之間維持平衡，這毫無疑問是困難的。我們幾乎是在沒有任何指導的條件下，發布了第一代產品。發布後，我們還是把重心放在了鞏固原有應用上，這意味著

1. 不放棄考慮加入新功能；

2. 突出並提升現有功能；

3. 修復小漏洞。

失敗的教訓

如今我們已經停止了對Read 的運營。鑒於用戶量的有限，我們無法再對這個App進行更新（但我很感謝你們對Read 的厚愛）。

我們時常會思考Read的下一步該怎麼走，我們原先是計劃先做成一個實用的工具，再做到商業化，最後做成社區。但以現有的用戶量，我們無法證明確保第一步能否實現。不僅如此，在眾多創業公司失敗後，也許沒有人會再去開發電子書市場。

我們還曾帶著Read到Y Combinator（成立於2005年，是美國著名創業孵化器，Y Combinator扶持初創企業並為其提供創業指南）參加評選，我想那時他們就意識到亞馬遜即將瓜分圖書市場，他們也最後沒能給我們投資。Y Combinator 非常認可我們對用戶體驗的尊重，也認可我們確實解決了一些用戶的痛點，但相比於Kindle Store而言，似乎我們從開始就搞錯了目標用戶。

我選了一些給了我們五星好評的用戶留言，但我希望你先看看那些差評：

顯示不了西里爾字體的書...

在載入書的時候它崩潰了！！

另一方面，近距離聆聽用戶的聲音是值得的：

這是最好用的閱讀軟體之一。從每個細節，例如滾動視圖和筆記，到簡便的反饋方式和團隊的回復，我真是愛不釋手哇，你們也是吧！

這個應用在慢慢變好呢。期待landscape（譯者註：一種文件列印格式）格式和Spritz的融合。（譯者註：Spritz，一個來自美國的初創團隊，要讓小屏幕上的高效閱讀成為可能）力薦！

不同於iBooks,這個應用可以充分利用整個屏幕，我能在屏幕上多閱讀至少30%的內容，幹得好！

哈哈，我真是做了一款有史以來最「完美」的「失敗」作品……

-------------------------------------------------------------------

翻譯 | 花花、林幾木、李蔚娜 校對 | 柴俐

轉載請與我聯繫，並註明文章來源：

原文鏈接：手把手教學：如何設計一款「完美」的「失敗」產品？

來特贊 ，找到最對的設計師

特贊（www.tezign.com ）| 產品策劃 |貴妃奶黃包

知乎專欄：讀點兒設計 - 知乎專欄