分享網易雲閱讀iPhone2.0交互設計思路

　　改版背景

　　iPhone版網易雲閱讀在1.5之前的每次改版，都是以增加功能為目標，快速迭代為手段。發布的大大小小的版本中，先後提供了離線下載、書籍閱讀、書城等實用功能，滿足了用戶更多的閱讀需求。但是一直沿用的信息架構，不再能滿足新增加的功能和需求;並且在反復的迭代中，增加了不少想改卻沒有時間改的體驗不足之處;再者，移動互聯時代的到來，用戶對移動體驗的要求越來越高，網易雲閱讀卻慢慢落後於這個時代的發展。所以，一次全面提升用戶體驗的改版迫在眉睫。

　　設計流程

　　一、收集需求(用研階段)：

　　1、簡易的可用性測試

　　項目時間永遠是緊張的，我們沒有條件按照標准的可用性測試流程來實施，但一個簡易的測試仍可以發現不少問題。在較早的一次可用性測試中，我們招募了公司內的7位同事作為被試者，測試時間進行了2天，設計任務和整理結果進行了1天左右，發現的主要問題有：

　　測試不僅可以發現問題，也能幫助我們在糾結的問題上做出選擇，比如1.x的首頁資訊源右上角有一個“i”，雖然礙眼，但考慮用戶在首頁會有查看源詳情的需求，一直沒去掉。而從測試結果中看出，當用戶需要用到詳情頁的功能時，大多數選擇點擊進入源，而對“i”視而不見。由此，就可以有理有據地把他干掉了。

　　2.整理有效的用戶反饋：

　　網易擁有較完善的用戶反饋收集系統，並且每隔一段時間都會將反饋整理並發送至項目內人員，讓所有參與者都能一直保持對用戶的關注。以下是從大量反饋中整理出來 的設計類中較典型的問題。

　　3.項目內人員發現的問題整理：

　　1) 動態效果太少

　　動態效果不僅可以帶給用戶時尚和酷的感覺，在情感上產生共鳴，增強用戶對網易品牌的認知度;而且在可用性方面，合適的動效可以使界面邏輯更清晰;再者，在現在的移動互聯網的環境中，動效的地位越來越高，是用戶體驗不可或缺的一個環節。

　　2) 搜索功能隱藏太深

　　對於目標明確的用戶，想要找資訊源或書時，需要多次點擊，經歷多個頁面的加載。

　　3) 文案不統一

　　諸如“資訊”和“訂閱”，“評價”和“評論”，“分享”和“轉發”等。

　　4) 信息架構不合理

　　比如收藏在設置中，顯然不合理(從可用性測試中也可得知)。並且目前架構擴展性不夠，小小的屏幕上已經塞了很多入口，再增加功能沒地方可放了，必須拓展屏幕外空間。

　　5) 重要元素視覺不夠突出

　　比如首頁的“資訊”和“書籍”是雲閱讀兩大重要模塊，而切換的TAB卻不夠明顯，導致當默認為“資訊”時，書籍的曝光率很少。

　　4.競品分析：

　　因為網易雲閱讀自身產品的特殊性：包括資訊和書籍兩大模塊，競品也可以分為兩大類。其中資訊類有：ZAKER，flipboard，鮮果聯播，騰訊愛看等;書籍類有：多看閱讀，QQ閱讀，雲中書城，iReader，字節社等。競品分析是一個持續的過程，主要分析競品的優勢，用戶為什麼喜歡使用的原因，哪些可以學習。由於競品數量多，沒有形成完整的一套文檔，所以我們的方法是在必要的時候，針對某一些大家都有的模塊，進行縱向的深入的分析。以下是書籍正文中，功能優先級的競品分析，通過分析可以給我們自己的設計提供參考，哪些功能是主要的，哪些是次要的。

　　從競品分析中看出，返回-目錄-書簽-進度-亮度-夜間模式-字體大小，是最被重視的，而橫屏閱讀和閱讀主題也是很多競品都有的功能，我們未來必須考慮這兩個功能的必要性。當然競品分析不能作為設計的准則，否則肯定會成為一款毫無亮點的中庸的產品，它只能從某一個側面給我們在做設計決策時提供某種參考。設計還是應該以目標用戶和使用場景為導向。

　　二、確定體驗設計目標：

　　在上面的結果中可以看出，用戶碰到不爽，會直接建議我們“增加**功能”，或者“學一學騰訊”。但這些建議還不能夠指導設計，作為設計師需要還原用戶提出這些建議的場景，發現用戶的痛點和本質需求，最終提煉出用戶體驗設計的目標，並以此作為設計的導向。所謂條條大路通羅馬，同一個目標可以用多種不同的解決方案來實現，把目標明確出來，更有利於拓展設計思維。

　　三、方案PK

　　新項目流程中，用戶研究之後應是梳理信息架構和繪制流程圖的工作，但在改版項目中，架構和流程都較穩定，不會頻繁修改。我們的辦法是圍繞用戶體驗設計目標，結合用戶實際使用情景，提出多種解決方案。這個過程前期類似於“故事板”的方法，但時間有限並沒有將故事紙面化。

　　有了解決方案後，再根據體驗提升程度、實現成本、系統性能、運維支持等多方面來最終確定方案。

　　下面舉兩個例子說明我們確定設計方案的過程。

　　1.目標：讓用戶能夠方便地找到已經訂閱的資訊源和已添加的書籍

　　首先想到的是提供分組，我們也進行了很多的抽屜模型的嘗試：

　　但是嘗試多種分組方案後，每種方案都存在較大的弊端，可能帶來導航混亂、復雜度提高等不良後果。於是再分析用戶的一般使用場景：用戶想要找的一般是他常看的源或書，所以“按照使用頻次來自動排序”和“便捷的搜索功能”也同樣可以達到這個目標，因此最終放棄了分組功能，而只增加了搜索功能，不僅可以滿足“使搜索資訊源和書籍更便捷”這個目標，也可以滿足“方便找到已經訂閱的資訊源和書”。

　　2.設計目標：優化手勢操作，使閱讀更高效和方便

　　方案1(原方案)：在文章正文頁左右滑動切換文章：

　　優點：在文章內切換文章很方便，符合老用戶的習慣

　　方案2(改進方案)：

　　優點：

　　對於較長的文章(如網易新聞)，一般情況下用戶會選擇性地閱讀，很少會連續閱讀文章，所以右滑返回列表更有效。

　　對於較短的文章(如笑話之類)，用戶需要連續閱讀，上下滑動切換仍可滿足這個使用場景。

　　手勢操作和動效隱喻對應，空間結構在正文頁和列表頁統一，更易於理解和記憶。

　　在討論中，我們預見到會有很多老用戶來抨擊這個設計，因為改變了已養成的習慣，但我們相信：只要是正確的設計，越早改影響越小，越往後代價越大。

　　關於堅持和妥協：

　　設計方案的提出，免不了要面對各方挑戰，設計者一味說服別人或者一味接受意見都不可取，如何堅持和妥協我覺得應該有如下原則：

　　討論過程中各方人員根據自己的需求和想像，對方案提出挑戰，這時設計師應該堅持，並從目標用戶、使用場景、體驗目標出發來解釋如此設計的原因，當然如果設計者說不出那就說明方案確實不靠譜，經不起挑戰。

　　開發人員憑借對系統的透徹了解，提出各種極端可能性和異常現象來否定方案，這時候設計師一定要堅持“為大多數用戶設計”的原則，切不可為“可能性”而犧牲了大部分的體驗。

　　開發從系統性能、實現成本、平台制約等方面提出意見，策劃從優先級、資源配置提出意見，對於這類挑戰我們需要適當妥協，因為我們的目標都是產品成功，如何利用有效的資源實現最多的體驗目標，這是成熟的設計必須關注的。

　　四、交互細節

　　移動客戶端的細節設計是對設計師基本功的考驗，第一、客戶端要考慮的case比web端要多很多，諸如屏幕尺寸、內存因素、網絡狀況、緩存和網絡加載的區別、界面切換動效等等;第二、每一處細節也都體現著設計師對用戶使用場景的思考。

　　下面也舉兩個例子。

　　一、首頁搜索的結果中，對於已添加的內容，顯示按鈕“閱讀”;而資訊中心已添加的內容，不顯示“閱讀”。

　　用戶在使用首頁搜索的一種場景如下：因為訂閱了很多源，在首頁翻頁找不到，就使用搜索來快速定位。這種場景下提供給