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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我們來看看整個的“周邊”流程以及涉及到的頁面：

　　這個流程看起來並不是很復雜，並且，如果你熟習操作的話，或許在操作上還會更快捷，但是，也正因為如此，它給了用戶很大的自由度，這樣在一個界面上就存在多種操作可能，而這些操作可能會把用戶帶向偏離主任務的地方，最終給用戶帶來困惑，界面上的誤解帶來的困惑也造成了任務完成度的下降。

　　接著，我們來看另一個任務，“群組”導航，下圖是“群組”導航的流程和涉及到的頁面：

　　“群組”導航是一個復雜的任務，主要面對兩類人，群主和成員，基本上一步一個界面，雖然繁瑣，但每個界面上傳達出的任務信息卻是清晰明確，給用戶的自由度很小，用戶在完成整個流程之前幾乎很難從當前任務中跳出去，這樣，整個過程就和安裝軟件一樣，一直“下一步”直到最後的“完成”。

　　通過這兩個任務的流程對比，我們發現，如果你不能把一個任務流程做的很簡單，那就盡可能的把它做的更清晰一點，少在界面上給用戶更多自由度;如果一個任務不復雜，就盡可能的少在界面上給用戶帶來困惑，同時，一些功能(如設定中心點)，如非必要，那就砍掉，盡量讓操作更簡潔。

　　以上，是從流程方面來分析的。在和圈圈談到這個問題時，她給出了另外一個角度也比較有意思：用戶的角度。

　　相比而言，“周邊”是一個比流程更常用的功能，甚至有些用戶一輩子都可能不會去碰“群組”，“群組”對用戶而言，就是一個陌生東西，那麼在可用性測試中，要求用戶去完成一個陌生的任務，尤其是當這個任務還稍微復雜時，用戶就會分配更多的注意力，在做之前已經有了一個心裡預期，這樣也就更加有耐心去完成這個任務。

　　那麼，對於“周邊”這種常用的基本功能，用戶在執行任務時，可能更多是按照自己的已有的習慣或直覺來進行操作，也就不會分配太多的注意力，對軟件的容忍度也就沒有那麼大，一旦出現一點困惑、等待、或錯誤，用戶的抱怨就會較高。

　　在Kano模型中，如果基本需求沒有得到滿足或表現欠佳，用戶的不滿情緒會急劇增加，並且此類需求得到滿足後，可以消除客戶的不滿，但並不能帶來客戶滿意度的增加;與此相對的，如果魅力需求一經滿足，即使表現並不完善，也能到來客戶滿意度的急劇提高，同時此類需求如果得不到滿足，往往不會帶來客戶的不滿。在這個導航產品中，“周邊”應該就屬於基本需求，“群組”屬於魅力需求，實際的測試結果也是用戶對“群組”的整體滿意度要稍高於“周邊”。

　　由此想到的是，對於常用功能，一定要做好;不常用的功能，一定要做清晰。無論任務簡單還是復雜，首要滿足的是，清晰。如果你能想到更酷的方式，那麼很好，但也要盡量保證這樣的前提。

　　作者博客：冬源志

　　(雷鋒網 Warlial專稿，轉載請注明來自雷鋒網及作者)