網易雲閱讀【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端要多很多，諸如螢幕尺寸、記憶體因素、網路狀況、快取和網路載入的區別、介面切換動效等等；第二、每一處細節也都體現著設計師對使用者使用場景的思考。
下面也舉兩個例子。
一、首頁搜尋的結果中，對於已新增的內容，顯示按鈕“閱讀”；而資訊中心已新增的內容，不顯示“閱讀”。
使用者在使用首頁搜尋的一種場景如下：因為訂閱了很多源，在首頁翻頁找不到，就使用搜索來快速定位。這種場景下提供給使用者一個“閱讀”按鈕可以提高操作效率。
而在資訊中心時，使用者是想要新增新源，如果也在列表上增加“閱讀”按鈕，一旦誤點選，會跳轉到首頁再開啟此源，無法返回，後果較嚴重。
同樣的列表為何有不同的設計?因為即使樣式差不多，使用場景卻有很大差別。
‘
二、在資訊正文的操作中增加“日間模式”和“夜間模式”的切換。
從系統邏輯上講，日間和夜間的切換是全域性的，所以放在全域性的設定中更合理。但分析使用者的使用場景，使用者往往在專注於閱讀文章時，才發現螢幕太亮而需要換到夜間模式。
‘
五、開發跟進
一份完備的互動輸出文件，是設計與開發有效溝通的必不可少的環節。但實際工作中，文件溝通總是有障礙，簡單了，很多細節說不清，複雜了，設計者寫得累死開發還不一定仔細看。所以，最有效的辦法：坐到開發旁邊，每天檢查成果，有不符合規範的地方直接溝通並修改，省去繁冗的文件和郵件，可以大大提高效率。當然這種方法僅限於程式碼沒有還原設計的情況，如果涉及設計變更，還是需要使用郵件等方法告知專案中其他相關人員。
再分享一個經驗，將Axure匯出的互動文件存放到伺服器上，通過瀏覽器可開啟地址直接瀏覽，當開發期間有設計變更時，開發者也可以看到最新的設計稿，不再需要通過郵件附件不斷往返，降低溝通失誤的機率。
‘
存在的不足：
- 在前期資料支援不夠。客戶端產品不像web端產品容易埋點蒐集資料，所以在資料方面我們存在很大的不足，希望以後的版本能有改進。
- 設計流程不夠完善。雖然知道有很多使用者研究、互動設計的方法，但由於專業能力、專案時間、資源等等原因，並沒有很好的實施起來，很多設計決策主要還是靠想像和討論，沒有足夠多地與使用者接觸。如此，產品可用性沒有很好的保障，設計人員的專業影響力也得不到提高。希望以後流程能夠越來越完善。
- 設計師對客戶端技術和平臺約束瞭解太少，導致溝通困難。在web端，設計師都被要求瞭解html和css、清楚前端後臺的分工，可以減少很多溝通成本；在移動客戶端領域也一樣，做IOS平臺設計的也有必要了解Xcode的基本知識，儘管他比html要難許多。總之，設計師要學習的還有很多。