APP開發(fā)或者網(wǎng)站開發(fā)，如何才能讓用戶獲得更可用的體驗(yàn)，這就是可用性設(shè)計(jì)需要思考的問題。下面我們來討論一下，在移動(dòng)時(shí)代，APP開發(fā)如何提高產(chǎn)品的可用性。

讓設(shè)計(jì)團(tuán)隊(duì)和潛在用戶直接接觸，而不是通過中介人或一個(gè)綜合檢查。特別是在第一階段，要收集用戶想要完成什么，什么是沒有意義的，以及信息架構(gòu)和系統(tǒng)導(dǎo)航在多大程度上符合用戶期望的信息。關(guān)鍵任務(wù)分析是一種有效理解用戶在軟件或網(wǎng)站上想要完成的關(guān)鍵任務(wù)的方法。

 

第一次就把事情做好是一個(gè)不錯(cuò)的目標(biāo)，但經(jīng)驗(yàn)告訴我們事情并沒有聽上去那么簡(jiǎn)單。如果你有測(cè)試15個(gè)用戶的預(yù)算，最好是將這15個(gè)用戶拆分為3組。第一輪測(cè)試5個(gè)用戶，解決那些沒有爭(zhēng)議或不會(huì)造成新問題的問題，然后再次測(cè)試。

 

許多研發(fā)團(tuán)隊(duì)可能遵循了前兩條原則但對(duì)測(cè)量卻猶豫不決。從每一輪的測(cè)試中得到一些關(guān)鍵的可用性指標(biāo)能夠?yàn)槟愕脑O(shè)計(jì)決策提供簡(jiǎn)單的客觀評(píng)估。低保真原型和變化任務(wù)(changing tasks)并不是不用測(cè)量的借口。除了完成率，也有其他用于測(cè)量從迭代設(shè)計(jì)中得到的產(chǎn)品改善的指標(biāo)。

 

我們?cè)谌齻€(gè)月的時(shí)間內(nèi)對(duì)一個(gè)iPad應(yīng)用進(jìn)行了三輪測(cè)試。在每輪測(cè)試中，我們讓5-6名參與者嘗試一系列任務(wù)。每個(gè)任務(wù)完成后我們會(huì)要求參與者在7點(diǎn)量表上評(píng)價(jià)任務(wù)的困難度(我們會(huì)在口頭上詢問)。在第一輪測(cè)試中，原型基本上可用，但我們?nèi)匀话l(fā)現(xiàn)了導(dǎo)航和標(biāo)簽的一些問題。下圖顯示了在85%的置信度水平上每輪測(cè)試的平均分。

 

盡管我們?cè)诿枯啘y(cè)試中用到的任務(wù)會(huì)有所變化，但有三個(gè)任務(wù)在每輪的測(cè)試中是一樣的，有5個(gè)任務(wù)在兩輪的測(cè)試中式一樣的。

 

除了任務(wù)層次的測(cè)量，你也可以在不同階段測(cè)量對(duì)整個(gè)APP體驗(yàn)的感知。Bangor等人介紹了一個(gè)在每個(gè)階段都是用系統(tǒng)可用性量表(System Usability Scale，SUS)進(jìn)行測(cè)量的迭代設(shè)計(jì)的例子。下圖顯示了他們?cè)谖遢啘y(cè)試中得到的數(shù)據(jù)，以及基于以往數(shù)據(jù)的68分的基準(zhǔn)平均得分。

 

如果你不想追蹤其他數(shù)據(jù)，你可以測(cè)量每輪測(cè)試中發(fā)現(xiàn)的可用性問題的頻次和嚴(yán)重性。這些也能夠衡量產(chǎn)品的改善。我們更關(guān)注關(guān)鍵問題相對(duì)于全部問題的比率而不是全部問題的大體數(shù)量。

 

這樣做的原因在于我們經(jīng)常在每輪測(cè)試中發(fā)現(xiàn)同樣數(shù)量的總體問題數(shù)量。當(dāng)界面改善時(shí)，問題變得更細(xì)微。在一些例子中，當(dāng)關(guān)鍵問題解決后，用戶也能夠進(jìn)一步通過任務(wù)來發(fā)現(xiàn)更多的問題。

 

總的來說，在APP開發(fā)和設(shè)計(jì)時(shí)要提前關(guān)注用戶和任務(wù)、實(shí)證測(cè)量和迭代設(shè)計(jì)，這樣才能讓用戶獲得更可用的體驗(yàn)，提升APP的可用性。