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

1、簡易的可用性測試

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

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

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

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

3.項目內(nèi)人員發(fā)現(xiàn)的問題整理：

1) 動態(tài)效果太少
動態(tài)效果不僅可以帶給用戶時尚和酷的感覺，在情感上產(chǎn)生共鳴，增強用戶對網(wǎng)易品牌的認知度；而且在可用性方面，合適的動效可以使界面邏輯更清晰；再者，在現(xiàn)在的移動互聯(lián)網(wǎng)的環(huán)境中，動效的地位越來越高，是用戶體驗不可或缺的一個環(huán)節(jié)。

2) 搜索功能隱藏太深
對于目標明確的用戶，想要找資訊源或書時，需要多次點擊，經(jīng)歷多個頁面的加載。

3) 文案不統(tǒng)一
諸如“資訊”和“訂閱”，“評價”和“評論”，“分享”和“轉(zhuǎn)發(fā)”等。

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

5) 重要元素視覺不夠突出
比如首頁的“資訊”和“書籍”是云閱讀兩大重要模塊，而切換的TAB卻不夠明顯，導(dǎo)致當(dāng)默認為“資訊”時，書籍的曝光率很少。

4.競品分析：

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

二、確定體驗設(shè)計目標：

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

三、方案PK

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

有了解決方案后，再根據(jù)體驗提升程度、實現(xiàn)成本、系統(tǒng)性能、運維支持等多方面來最終確定方案。

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

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

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

但是嘗試多種分組方案后，每種方案都存在較大的弊端，可能帶來導(dǎo)航混亂、復(fù)雜度提高 等不良后果。于是再分析用戶的一般使用場景：用戶想要找的一般是他?？吹脑椿驎浴鞍凑帐褂妙l次來自動排序”和“便捷的搜索功能”也同樣可以達到這個 目標，因此最終放棄了分組功能，而只增加了搜索功能，不僅可以滿足“使搜索資訊源和書籍更便捷”這個目標，也可以滿足“方便找到已經(jīng)訂閱的資訊源和書”。

2.設(shè)計目標：優(yōu)化手勢操作，使閱讀更高效和方便

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

優(yōu)點：在文章內(nèi)切換文章很方便，符合老用戶的習(xí)慣

方案2(改進方案)：

優(yōu)點：

1. 對于較長的文章(如網(wǎng)易新聞)，一般情況下用戶會選擇性地閱讀，很少會連續(xù)閱讀文章，所以右滑返回列表更有效。
2. 對于較短的文章(如笑話之類)，用戶需要連續(xù)閱讀，上下滑動切換仍可滿足這個使用場景。
3. 手勢操作和動效隱喻對應(yīng)，空間結(jié)構(gòu)在正文頁和列表頁統(tǒng)一，更易于理解和記憶。

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

關(guān)于堅持和妥協(xié)：

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

1. 討論過程中各方人員根據(jù)自己的需求和想像，對方案提出挑戰(zhàn)，這時設(shè)計師應(yīng)該堅持，并從目標用戶、使用場景、體驗?zāi)繕顺霭l(fā)來解釋如此設(shè)計的原因，當(dāng)然如果設(shè)計者說不出那就說明方案確實不靠譜，經(jīng)不起挑戰(zhàn)。
2. 開發(fā)人員憑借對系統(tǒng)的透徹了解，提出各種極端可能性和異?，F(xiàn)象來否定方案，這時候設(shè)計師一定要堅持“為大多數(shù)用戶設(shè)計”的原則，切不可為“可能性”而犧牲了大部分的體驗。
3. 開發(fā)從系統(tǒng)性能、實現(xiàn)成本、平臺制約等方面提出意見，策劃從優(yōu)先級、資源配置提出意見，對于這類挑戰(zhàn)我們需要適當(dāng)妥協(xié)，因為我們的目標都是產(chǎn)品成功，如何利用有效的資源實現(xiàn)最多的體驗?zāi)繕?，這是成熟的設(shè)計必須關(guān)注的。

四、交互細節(jié)

移動客戶端的細節(jié)設(shè)計是對設(shè)計師基本功的考驗，第一、客戶端要考慮的case比web端要多很多，諸如屏幕尺寸、內(nèi)存因素、網(wǎng)絡(luò)狀況、緩存和網(wǎng)絡(luò)加載的區(qū)別、界面切換動效等等；第二、每一處細節(jié)也都體現(xiàn)著設(shè)計師對用戶使用場景的思考。

下面也舉兩個例子。

一、首頁搜索的結(jié)果中，對于已添加的內(nèi)容，顯示按鈕“閱讀”；而資訊中心已添加的內(nèi)容，不顯示“閱讀”。

用戶在使用首頁搜索的一種場景如下：因為訂閱了很多源，在首頁翻頁找不到，就使用搜索來快速定位。這種場景下提供給用戶一個“閱讀”按鈕可以提高操作效率。

而在資訊中心時，用戶是想要添加新源，如果也在列表上增加“閱讀”按鈕，一旦誤點擊，會跳轉(zhuǎn)到首頁再打開此源，無法返回，后果較嚴重。

同樣的列表為何有不同的設(shè)計?因為即使樣式差不多，使用場景卻有很大差別。

二、在資訊正文的操作中增加“日間模式”和“夜間模式”的切換。

從系統(tǒng)邏輯上講，日間和夜間的切換是全局的，所以放在全局的設(shè)置中更合理。但分析用戶的使用場景，用戶往往在專注于閱讀文章時，才發(fā)現(xiàn)屏幕太亮而需要換到夜間模式。

五、開發(fā)跟進

一份完備的交互輸出文檔，是設(shè)計與開發(fā)有效溝通的必不可少的環(huán)節(jié)。但實際工作中，文 檔溝通總是有障礙，簡單了，很多細節(jié)說不清，復(fù)雜了，設(shè)計者寫得累死開發(fā)還不一定仔細看。所以，最有效的辦法：坐到開發(fā)旁邊，每天檢查成果，有不符合規(guī)范 的地方直接溝通并修改，省去繁冗的文檔和郵件，可以大大提高效率。當(dāng)然這種方法僅限于代碼沒有還原設(shè)計的情況，如果涉及設(shè)計變更，還是需要使用郵件等方法 告知項目中其他相關(guān)人員。

再分享一個經(jīng)驗，將Axure導(dǎo)出的交互文檔存放到服務(wù)器上，通過瀏覽器可打開地址直接瀏覽，當(dāng)開發(fā)期間有設(shè)計變更時，開發(fā)者也可以看到最新的設(shè)計稿，不再需要通過郵件附件不斷往返，降低溝通失誤的機率。

存在的不足：

1. 在前期數(shù)據(jù)支持不夠?？蛻舳水a(chǎn)品不像web端產(chǎn)品容易埋點搜集數(shù)據(jù)，所以在數(shù)據(jù)方面我們存在很大的不足，希望以后的版本能有改進。
2. 設(shè)計流程不夠完善。雖然知道有很多用戶研究、交互設(shè)計的方法，但由于專業(yè)能力、項 目時間、資源等等原因，并沒有很好的實施起來，很多設(shè)計決策主要還是靠想像和討論，沒有足夠多地與用戶接觸。如此，產(chǎn)品可用性沒有很好的保障，設(shè)計人員的 專業(yè)影響力也得不到提高。希望以后流程能夠越來越完善。
3. 設(shè)計師對客戶端技術(shù)和平臺約束了解太少，導(dǎo)致溝通困難。在web端，設(shè)計師都被要 求了解html和css、清楚前端后臺的分工，可以減少很多溝通成本；在移動客戶端領(lǐng)域也一樣，做IOS平臺設(shè)計的也有必要了解Xcode的基本知識，盡 管他比html要難許多。總之，設(shè)計師要學(xué)習(xí)的還有很多。

轉(zhuǎn)自： http://uedc.163.com/10729.html