關于APP開發的(de)可(kě)用(yòng)性設計原則

APP開發或者網站開發，如何才能讓用(yòng)戶獲得(de)更可(kě)用(yòng)的(de)體驗，這(zhè)就是可(kě)用(yòng)性設計需要思考的(de)問題。下(xià)面我們來(lái)討(tǎo)論一下(xià)，在移動時(shí)代，APP開發如何提高(gāo)産品的(de)可(kě)用(yòng)性。

讓設計團隊和(hé)潛在用(yòng)戶直接接觸，而不是通(tōng)過中介人(rén)或一個(gè)綜合檢查。特别是在第一階段，要收集用(yòng)戶想要完成什(shén)麽，什(shén)麽是沒有意義的(de)，以及信息架構和(hé)系統導航在多(duō)大(dà)程度上符合用(yòng)戶期望的(de)信息。關鍵任務分(fēn)析是一種有效理(lǐ)解用(yòng)戶在軟件或網站上想要完成的(de)關鍵任務的(de)方法。

 

第一次就把事情做(zuò)好是一個(gè)不錯的(de)目标，但經驗告訴我們事情并沒有聽(tīng)上去那麽簡單。如果你有測試15個(gè)用(yòng)戶的(de)預算(suàn)，最好是将這(zhè)15個(gè)用(yòng)戶拆分(fēn)爲3組。第一輪測試5個(gè)用(yòng)戶，解決那些沒有争議(yì)或不會造成新問題的(de)問題，然後再次測試。

 

許多(duō)研發團隊可(kě)能遵循了(le)前兩條原則但對(duì)測量卻猶豫不決。從每一輪的(de)測試中得(de)到一些關鍵的(de)可(kě)用(yòng)性指标能夠爲你的(de)設計決策提供簡單的(de)客觀評估。低保真原型和(hé)變化(huà)任務(changing tasks)并不是不用(yòng)測量的(de)借口。除了(le)完成率，也(yě)有其他(tā)用(yòng)于測量從叠代設計中得(de)到的(de)産品改善的(de)指标。

 

我們在三個(gè)月(yuè)的(de)時(shí)間内對(duì)一個(gè)iPad應用(yòng)進行了(le)三輪測試。在每輪測試中，我們讓5-6名參與者嘗試一系列任務。每個(gè)任務完成後我們會要求參與者在7點量表上評價任務的(de)困難度(我們會在口頭上詢問)。在第一輪測試中，原型基本上可(kě)用(yòng)，但我們仍然發現了(le)導航和(hé)标簽的(de)一些問題。下(xià)圖顯示了(le)在85%的(de)置信度水(shuǐ)平上每輪測試的(de)平均分(fēn)。

 

盡管我們在每輪測試中用(yòng)到的(de)任務會有所變化(huà)，但有三個(gè)任務在每輪的(de)測試中是一樣的(de)，有5個(gè)任務在兩輪的(de)測試中式一樣的(de)。

 

除了(le)任務層次的(de)測量，你也(yě)可(kě)以在不同階段測量對(duì)整個(gè)APP體驗的(de)感知。Bangor等人(rén)介紹了(le)一個(gè)在每個(gè)階段都是用(yòng)系統可(kě)用(yòng)性量表(System Usability Scale，SUS)進行測量的(de)叠代設計的(de)例子。下(xià)圖顯示了(le)他(tā)們在五輪測試中得(de)到的(de)數據，以及基于以往數據的(de)68分(fēn)的(de)基準平均得(de)分(fēn)。

 

如果你不想追蹤其他(tā)數據，你可(kě)以測量每輪測試中發現的(de)可(kě)用(yòng)性問題的(de)頻(pín)次和(hé)嚴重性。這(zhè)些也(yě)能夠衡量産品的(de)改善。我們更關注關鍵問題相對(duì)于全部問題的(de)比率而不是全部問題的(de)大(dà)體數量。

 

這(zhè)樣做(zuò)的(de)原因在于我們經常在每輪測試中發現同樣數量的(de)總體問題數量。當界面改善時(shí)，問題變得(de)更細微。在一些例子中，當關鍵問題解決後，用(yòng)戶也(yě)能夠進一步通(tōng)過任務來(lái)發現更多(duō)的(de)問題。

 

總的(de)來(lái)說，在APP開發和(hé)設計時(shí)要提前關注用(yòng)戶和(hé)任務、實證測量和(hé)叠代設計，這(zhè)樣才能讓用(yòng)戶獲得(de)更可(kě)用(yòng)的(de)體驗，提升APP的(de)可(kě)用(yòng)性。