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

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

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

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

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

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

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

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

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

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

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

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