七牛portal可用性測試記

引言：2013年年末應七牛公司朋友的邀請，給他們的Portal進行可用性測試。七牛（http://www.qiniu.com/）一直專一於雲存儲基礎服務，在業內很有聲譽。七牛雲存儲的後臺選用並不經常使用的Go語言，聽說公司高層至今都會參與編寫核心代碼，這些讓我感覺到團隊中濃重的工程師氣質。

在此次可用性測試中，七牛的產品經理與前端工程師深度參與其中。除了邀請用戶，還協助我進行測試數據記錄，可用性問題記錄。最終彙總了39項觀察所得。其中包括術語選用、導航設計、交互設計、美工設計等問題。有幾項給個人印象很深。

 

因爲「全部空間」與「單個空間」展示的內容、用戶能進行的操做是不一樣的，因此七牛portal的主導航項是會變的。我能夠想象網站設計者在設計該導航時，通過不少思考。容納全部操做，同時從美觀與一致出發，讓用戶不管選擇「所用空間」仍是「單個空間」導航項都是4項，僅僅是導航按鈕上的圖標與文字發生變化。

這一導航是可用的，但卻不是讓用戶使用起來最順暢的，有些地方容易讓人疑惑。如下兩張圖都會讓用戶疑惑與出乎意外。

圖1  頁面中有兩處能進行空間選擇

圖2  在picshare空間中，點擊「查看詳細使用狀況」按鈕後，頁面將把用戶導航至報表中心。當前選擇的空間，以及導航欄內容都發生變化。

對於七牛的導航項來講，能夠分爲兩類：

• 所用空間導航項，包括：使用概況、充值、發票、消費/充值記錄等
• 某一空間導航項，包括：使用概況、內容管理、媒體處理、空間設置

這兩類導航部分項的名稱是一致的，如：使用概況。但其餘項名稱不一樣，且數量也不一樣。

新畫了一張導航草圖，如圖3所示。但願能達到以下目標：

1. 頁面中只有一個選擇空間的地方，並引導用戶先進行選擇
2. 讓導航項的歸屬清晰
3. 能夠容納「全部空間」、「單個空間」不一樣數量的導航項
4. 經過麪包屑導航讓用戶知道本身在如今在哪裏

圖3  新七牛導航草圖

 

七牛爲用戶提供了強大的圖片處理功能，但在可用性測試中，多位用戶沒法成功的應用圖片樣式。

後期進行分析思考中發現這是由於沒有把用戶要的東西放到用戶但願看到的地方。

圖4  七牛數據處理頁面

在可用性測試過程當中，用戶能成功建立圖片樣式（上圖中的1）。建立圖片樣式成功後，頁面中將出現新建立的樣式描述（上圖中的2）。此時用戶的視線注意點都會落在新出現的樣式區域，用戶試圖在這個區域中尋找應用樣式的方法，但卻沒法找到。

用戶經過一番尋找後才能發現應用圖片樣式的說明在頁面中的黃框區域。但接着又遇到第二個困難，用戶沒法理解樣例。

• 當前的樣式分隔符是「-」，但樣例中用的分隔符是「/」
• 樣例也沒交代樣式名是什麼，用戶不能一下知道「style.com.jpg」是一個樣式名

比較好的作法是，把示例放在新出現的樣式區域，並根據用戶建立的樣式名和當前選擇的分隔符，給一個示例。

 

在測試中，多位用戶在完成「瞭解空間使用狀況」任務中吐槽。

圖5  日期時間段在各項查詢中被重置爲「近30天」

任務中用戶須要查詢上個天然月流量、存儲空間、GET請求數、PUT請求數的統計值，每次都要從新設置時間段讓用戶以爲很麻煩，並且還容易疏忽。

網站只要記住用戶設置的時間段，並帶入到另外一個查詢頁面中，就能很好的解決這一問題。

 

用戶在進行「充值並申請發票」操做中，有兩項發現值得思考。

第1、用戶完成充值後，會回到「確認充值頁面」等待頁面反饋（但願看到充值成功信息），但頁面沒有預期的反饋。

要徹底知足用戶的預期技術上是有困難的，由於支付成功後，網站頁面沒法實時得到該信息。

這個時候不少其餘網站已經有成熟的解決方案了，即讓用戶本身點選支付成功或失敗（如圖6所示），這一解決方案既不復雜，又知足了用戶的預期（用戶回到支付確認頁查看反饋）。

圖6  支付完成狀況

 

第2、用戶成功充值後，試圖在「發票」頁面尋找以前充值的記錄來申請發票。

但該頁面顯示的記錄僅僅爲已申請發票記錄，只有用戶點擊頁面最下發的「申請發票」按鈕，才能看到未申請發票的充值記錄。在測試中，多位用戶在這個頁面中尋找，甚至跳出該頁面去其餘頁面尋找。

圖7  發票頁面

按照用戶的預期設計，提出一些新的設計方案。

• 方案1、列表中顯示充值記錄，在列表中提供申請發票按鈕。該方案能夠去除列表下方單獨的「申請發票」按鈕，對用戶來講簡單、直觀，但沒法合併屢次充值爲一張發票。
• 方案2、若但願屢次充值合併開具發票。首先列表中顯示充值記錄，這是用戶的預期。其次在列表中加入一列多選框，用戶勾選完後，再點擊列表下的「申請發票」按鈕。