可用性測試：表述清晰的功能

　　在產品開發完成后，可用性測試是我們必要的一個環節，而在測試之前，我們一般會對軟件走查多遍，以熟習產品，并對可能遇到的問題在心里有一個大致的判斷。

　　本文作者@Uprit 最近做了一個導航產品的可用性測試，主要過程是，讓一些用戶在主持人的陪同下完成一系列已設計好的典型任務，以此來發現軟件中的一些可用性問題。

　　整個測試下來，發現了一件比較有意思的事情：有一個任務看起來比較復雜(群組導航)，但一次完成率較高;同時有一個任務看起來簡單(搜周邊)，但一次完成率卻較低。這與測試之前的預期有點出入。

　　先來看看這兩個任務的流程以及涉及到的界面吧。在這之前，先介紹下這兩個功能。

　　首先是“周邊”。“周邊”的整體邏輯是比較簡單的：首先確定中心點，然后搜索中心點附近的各類地點。簡單來講，就是“定點–>搜索”，如圖:

　　這其中，因為手機具有定位功能，“定點”又多是我們當前的位置，所以，對與用戶而言，定點一般來說是由機器自動完成的，用戶需要做的也就只剩下“搜索”了。這個過程確實很簡單。

　　接著是“群組”。所謂“群組”，主要是在多人一起駕車出去時，可以通過“群組”來共享路線，實時導航，并彼此看到對方，此外還有一些附加功能，如聊天等。“群組”的整個邏輯稍微有點復雜：首先，需要一個人(群主)來創建一個群組，創建好之后，需要他來告知其他人群組名、密碼，這個過程一般通過短信邀請來實現，收到短信的人(成員)在獲取群組名密碼之后，進入導航，搜索群組名，輸入密碼，加入;然后群主規劃路線，規劃好后，成員即可在地圖上看到共享的路線并可以看到彼此的位置。圖示如下：

　　這個過程中涉及到了多個頁面，同時需要多人多部手機之間進行互動，整個流暢稍微有些復雜。

　　然而，完成情況卻是“群組”的一次完成率比“周邊”好，這在測試前是沒想到的，這兩個任務的完成情況如下：

　　(綠：一次完成;黃：多次嘗試;紅：失敗)

　　為什么會產生這樣的結果呢?我嘗試這尋找這其中的原因。先從界面設計的角度來看一下吧。

　　首先，我們先看看“周邊”的界面，“周邊”頁面，頂部是中心點，下面是搜索框，然后是類別，最后是虛擬鍵盤。進入頁面默認是激活搜索框的。

　　這個頁面有什么問題?我覺得，主要問題在于中心點和搜索框之間的關系不明確。比如搜索“田子坊”周邊的餐館，任務失敗或多次嘗試的用戶，他們會現在搜索框中搜索“田子坊”，然后回到“周邊”，點擊“餐館”。這里最終得到的結果并不是“田子坊”周邊的餐館，因為用戶把中心點的設置理解錯了。

　　另外，定位中心點也是一個比較多余的功能，前面已經提到，多數時這個定位過程可以由手機自動完成，那么就不需要用戶去設置了。在實際的測試中，用戶基本上沒注意到這個位置是可以點擊設置的(當然，他們通過其他路徑完成了任務)。

　　其次，這里的搜索，是含義不清楚的，不知道是搜地點還是搜類型。從層級關系上來講，搜索應該是和下面的不同類型是一個層級的，但這個界面卻把搜索和定位中心點放在了一塊，這也是造成困惑的原因之一。

　　最后，進入頁面后默認搜索激活輸入框，就好像在提示用戶要輸入文字，一般而言，用戶需要找一個東西時，如果他有明確的目標時，他會傾向使用搜索來找，如果目標不夠明確或者目標明確且清楚類別時，他會使用分類。對于“搜索田子坊周邊的餐館”這條信息，很顯然，“田子坊”是一個明確的目標，“餐館”是一個模糊的目標，于是，用戶就有可能直接用搜索來定位中心點了，這樣就會產生錯誤的結果。

原文轉自：http://www.uml.org.cn/Test/201301083.asp