概念: 可用性測試
可用性測試是一種邀請產品使用者代表來執行特定作業的一種方法,目的是測試使用者介面的易用性、作業時間及使用者親自的體驗。
關係
主要說明

展現設計的方法

展現使用者介面設計的一種方法是請商業或系統分析師陪使用者一起坐在介面的前面。排演一個普通的範例情節;例如,以使用案例分鏡腳本上描述的代表值來演練使用案例的基本流程。鼓勵此人提出問題和意見。

這種方式的困難之處在於要儘可能取得最客觀的資訊。因此,必須確定您提問的問題不受環境影響。儘量動手做筆記。可能的話,請其他人代勞,才不會打斷使用者的思路 (關於舉辦使用者訪談和研討會的實用準則,請參閱「準則:訪談」和「準則:需求研討會」)。

展現使用者介面設計的另一種方式是執行使用測試。通常以實驗室或研討會的形式辦理,由一般使用者社群的代表來參與。在使用測試中,真正的使用者以介面來執行實際的作業,軟體開發人員通常扮演被動、觀察的角色。

從這種可用性測試中,通常可以產生許多價值,可是,仍然必須面對許多挑戰,也必須權衡得失來取得可靠、划算的結果:

  • 如果一般使用者社群很龐大、來自四面八方,且在選擇軟體系統方面有高度的自主權,一般而言,這種方式最有價值。面對這些因素,如果不執行使用測試,風險將會提高。通常,執行這些測試的價值愈高,就愈難以掌控、協調及管理這項活動的一般使用者。 
  • 必須明確找出最普遍的使用型樣,排除極端值和異常的結果,以確保使用者介面設計決策符合大多數人的需求。所以,您需要更廣和更深入的取樣資料,這通常需要展開大規模的收集和校對工作。
  • 如果使用者必須從現有的舊版系統移轉至新系統,他們通常希望新系統比舊系統提供更少的功能。很不幸,這個問題很少直接浮出檯面,通常會因為像是「我希望新的系統和目前的系統有一樣的外觀與操作方式」的這種意見而隱匿。
  • 在向一般使用者社群發佈重大的技術變革時,可能需要提供基本技術運用的訓練,才可能從使用測試中產生明顯的價值。例如,舊版系統的使用者可能毫無使用滑鼠或操作 GUI 的經驗。

每一個專案團隊必須針對自己特殊的專案環境來考量這些問題,以取得可用性測試的適當時機、方法及途徑。

向不同關係人展現設計的好處

向其他人展現使用者介面非常重要。隨著介面的設計和實作持續進行,您會向愈來愈多審查人員展示設計,包括:

  • 其他專案成員
  • 外部可用性專家
  • 使用者

為了取得寶貴的意見,在真正使用者執行真實作業的情況下,您不一定會徹底演練一遍正式的使用測試。有許多使用者介面的問題起因於使用者介面設計師陷入當局者迷的盲點 - 未參與使用者介面設計的任何人,就能看出這些問題。

其他專案成員

這是展示設計的一種低估法。作業時間非常快:專案成員已熟悉應用程式,且通常隨時自願參加非正式的可用性會議。在設計活動期間,使用者介面設計師應該持續採取這種作法,以免陷入當局者迷的弔詭中。

外部可用性專家

優秀的可用性專家可指出常見的可用性缺陷,進而減少開發投入成本,通常可根據經驗在使用者介面上提出其他觀點。在使用者介面的設計工作中,最好及早引進外部的可用性專家,這樣才有足夠的時間納入建議來重新建構設計。

向使用者展示設計

向使用者展示原型通常是最好的時機。因為通常不容易找到使用者,請把握機會取得原型的意見。應該時常進行來取得關係人的認同,並釐清對於關係人需求的任何誤解。這項活動可能在需求擷取或使用者介面設計期間進行。請儘可能避免將介面向相同的使用者展示一次以上,因為到了第二次,使用者將被您上一次的設計構想所污染(也一樣變成 當局者迷),以至於貶損活動的價值。

另外,當您向使用者展示軟體原型時,請謹慎設定正確的期望。如果不妥善設定,使用者可能期望太高,以為會看到使用者介面背後完整的系統運作表現。

參考資料

如需可用性設計的相關資訊,請參閱 [CON99] 和 [GOU88]。