關于APP開發的可用性設計原則

APP開發或者網站開發，如何才能讓用戶獲得更可用的體驗，這就是可用性設計需要思考的問題。下面我們來討論一下，在移動時代，APP開發如何提高產品的可用性。

讓設計團隊和潛在用戶直接接觸，而不是通過中介人或一個綜合檢查。特別是在第一階段，要收集用戶想要完成什么，什么是沒有意義的，以及信息架構和系統導航在多大程度上符合用戶期望的信息。關鍵任務分析是一種有效理解用戶在軟件或網站上想要完成的關鍵任務的方法。

 

第一次就把事情做好是一個不錯的目標，但經驗告訴我們事情并沒有聽上去那么簡單。如果你有測試15個用戶的預算，最好是將這15個用戶拆分為3組。第一輪測試5個用戶，解決那些沒有爭議或不會造成新問題的問題，然后再次測試。

 

許多研發團隊可能遵循了前兩條原則但對測量卻猶豫不決。從每一輪的測試中得到一些關鍵的可用性指標能夠為你的設計決策提供簡單的客觀評估。低保真原型和變化任務(changing tasks)并不是不用測量的借口。除了完成率，也有其他用于測量從迭代設計中得到的產品改善的指標。

 

我們在三個月的時間內對一個iPad應用進行了三輪測試。在每輪測試中，我們讓5-6名參與者嘗試一系列任務。每個任務完成后我們會要求參與者在7點量表上評價任務的困難度(我們會在口頭上詢問)。在第一輪測試中，原型基本上可用，但我們仍然發現了導航和標簽的一些問題。下圖顯示了在85%的置信度水平上每輪測試的平均分。

 

盡管我們在每輪測試中用到的任務會有所變化，但有三個任務在每輪的測試中是一樣的，有5個任務在兩輪的測試中式一樣的。

 

除了任務層次的測量，你也可以在不同階段測量對整個APP體驗的感知。Bangor等人介紹了一個在每個階段都是用系統可用性量表(System Usability Scale，SUS)進行測量的迭代設計的例子。下圖顯示了他們在五輪測試中得到的數據，以及基于以往數據的68分的基準平均得分。

 

如果你不想追蹤其他數據，你可以測量每輪測試中發現的可用性問題的頻次和嚴重性。這些也能夠衡量產品的改善。我們更關注關鍵問題相對于全部問題的比率而不是全部問題的大體數量。

 

這樣做的原因在于我們經常在每輪測試中發現同樣數量的總體問題數量。當界面改善時，問題變得更細微。在一些例子中，當關鍵問題解決后，用戶也能夠進一步通過任務來發現更多的問題。

 

總的來說，在APP開發和設計時要提前關注用戶和任務、實證測量和迭代設計，這樣才能讓用戶獲得更可用的體驗，提升APP的可用性。